To be honest I'm struggling a bit with this one. CC'd to modules.

If it wasn't for the fact that the 'use' line has to be commented
and uncommented I'd say Devel::Debug was probably okay.

So how about this for a feature-enhancement...

        use Devel::Debug enable => '/path/to/file';

If the specified file exists, is readable, and contains a line that
matches the caller's package, then enable debugging for that caller.

Thus if /path/to/file contains a single line containing /./ then
everything get debugging enabled. Or if it contains /^Foo::/ then
all packages named Foo::* gets debugging enabled.

While you're there - some other random thoughts ...

        use Devel::Debug emit => 'carp';
        use Devel::Debug emit => 'cluck';
        use Devel::Debug emit => sub { ... }; # syslog or whatever

Umm, in fact those directives could also be embedded into the control
file. So for some modules you could carp and other cluck (etc. etc.).

Would also make sense to have the relevant data from the control file
for this module available to the #!...! code - so the <value> part
of wait could be specified externally, for example.

The key point being to further your own aim of being able to
enable debugging "without modyfying my code".

Tim.

p.s. I'd also suggest renaming some of the functions to be more
natural and consistent with common perl and debugger conventions:
        print -> carp (or emit to match the directive)
        show -> dump
        wait -> when

On Fri, Jun 28, 2002 at 08:24:35AM +0000, Mr Arhuman wrote:
> Thanx a lot for your time and avices !
> You'll find the doc attached.
> 
> Arnaud.
> 
> >On Thu, Jun 27, 2002 at 10:17:25PM +0000, Mr Arhuman wrote:
> > > Thanks for the comment, any idea for a proper name ?
> > >
> > > Devel::Debug::Utils ?
> 
> > > Devel::Debug::Var ?
> > > Devel::Debug::Data ?
> >
> >Not three-levels. There's no point: Devel::DebugFoo or Devel::FooDebug
> >is fine.
> >
> > > You apart, nobody seems too really care (I've asked the question several times)
> > > that's why I'm bothering you, just in case ;-)
> >
> >I'd need much more info. The summary didn't actually say much.
> >Send me the docs.

> .::Debug(3)    User Contributed Perl Documentation    .::Debug(3)
> 
> 
> NNAAMMEE
>        Devel::Debug - Simple debug module
> 
> SSYYNNOOPPSSIISS
>        # in user's code:
> 
>        Use Devel::Debug;
> 
>        ... #!assert(<cond>)!
> 
>              will die at this line if <cond> is not verified...
> 
>        ... #!watch(<var_name>)!
> 
>              will carp each access to <var_name>
>              (Idea from Srinivasan's monitor module)
> 
>        ... #!print(<double_quoted_string_to_be_printed>)!
> 
>              will carp  the string
>              Yes it's only the usual coder's best friend : print
> 
>        ... #!show(<ref to a variable to be showed>)!
> 
>              will carp the variable's structure
> 
>        ... #!wait(<var_name>,<op>,<value>)!
> 
>              will emit when <var_name> will pass the condition described by
>                  <op><value>. Currently, only works for 'watched' scalar....
> 
>        ... #!emit(carp|croak)!
> 
>              Define the emit's behaviour.
> 
> 
> AABBSSTTRRAACCTT
>        This module will allow you to debug your code in a non-
>        intrusive way.
> 
> DDEESSCCRRIIPPTTIIOONN
>        TThhee SSttoorryy
> 
>        This module started as a joke called "Psychorigid.pm".
>        Following a discussion with a JAVA zealot (hi Gloom) I
>        coded a short module using Filter::Simple to show that
>        strong type checking and other missing features could be
>        added easily to Perl thanks to filters.
> 
>        The code posted on www.perlmonks.org produced insightful
>        comments (as always on perlmonks ! Go there it's a GREAT
>        place for any Perl lover) One of them was emphazing the
>        fact that any feature making the debugging easier is a
>        good thing.  I then decided to play with Filter::simple to
> 
> 
> 
> perl v5.6.1                 2002-06-28                          1
> 
> 
> 
> 
> 
> .::Debug(3)    User Contributed Perl Documentation    .::Debug(3)
> 
> 
>        make a useful module.  I quickly coded a dirty module to
>        do the job, which stood unused on my hardisk for months.
>        I entually decided that It could be a good thing to
>        release my first module, I did some clean-up, wrote some
>        documentation and : voila !
> 
>        WWhhyy aannootthheerr ddeebbuugg mmoodduullee 
> ??
> 
>        A simple search on CPAN will lead you to several other
>        useful modules making debugging easier. (for example
>        Carp::Assert) Why did I decide to reinvent the wheel ?
>        Especially when some of the already existing wheel are
>        well crafted. Simply beccause I wanted to explore a new
>        kind of interface.
> 
>        I wanted a simple and _n_o_n_-_i_n_t_r_u_s_i_v_e way to 
> make the first
>        stages of coding easier and safer.  (By non-intrusive I
>        mean without modyfing the code)
> 
>        Ideally I wanted to switch-on (via 'use Debug;') a battery
>        of checks without modyfying my code, and then use it in
>        production with only the use line commented out.
> 
>        I could have used the usual embeded tests triggered by a
>        variable (usually $DEBUG)  but I didn't want to pollute
>        the code logic with the debugging statements and I also
>        wanted to play with the wonderful Filter::Simple module.
> 
>        Furthermore I've tried to group (and when possible
>        enhance) in this modules several features dissiminated (or
>        simply missing) in several modules.
> 
> AAUUTTHHOORR
>        Arnaud (Arhuman) ASSAD <[EMAIL PROTECTED]>
> 
> CCOOPPYYRRIIGGHHTT
>        Copyright (c) 2001,2002 Arnaud ASSAD. All Rights Reserved.
>        This module is free software. It may be used,
>        redistributed and/or modified under the same terms as Perl
>        itself.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> perl v5.6.1                 2002-06-28                          2
> 
> 
> 

Reply via email to