Re: Looking for tool like pydoc to document perl cgi scripts

[_brian_d_foy]

In article , Jeff Kowalczyk <[EMAIL PROTECTED]> wrote:

> Is there an application for perl cgi scripts that will generate formatted
> HTML documentation similar to what I can get with pydoc?
> http://web.lfw.org/python/pydoc.html

you can put POD in your CGI scripts, then use pod2html

Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])

[Nicholas Clark]

On Mon, Sep 02, 2002 at 03:56:14PM -0700, Michael G Schwern wrote:
> While the result is still ugly, it means we can expand and alter the
> requirements for running a core test.  For example, the PERL_CORE
> environment variable should be set (t/TestInit.pm currently doesn't).  So
> the full command is really something like this:
> 
> cd t;
> PERL_CORE=1 ./perl -I../lib path/to/test.t
> 
> Which could be reduced somewhat to:
> 
> ./perl -It -MTestInit t/path/to/test.t
> 
> and perhaps reduced a little further by moving/linking TestInit.pm into the
> top level directory.
> 
> ./perl -MTestInit t/path/to/test.t

I think that that would be a good idea.

> but that will cause trouble when running tests with -T (because . is no
> longer in the path).

../perl -MTestInit t/path/to/test.t 
Too late for "-T" option at t/path/to/test.t line 1.

So you already have to change the command line to run a -T test by hand.
So I don't see this as a problem:

../perl -TI. -MTestInit t/path/to/test.t 
1..1
ok 1

Although writing it -T -I. is probably clearer

Nicholas Clark

Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])

[Nick Ing-Simmons]

Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>There's a chicken/egg problem here.  blib.pm is going to find the lib/
>directory so we can load uninstalled modules.  So... how do you find
>blib.pm?

Same place one would have found TestInit.pm ?

But I take you point. blib.pm is in perl core dist precisely so that 
extension modules can find it via perl's built-in INC. 

I have no real objection to t/TestInit.pm, I was just trying to 
avoid duplication.


>
>I believe the above worked for you because you happen to have an already
>installed perl in the same spot as the new one is going to go.  If you move
>that out of the way, no good.
>
>Other problems include that we can't assume blib.pm works.  Don't want the
>whole basic test suite falling apart because of a module failure.
>
>Finally, since you have to run from t/ anyway, blib.pm is overkill.  This
>works just as well:
>
>cd t;  ./perl -I../lib foo/bar.t
>
>Anyhow, t/TestInit.pm *already does this*.
>
>schwern@blackrider:/usr/local/src/perl-current$ ./perl -It -MTestInit -wle 'print 
>@INC;  use Cwd;  print cwd;'
>.../lib
>/usr/local/src/perl-current/t
>
>While the result is still ugly, it means we can expand and alter the
>requirements for running a core test.  For example, the PERL_CORE
>environment variable should be set (t/TestInit.pm currently doesn't).  So
>the full command is really something like this:
>
>cd t;
>PERL_CORE=1 ./perl -I../lib path/to/test.t
>
>Which could be reduced somewhat to:
>
>./perl -It -MTestInit t/path/to/test.t
>
>and perhaps reduced a little further by moving/linking TestInit.pm into the
>top level directory.
>
>./perl -MTestInit t/path/to/test.t
>
>but that will cause trouble when running tests with -T (because . is no
>longer in the path).
>
>When tests are run using t/TEST (ie. "make test") are run with TestInit.  So
>strictly speaking the BEGIN block is redundant.  t/harness (ie. "make
>test_harness") is currently not using TestInit.  There's currently a bug
>where $Test::Harness::switches is not honored.
-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/

TEST_VERBOSE

[David Wheeler]

Hi All,

I'm adding a framework for testing to Bricolage (we've never had one! 
Yuck!), and am just trying to get my head around a few things. I've 
decided to use Test::Class because it's a nice framework for working 
with an application as large as Bricolage (over 150 classes!), but when 
I run tests with TEST_VERBOSE=1, it doesn't do much -- just print out 
the names of the test methods being called. I thought it would provide 
more information about why tests fail and such. I mean, it prints 
relevant failure messages from Test::More, but not, for example, the 
names of the tests that failed.

In fact, other than the Test::Class method names, TEST_VERBOSE adds 
nothing to the output -- not even diag messages. So I've added this to 
the script that runs my test scripts through Test::Harness:

   use Test::Harness qw(runtests $verbose);
   $verbose = $ENV{TEST_VERBOSE} ? 1 : 0;

But what am I missing? I know that a lot of people on the cpan-testers 
list ask for tests to be re-run with TEST_VERBOSE=1, but I can't see 
that it actually makes much difference. Should it?

Thanks,

David

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]