All the Perl that's Practical to Extract and Report

Just another day...

arhuman on 2002-02-22T11:11:12

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...

why not attributes?

autarch on 2002-02-22T16:01:37

Attributes would be a much more elegant (and simple for you) solution here:

  my $a : watch;

Beccause I'm following the non-intrusive path.

arhuman on 2002-02-22T19:06:52

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 end the only solution I see will be to always use the AttrDecl modules and turn on/off the debug feature via a variable which is not much different to my mind from using the usual $DEBUG var with debug code or the way Carp::Assert works...

The only usefulness would be, IMHO, the autotie usage which could be used behind the scene, but as I manage to do it 'by hand' and beccause as it's hidden, elegance/simplicity isn't a requirement (Did I really say that !?!?) I see no reason to add Attribute::Handlers to MyDebug's required modules.

But as you're not the first person telling me that, I start to wonder if I don't miss something or even if this I'm the only one seeing the usefulness/beauty of the non-intrusive interface.

Re:Beccause I'm following the non-intrusive path.

autarch on 2002-02-22T19:57:10

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.

Re:Beccause I'm following the non-intrusive path.

arhuman on 2002-02-22T21:17:37

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 ?

What about use constant?

BooK on 2002-02-25T09:22:35

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 comment en français: Au fait, maintenant que cvs.mongueurs.net, tu peux faire héberger ton répertoire CVS chez les mongueurs de Perl, avec le site de Marseille, à côté de Log::Procmail et Games::Golf... ;-)