Re: SKIP blocks and the debugger

[Adam Kennedy]

Kirrily Robert wrote:
Does anyone else find that SKIP: { } blocks bugger up the debugger?   
I'll be happily bouncing on the "n" key to get to round about the  
vicinity of the failing test, and then blam, it sees a skipped test  and 
just fast-forwards to the end.


K.




Yep

Actually, eval does this all the time as well. If you next your way 
though an eval, it's prone to running away to the end of a program.


Adam K

How to best have statements execute only during dev/testing?

[Matisse Enzer]

I'd like to create a class that provides a bunch of assertion  
methods, like Carp::Assert, etc. I want to have an object oriented  
interface, so in some code I'm developing I would have:



  use Devel::Assert;
  my $tester = Devel::Assert->new( on_fail => carp ); # or   on_fail  
=> cluck, etc.


  my $data_structure = blah_blah();
  $tester->save($data_structure);   # Saves a clone of the data in a  
unique slot

  #
  #  do stuff with $data_structure
  #
  $tester->has_changed($data_structure);

The trick I want is that if my code is running in a production  
environment (perhaps determined at compile-time) then I want my  
Devel::Assert stuff to basically disappear. So the question is, what  
is the lowest-impact way to do that?


One easy, but probably not best way is to like this:

  sub has_changed {
 return if is_production();
 # do actual stuff
   }

I'll note here that Carp::Assert handles this issue by having you  
make all the test calls conditional:


   ASSERT( $a == $b) if DEBUG;

-M

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: How to best have statements execute only during dev/testing?

[Paul Johnson]

On Tue, Jan 10, 2006 at 08:11:43AM -0800, Matisse Enzer wrote:

> I'd like to create a class that provides a bunch of assertion  
> methods, like Carp::Assert, etc. I want to have an object oriented  
> interface, so in some code I'm developing I would have:
> 
> 
>   use Devel::Assert;
>   my $tester = Devel::Assert->new( on_fail => carp ); # or   on_fail  
> => cluck, etc.
> 
>   my $data_structure = blah_blah();
>   $tester->save($data_structure);   # Saves a clone of the data in a  
> unique slot
>   #
>   #  do stuff with $data_structure
>   #
>   $tester->has_changed($data_structure);
> 
> The trick I want is that if my code is running in a production  
> environment (perhaps determined at compile-time) then I want my  
> Devel::Assert stuff to basically disappear. So the question is, what  
> is the lowest-impact way to do that?
> 
> One easy, but probably not best way is to like this:
> 
>   sub has_changed {
>  return if is_production();
>  # do actual stuff
>}
> 
> I'll note here that Carp::Assert handles this issue by having you  
> make all the test calls conditional:
> 
>ASSERT( $a == $b) if DEBUG;

This isn't an answer to your question, but in general production is the
environment in which your code will be exposed to the data and
conditions which have had the least testing, and to which you will have
the least access and freedom to change things.  This is precisely the
environment in which I like to have checks to discover problems as early
as possible and to provide the most information about them.

Should you have considered this found that the checks are just too
expensive, for example, one possibility which is slightly better than
the one you proposed might be to to replace all the methods in
Devel::Assert with empty subs.  This will mean that you will still have
the overhead of a method call, which is (un)reasonably expensive in
Perl, so to eliminate the call completely you are left with a solution
such as the one you noted, where the call is conditional on some
constant which can be set to false allowing the optimiser to remove the
whole thing from the op tree.

I suppose you could consider a source filter, but I couldn't recommend
that.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: How to best have statements execute only during dev/testing?

[Matisse Enzer]

By the way - I have also been looking at Test::Assertions

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: How to best have statements execute only during dev/testing?

[Matisse Enzer]

On Jan 10, 2006, at 8:44 AM, Paul Johnson wrote:

I suppose you could consider a source filter, but I couldn't recommend
that.


I am in fact considering using a filter, but it scares me - perhaps  
because I have never done it before.



---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: How to best have statements execute only during dev/testing?

[Ben Evans]

On Tue, Jan 10, 2006 at 05:44:45PM +0100, Paul Johnson wrote:
> 
> This isn't an answer to your question, but in general production is the
> environment in which your code will be exposed to the data and
> conditions which have had the least testing, and to which you will have
> the least access and freedom to change things.  This is precisely the
> environment in which I like to have checks to discover problems as early
> as possible and to provide the most information about them.

Absolutely.
 
> Should you have considered this found that the checks are just too
> expensive

Then you should go back again and prove it beyond any shadow of a doubt with 
benchmarks. 

Then add assertion guards using 

if ($DEBUG) {
 # Assertion goes here
}

and benchmark again. If they are still too expensive, then you have 
bigger problems than assertion checking, notably that your application
is probably written in the wrong language.

> I suppose you could consider a source filter, but I couldn't recommend
> that.

I'd make a slightly stronger statement than that: If you were congenitally 
insane, wilfully stupid or drunk, you could consider a source filter for this.

Ben

Re: How to best have statements execute only during dev/testing?

[dakkar]

Matisse Enzer wrote:

The trick I want is that if my code is running in a production
environment (perhaps determined at compile-time) then I want my
Devel::Assert stuff to basically disappear. So the question is, what  is
the lowest-impact way to do that?


This entry in BooK's use.perl journal might help you:
http://use.perl.org/~BooK/journal/25445

--
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88


signature.asc
Description: OpenPGP digital signature

Re: How to best have statements execute only during dev/testing?

[A. Pagaltzis]

Hi Ben,

* Ben Evans <[EMAIL PROTECTED]> [2006-01-10 18:20]:
>I'd make a slightly stronger statement than that: If you were
>congenitally insane, wilfully stupid or drunk, you could
>consider a source filter for this.

Depends. Additive filters that the same code can run without are
sane when used carefully, and they’re easy to create if the
trigger is a special comment or better yet POD section:

$foo = bar();

=begin testcode

assert( defined( $foo ) );

=end testcode

frobnitz( $foo );

In production, the code runs *without* a filter so the POD
section blinkers perl reliably; what you see is exactly what
executes. Potential for mysterious bugs: zero.

In testing, the code runs with an extremely simple filter.
Potential for mysterious bugs: non-zero, but miniscule.

This is pretty sane.

Regards,
-- 
Aristotle Pagaltzis //