Looking for tool like pydoc to document perl cgi scripts
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 Thanks.
Re: Test::More::can_ok when using AutoLoader
On Sat, Aug 31, 2002 at 02:05:53PM +0200, Elizabeth Mattijsen wrote:
$ perl -Mblib -wle 'use AutoExample; print Yes if
AutoExample-can(foo)'
Using /home/schwern/tmp/AutoExample/blib
Yes
Hmmm... I'm doing BEGIN { use_ok( 'Thread::Pool' ) }... Maybe there is a
difference there...
Hmmm. Shouldn't be a difference.
Ok, so it _should_ work. I'll see if I can boil this down and create a
bugreport if I can.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Out of ammunition. God save the King.
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Mon, Sep 02, 2002 at 08:13:06AM +0100, Nick Ing-Simmons wrote: I understand all that. My point was that while test itself may care where it is run, blib.pm does not mind as much. Also blib.pm's job is to make running an un-installed module easy which is what you want to do for a pre-install test. So if there is boiler-plate stuff to do blib.pm is an appropriate place to do it. Thus is you need to be in t this might suit cd t; perl -Mblib=lib foo/bar.t would work, and I would be more than happy it it looked for a t directory as well. 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? 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. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One MERV GRIFFIN!
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Tuesday, September 3, 2002, at 08:56 AM, Michael G Schwern wrote: On Mon, Sep 02, 2002 at 08:13:06AM +0100, Nick Ing-Simmons wrote: I understand all that. My point was that while test itself may care where it is run, blib.pm does not mind as much. Also blib.pm's job is to make running an un-installed module easy which is what you want to do for a pre-install test. So if there is boiler-plate stuff to do blib.pm is an appropriate place to do it. Thus is you need to be in t this might suit cd t; perl -Mblib=lib foo/bar.t I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir t'. I'd be happier still if tests didn't run from t/, since that's not how most CPAN modules work. 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? This doesn't seem like a real problem. The test suite can find it because it knows where it's being run from. It can set up INC however it wants, to make sure blib.pm is found. Then blib.pm sets things up for the rest of the tests. 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. For core perl, we can indeed assume blib.pm works. If it doesn't, we want to know about it right away. 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 I have to wonder why it's preferable to put code on command lines rather than in modules. 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 That's reasonable to me. I don't really care whether the code goes in TestInit.pm or blib.pm, but a disadvantage of blib.pm is that it's got a rather closed command-line interface, all you can do is specify a directory to treat as a blib/ . Really, it would be nice if you could tell the module about certain situations, like -MTestInit=core or whatever, and that would do whatever's necessary for a core test run (including chdir, INC adjustments, etc.). Heck: with a smart enough TestInit, it could even adjust ARGV so that you could specify all *.t paths in Unix format, if that would be helpful. 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). '.' won't necessarily be in the path anyway. -Ken
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Tue, Sep 03, 2002 at 11:26:01AM +1000, Ken Williams wrote: Thus is you need to be in t this might suit cd t; perl -Mblib=lib foo/bar.t I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir t'. It already happens inside TestInit. I'd be happier still if tests didn't run from t/, since that's not how most CPAN modules work. The trouble here is we don't want tests running from the top level. Too much chance of them overwriting something they shouldn't be, or writing a file and forgetting to clean it up. Or touching the wrong directory, etc... So t/ is used as a safer location. It's also used just because that's what all the other tests do, so there's some cargo-cult/needless tradition. So they can't run from the top level directory, and at that point you're already different than CPAN. However, we can chdir for them, that's not hard. 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? This doesn't seem like a real problem. The test suite can find it because it knows where it's being run from. It can set up @INC however it wants, to make sure blib.pm is found. Then blib.pm sets things up for the rest of the tests. I thought the whole idea was to run blib.pm to set @INC. If the test suite is setting up @INC we don't need blib. And if we're not using blib to setup @INC there's no point in shoving extra functionality unrelated to finding modules into it. Put it into something else. Like TestInit.pm, which already has all this. 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. For core perl, we can indeed assume blib.pm works. If it doesn't, we want to know about it right away. You want to be able to continue with basic testing even in the event of a catastrophic failure. There was a big discussion along these lines about at what point in the tests we can start relying on modules, this was about using things like Test and Test::More in basic core tests. The result was that 'make test' should rely on as little as possible and I agree with that. Worse, blib relies on Cwd.pm and File::Spec. If any of these fail the test suite doesn't work at all. No good. 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 I have to wonder why it's preferable to put code on command lines rather than in modules. As mentioned below, it's not. That's why it's already in TestInit.pm (are you sensing a theme here?) I was just spelling out the equivalent command to show blib wasn't buying us anything. Really, it would be nice if you could tell the module about certain situations, like -MTestInit=core or whatever, and that would do whatever's necessary for a core test run (including chdir, @INC adjustments, etc.). TestInit is a module only available and useful in the core for doing the special little things necessary to run a CPAN-style test as a core test. There wouldn't be anything to do otherwise outside the core. Heck: with a smart enough TestInit, it could even adjust @ARGV so that you could specify all *.t paths in Unix format, if that would be helpful. Hmmm. I can't think of a use. 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). '.' won't necessarily be in the path anyway. Sorry, I ment perl's @INC. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Not king yet
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Tuesday, September 3, 2002, at 03:10 PM, Michael G Schwern wrote: On Tue, Sep 03, 2002 at 11:26:01AM +1000, Ken Williams wrote: Thus is you need to be in t this might suit cd t; perl -Mblib=lib foo/bar.t I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir t'. It already happens inside TestInit. Cool. [...] So they can't run from the top level directory, and at that point you're already different than CPAN. A pity - it means that if they write files, etc. (which is presumably the only case where this consideration matters) they have to do it differently in the core vs. regular CPAN if they want the effect to be the same. Just another obstacle to having things lead dual lives. 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? This doesn't seem like a real problem. The test suite can find it because it knows where it's being run from. It can set up INC however it wants, to make sure blib.pm is found. Then blib.pm sets things up for the rest of the tests. I thought the whole idea was to run blib.pm to set INC. If the test suite is setting up INC we don't need blib. blib.pm only adds to INC. Seems like the core requires something to strip INC down to a small set, not add to it. So blib.pm as it currently works isn't really the right tool I guess. Nick was suggesting blib.pm could be changed, but it sounds like you'd rather create a different TestInit tool. Anyway, what I meant was that INC needs to be one value to find blib.pm, and then blib.pm changes INC to be another value, so there's no chicken/egg problem. And if we're not using blib to setup INC there's no point in shoving extra functionality unrelated to finding modules into it. Even more importantly, there may not be room in the blib.pm interface for other stuff. I have to wonder why it's preferable to put code on command lines rather than in modules. As mentioned below, it's not. That's why it's already in TestInit.pm (are you sensing a theme here?) I was just spelling out the equivalent command to show blib wasn't buying us anything. Ah, I see. 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). '.' won't necessarily be in the path anyway. Sorry, I ment perl's INC. That's what I meant too. People can build Perl without '.' in INC, right? -Ken
Re: Looking for tool like pydoc to document perl cgi scripts
On Mon, Sep 02, 2002 at 01:01:24PM -0400, Jeff Kowalczyk 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 POD perldoc. See the perldoc and perlpod man pages. It can produce HTML and lots of other formats. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Still not king
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Tue, Sep 03, 2002 at 03:34:39PM +1000, Ken Williams wrote: I thought the whole idea was to run blib.pm to set @INC. If the test suite is setting up @INC we don't need blib. blib.pm only adds to @INC. Seems like the core requires something to strip @INC down to a small set, not add to it. @INC only contains paths to where the libraries will be installed. Until installation happens, perl can't find it's own not-yet-installed libraries without help. We remove all other entries from @INC so that previously installed modules don't interfere with testing the new versions. Anyway, what I meant was that @INC needs to be one value to find blib.pm, and then blib.pm changes @INC to be another value, so there's no chicken/egg problem. There is no other value to be changed to. All you need to do is find lib/ '.' won't necessarily be in the path anyway. Sorry, I ment perl's @INC. That's what I meant too. People can build Perl without '.' in @INC, right? I don't think so. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If your module passes test You're one of the very best Don't fuck up the MANIFEST Burma-Shave - ignatz
