Re: [PATCH] Quiet autodie's pollution of test output
2009/7/2 Paul Fenwick p...@perltraining.com.au: Since the line in question is using diag(), it already does have a # prepended to it. AFAIK most TAP parses pass that through to the user by default. diag() writes to STDERR by default, so it's noisy and clutters output. Core tests use Cprint # message\n instead for this reason. Is there a way to make diag() output to STDOUT by default globally (from the test harness) ? I'd rather not mess with redirections, but a global environment variable that would tell Test::Builder to use STDOUT for all streams by default would be nice. That way dual-life module authors could still use diag() to print informative messages. Would a patch be welcomed?
Re: Change 33313 causing failures
On 15/02/2008, Andy Armstrong [EMAIL PROTECTED] wrote: The 'failure' is the extra 'not' before the pound sign. I tried to figure out what's causing it, but couldn't. Is it possible to put the TAP parser into a strict mode where it would detect and fault these sorts of things? (I think most specifically these things are lines that aren't /^ok/, /^not ok/ or /^#/ ) I presume the lines beginning with # above are on STDERR and that what you're seeing is a mix of STDERR and STDOUT? So what the parser is seeing on STDOUT is either not ok 1309 or not ok 1309 ? No. Everything is on STDOUT. Unfortunately that second version is a special case for tests on VMS that don't output not and ok on the same line - I wonder if that's what's causing the problem. -- Andy Armstrong, Hexten
[PATCH] warnings in TAP::Parser
I've applied the following patch to TAP::Parser in bleadperl, where it was necessary to avoid a Use of uninitialized value in uc warning. Also, I found that it was unnecessary to uc() a parameter both before and after it was passed to an internal method. Change 33092 by [EMAIL PROTECTED] on 2008/01/28 14:06:59 Warning cleanup, and avoid a double call to uc Affected files ... ... //depot/perl/lib/TAP/Parser/Grammar.pm#4 edit Differences ... //depot/perl/lib/TAP/Parser/Grammar.pm#4 (text) @@ -133,7 +133,7 @@ } return $self-_make_test_token( $line, $ok, $num, $desc, -uc $dir, $explanation +$dir, $explanation ); }, }, @@ -372,7 +372,7 @@ ok = $ok, test_num= $num, description = _trim($desc), -directive = uc($dir), +directive = uc($dir || ), explanation = _trim($explanation), raw = $line, type= 'test',
Re: [Fwd: FAIL Time-HiRes-1.9708 x86_64-linux-thread-multi 2.6.20-1.3001.fc6xen]
On 15/11/2007, Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Maybe we need a way to mark a test or or a set of tests as 'can fail due to load, bad randomness, and other fluctuating factors, please try at least N times (with random sleeps in between) before giving up'? This goes for all of t/TEST, t/harness, and the various test modules. The other alternative of various module authors having to cook up their own retry policies would suck majorly. (Why do I care? Because I get every other week a report of Time::HiRes failing, that's why.) Yes, and other core tests are sensitive to load (stress tests for threads, Benchmark.pm, ...). So that would be useful. But since that probably needs to be discussed at the TAP level, please followup-to perl-qa.
Re: Test::Harness feature suggestion
On 24/10/2007, Andy Armstrong [EMAIL PROTECTED] wrote: On 24 Oct 2007, at 12:13, H.Merijn Brand wrote: pc09:/pro/3gl/CPAN/perl-current/t 138 env HARNESS_TIMER=time ./ TEST op/ver.t t/op/verok 12:18:46 Now (as of r736 from http://svn.hexten.net/tapx/trunk) the output looks like this: [12:34] andy $ prove -rb --timer [12:34:45] t/000-load..1/2 # Testing HTML::Tiny 0.905 [12:34:45] t/000-load..ok 27 ms [12:34:45] t/010-simpleok 41 ms [12:34:46] t/020-coverage..ok 306 ms I think that Merijn wanted to have the time, as in HH:MM:SS, not the duration. That helps locating what test has spuriously created temporary files it failed to cleanup.
Re: Test::Harness feature suggestion
On 24/10/2007, Andy Armstrong [EMAIL PROTECTED] wrote: On 24 Oct 2007, at 12:41, Rafael Garcia-Suarez wrote: [12:34] andy $ prove -rb --timer [12:34:45] t/000-load..1/2 # Testing HTML::Tiny 0.905 [12:34:45] t/000-load..ok 27 ms [12:34:45] t/010-simpleok 41 ms [12:34:46] t/020-coverage..ok 306 ms I think that Merijn wanted to have the time, as in HH:MM:SS, not the duration. That helps locating what test has spuriously created temporary files it failed to cleanup. Yeah - is the left hand column not that? Ah duh. Didn't notice. That was looking too much like my irc screen. /me goes back to work
Re: [ANNOUNCE] Test::Builder/More/Simple 0.71
On 19/09/2007, Steve Peters [EMAIL PROTECTED] wrote:
On Tue, Sep 18, 2007 at 06:03:13PM -0700, Michael G Schwern wrote:
Jerry D. Hedden wrote:
Michael G Schwern wrote:
http://www.pobox.com/~schwern/src/Test-Simple-0.71.tar.gz
BTW, when to you plan to submit a patch for this against blead?
Magic p5p fairies usually take care of that.
I hope that isn't a title that sticks. Bleadperl is updated to
Test-Simple-0.71 with change #31907.
And tests now pass with following change.
It takes care of
a/ pushing the right dirs in @INC when running in the perl core test suite
b/ fixes the $VERSION of Dummy.pm. Apparently bleadperl comes with
another version of Dummy.pm than Test::Simple don't ask me
why...
Change 31911 by [EMAIL PROTECTED] on 2007/09/19 14:28:28
Fix failing Test::Simple test
Affected files ...
... //depot/perl/lib/Test/Simple/t/More.t#11 edit
Differences ...
//depot/perl/lib/Test/Simple/t/More.t#11 (text)
@@ -3,7 +3,7 @@
BEGIN {
if( $ENV{PERL_CORE} ) {
chdir 't';
-@INC = '../lib';
+@INC = qw(../lib lib);
}
}
@@ -17,7 +17,7 @@
$! = $Errno;
use_ok('Dummy');
-is( $Dummy::VERSION, '0.01', 'use_ok() loads a module' );
+is( $Dummy::VERSION, '5.562', 'use_ok() loads a module' );
require_ok('Test::More');
Re: TAP::Parser 0.51
Andy Armstrong wrote in perl.qa : TAPx::Parser is now known as TAP::Parser. You can find the latest CPAN release here: http://search.cpan.org/dist/TAP-Parser/ and the latest work-in-progress here: http://svn.hexten.net/tapx/ Changes in this release: I might have missed that, but looks like TAP::Parser now ships with a prove utility ? Just like Test::Harness, or, for that matter, perl itself ? (recent perls anyway) I would just like to point out that this homonymy can be a source of problems, both for users (too keep track of which prove they have) and OS packagers (who will get two versions of the same file in two different packages). I would recommend to avoid that (at least until TAP::Parser becomes core in a stable perl.) -- They judge that metaphysics is a branch of fantastic literature. -- Borges
Re: UNIVERSAL::require broke my tests
Michael G Schwern wrote in perl.qa :
There is a fix for this, something like changing UNIVERSAL::import to be...
sub import {
my($class) = shift;
return unless $class eq 'UNIVERSAL';
...do the export...
}
Oh yes, that used to be a major *kh* problem.
That's what bleadperl's UNIVERSAL does, BTW.
--
* What system had proved more effective?
* Indirect suggestion implicating selfinterest.
-- Ulysses
Re: Object Identification Cold War and the return of autobox.pm (was Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane)
On 26/02/07, chromatic [EMAIL PROTECTED] wrote: Please reconsider autobox. I second this request. autobox in on CPAN and works. Moreover, the intent of the work on lexical pragmas was to enable people to write their own pragmas and put them on CPAN. (*) So just use it. Or, maybe you were asking to make autobox the default ? No. That's not going to happen anytime soon. The implications for backwards compatibility are too huge. And moreover the feature list for 5.10 is frozen (almost), because at some point we have to release. If autobox gets popular, used, stable, it might be included in perl 5.12 core. For the moment I think that's premature and I'd rather have people adding it as a prerequisite of their modules. (Note that I hope that 5.12 will happen in a much shorter range of time than we had to wait between 5.8.0 and today for 5.10.) (*) I note that autobox does some unclean hacks with $^H and %^H in order to try to be lexical. That would cause problems in evals. I think it will have to be rewritten for recent perls, to use the new lexical pragma capability.
Re: How many test files ship with 5.8.8?
Ovid wrote in perl.qa : In trying to get runtests to run against the core Perl test suite on a freshly built download, I'm having a few difficulties. 'make test' says this: u=5.02 s=4.72 cu=297.54 cs=98.73 scripts=934 tests=117325 This implies to me that we have 934 .t files in t/, lib/ and ext/. 'runtests' says this: Files=1002, Tests=104613, 963 wallclock secs (269.56 cusr + 78.56 csys = 348.12 CPU) Fewer tests, but more test files? 'find' says this: perl-5.8.8 $ find t ext lib -name '*.t'|wc -l 1002 So it appears that there really are 1002 .t files. What gives? The tests corresponding to modules that have not being built are not run. Also, the tests in t/japh are not run normally. Also, since I don't know makefiles terribly well, I can't figure out exactly how the test suite is getting invoked. That might help me with 'runtests'. Help? The thing that gets run when make test is issued is t/TEST. If you run make test_harness instead, it will invoke t/harness, which does use Test::Harness (t/TEST is a standalone, simpler script, that exercises less perl features.) -- Their notion of time is spread out not in a single dimension but over many, which all exist in a single, timeless instant. - Thomas Pynchon, Against the Day
Re: Terrible diagnostic failure
Ovid wrote in perl.qa : I've had similar issues with test output out of sequence, especially when I pipe the output into more or tee (sometimes 21 helps, but not always). What about an optional environment variable which forcess *all* output to STDOUT or STDERR but, if not present, leaves things as is? Seems like that would work and would also be backwards compatible. What's exactly the problem with sending everything to stdout by default? T::H knows how to cope with that. I don't like the environment variable idea. It's easy to forget your environment and be surprised when switching to anthoer session or machine. -- * What system had proved more effective? * Indirect suggestion implicating selfinterest. -- Ulysses
Re: fetching module version from the command line
Gabor Szabo wrote in perl.qa : While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' You should probably use -mModule to avoid calling Module::import(). (also, in some pathological cases, one can imagine that UNIVERSAL::VERSION() has been overidden) Side note: Abe Timmerman has a module, V, useful to get versions of installed modules: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html
Re: TAP::Harness
Michael G Schwern wrote in perl.qa : * What about Test::Harness? Test::Harness remains its own thing. At some point in the future Test::Harness will likely be gutted and turned into a thin wrapper around TAP::Harness. I'm not caring about this right now. What about prove(1) ? Are you going to make a version of it that uses TAP::Harness ? And it so, will it be removed it from T::H ? (I hope not, since it's part of the core). Or have a fork ? -- The rpmvercmp() algorithm has been implemented in shell, python, perl, ruby, java, and some gawd awful Oracle DB internal scripting language. Dunno about Forth and FORTRAN, but little surprises me any more. -- Jeff Johnson in rpm-devel
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. I'm not attached to percentages, which I wasn't looking at anyway, but when several tests fail, the header is repeated for each test. Failed Test Stat Wstat Total Fail List of Failed ---
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
On 23/04/06, Steve Peters [EMAIL PROTECTED] wrote: What's happening above is that TEST cannot handle seeing tests come in out of order, while harness can. I'm scanning Test::Harness::TAP a bit, but it seems to be unspecified whether this is OK or not. Should TEST care if the tests are reported out of order? I think it should. If the order of tests is really random, on can remove the numbering of the tests and only output ok\n or not ok\n.
Re: Test::Harness now tells you which TODOs passed unexpectedly
Andy Lester wrote in perl.qa : Please try out this dev release. I'd like to make it 2.58 tomorrow. Now integrated into bleadperl, all tests pass here. -- * What system had proved more effective? * Indirect suggestion implicating selfinterest. -- Ulysses
Re: First (developers) Release of Test::Shlomif::Harness
Andy Lester wrote in perl.qa : On Mon, Oct 10, 2005 at 02:52:49PM -0700, chromatic ([EMAIL PROTECTED]) wrote: I do NOT want to see that sort of thing as patches to Test::Harness. I have a few ideas myself on how to make T::H a little more clean and useful, but I'd have to do some refactorings myself on a private fork to see how well they look in practice. And I'm OK with that. I just want, and I suspect 99% of any authors want, to have people work WITH me. Hey, Andy, I've got some ideas on X, are you interested? Is this something you're looking at exploring? That said, now that TAP is well documented (yay), there's nothing wrong with writing other harnesses. For example, an harness that would run tests in parallel would be interesting, but I don't think there would be much code to reuse from the current T::H. (waving hands) -- Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. -- RFC 1925
Re: 5.004_xx in the wild?
On 7/4/05, Michael G Schwern [EMAIL PROTECTED] wrote: I'm going through some work to restore Test::More and Test::Harness to work on 5.4.5, minor stuff really, and I'm wondering if its worth the trouble. Has anyone seen 5.004_xx in the wild? And if so, were people actively developing using it or was it just there to run some old code and they were actually developing on a newer perl? Last time I used it (18 months ago) OpenUNIX 8, a crappy overpriced avatar of Unixware by SCO, was shipped with 5.004_something.
Re: Module and package version numbering
Michael G Schwern wrote in perl.qa : On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the A small correction -- 1.3004 would be the distribution version, (not mentioned as $...::VERSION in any package).
Re: [ANNOUNCE] Test::Simple/More/Builder 0.54
Michael G Schwern wrote: http://svn.schwern.org/svn/CPAN/Test-Simple/trunk or svn://svn.schwern.org/CPAN/Test-Simple/trunk or http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz or a CPAN near you. Thanks, bleadperl upgraded (as change #23654).
Re: New version of Test::LongString
David Wheeler wrote in perl.qa : Test::LongString is one of those modules that you should be using if you're doing testing against large data elements, especially web pages. There are now examples in the docs that I hope make you say Wow, this is cool, thanks RGS! I use Text::Differences for this, as it will show which lines are different, rather than just the first 50 characters. Much easier for me to diagnose problems. It's probably better adapted to text pages. I wrote Test::LongString to debug and test a serialization/deserialization protocol that was producing long binary strings. For this purpose, it was most helpful :)
Re: Invalid value for shared scalar
Andrew Pimlott wrote: Can you tell me where this limitation in perl threads is documented? Is there any hope that it will be removed in the future? It's not a limitation, if you share a hash it looks normal to me that you should share its elements too. (or you end up with weird quantum hashes that don't look the same from different threads...) That said, threads are underdocumented and the error message could be made much clearer.
Re: Updates to modules-related pod
Kirrily Skud Robert wrote: Here's an initial patch to perlnewmod, the main points of which are: * recommend module-starter over h2xs * modernise recommended h2xs invocation * modernise list of recommended modules to learn from * refer to Test::Simple and Test::More instead of Test * modernise PAUSE-related instructions Thanks, applied as change #23220 to bleadperl. I know module-starter (part of the Module::Starter package) isn't part of the core, but I figure that there are two answers to that: 1) propose M::S for inclusion in the core, or 2) since this doc is aimed at CPAN authors anyway, let's assume that it won't kill them to get the module from there. 2) is surely better :) BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ?
Re: Updates to modules-related pod
[EMAIL PROTECTED] wrote: 04pause.html has some useful and important information people should probably read before requesting an account. It's also linked from http://pause.perl.org/ (about PAUSE); this latest URL is probably easier to remember.
Re: Test for functions with operator names
Andy Lester wrote:
Here's a test file that makes sure that even with sub q{}, that q() is
an operator, but q() and main::q() are function calls. I suggest that
it be called t/comp/operator-subs.t.
Thanks, applied as #23215.
#./perl -T
^^
the lack of ! here gave me a small headache during the integration.
Re: Patch for t/op/sleep.t
Andy Lester wrote: t/op/sleep.t doesn't actually check to see how long it's slept for. The test takes sleep()'s word for it. I also modernized it to use Test::More and its convenience functions. Thanks, applied as change 23206.
Re: Test-Regex-0.01.tar.gz
Andy Lester wrote: Lets you check the dollar vars of your results matches_are( dog food, qr/dog(.+)/, 1=food, Matched OK ); or matches_are( first middle end, qr/middle|center/, = middle, ` = first ); Eventually we'll handle the punc vars, but for now this will do. Thoughts? What kind of useful diagnostics could this module emit in case of failure? IMO they have to be precisely detailed.
Re: more B::Concise stuff (PATCH - updated)
Jim Cromie wrote: Jim Cromie wrote: folks, attached patch has following adjustments to B::Concise and its tests. heres 2nd rev of that patch, now against 22802 Thanks, applied as change 22820. Time to play with it...
Re: tests for change #22539
Jim Cromie wrote: Heres a 'working' version of my earlier proposal, patched against [EMAIL PROTECTED] I hope you find it useful for regression testing of the optimizer, and the opcode generation phases. Thanks, applied to bleadperl as change #22664.
Re: Change 22021: Upgrade to Test::Harness 2.40.
Jim Cromie wrote: Well, it seems Ive been abusing diag() for some time now :-O Is there a 'right' way to do this ? perhaps just using ok() ? ok() goes to stdout by default, diag() to stderr or maybe a new function, ex: note() is better: note..ok# YOUR INFORMATIONAL MESSAGE HERE if that goes to stdout, that won't appear in the default harness output Since Ive been using diag() to denote groups of tests, which separates chunks of foo . ok, But this appears to be precisely what RGS doesnt like. Or use separate .t files ? Hence ive UPCASEd the note to give it some of the visual distinction that I got from diag(), hopefully w/o the annoyance. Is this worthwhile ? If so, Ill work up a patch
Re: Change 22021: Upgrade to Test::Harness 2.40.
Jim Cromie wrote: ok() goes to stdout by default, diag() to stderr which is, I presume, why perl -Ilib t/foo.t produces more output than make test. I see that as a feature.I guess note() should go to stderr - for my preferences at least. Then just do *note = \diag :) or maybe a new function, ex: note() is better: note..ok# YOUR INFORMATIONAL MESSAGE HERE if that goes to stdout, that won't appear in the default harness output Im not sure whether you regard this as a problem or a feature. as a feature. As I was saying, I like neat lined up OKs :) lots of :) Or use separate .t files ? for some cases, thats overkill. I knew you were going to say this.
Re: Perl Abstract/Concrete Syntax Tree
Andrew Potozniak wrote in perl.qa : I was wondering if there was anything built in Perl (a Module) that will take in a Perl file and parse that into an abstract or concrete syntax tree. I searched around cpan for a bit and couldn't find what I was looking for. If anyone is wondering what I'm talking about there is a nice Java package that Eclipse uses to create a tree for Java compilation that I can point you toward. Thanks for your time. Hm -- as the task of parsing perl involves some complex interplay between compile-time and run-time -- think about the function prototypes, for example -- perl can't be described by a non-ambiguous grammar, and can't be parsed accurately by tools that don't include a full-fledged perl interpreter already. However, during parsing, perl builds internally an abstract syntax tree for its own usage ; the syntax tree is then walked during execution. It's possible to stop the perl interpreter after the compilation of the main program and to have it print the current contents of the parse tree. This is achieved by the O and B::* modules, that come with perl. You may want something not too far from this : $ perl -MO=Concise -e 'print $a + $b' 8 @ leave[1 ref] vKP/REFC -(end) 1 0 enter -2 2 ; nextstate(main 1 -e:1) v -3 7 @ print vK -8 30 pushmark s -4 62 add[t1] sK/2 -7 - 1 ex-rv2sv sK/1 -5 4 $ gvsv(*a) s -5 - 1 ex-rv2sv sK/1 -6 5 $ gvsv(*b) s -6 -e syntax OK See the docs for O, B and B::Concise for more information.
Re: T::H 2.38
Andy Lester wrote in perl.qa :
prove begins with #!/usr/bin/perl and prove-switches.t
runs it with
my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/;
A $^X should be inserted here.
(in bleadperl, the shebang line of prove is fixed when installed.)
What should be in prove's shebang?
The $Config{startperl} configure variable of the perl being installed.
Re: T::H 2.38
H.Merijn Brand wrote: t/prove-switchesPerl lib version (v5.6.1) doesn't match executable version (v5.8.0) at /pro/lib/perl5/5.6.1/PA-RISC2.0/Config.pm line 21. prove begins with #!/usr/bin/perl and prove-switches.t runs it with my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/; A $^X should be inserted here. (in bleadperl, the shebang line of prove is fixed when installed.)
Re: thinking about variable context for like()
Chromatic wrote in perl.qa : On Mon, 2003-11-17 at 06:54, Potozniak, Andrew wrote: What's stopping you from creating this global var and passing it in to the function whenever it is called? Good taste. If it's going to be more convenient than Test::More's like(), go all the way and make it more convenient. Thanks, but actually that's due to my habit of adding tests to files that already contain hundreds of tests written by a dozen of people. Adding a test should be made the most straightforward possible and an interface shouldn't puzzle people. Moreover, it's convenient, when you debug a module, to have a more useful drop-in replacement for whatever test subroutine you have. That's how Test::LongString::is_string works : you can get a test file, include use Test::LongString at the top, and replace the offending is() by is_string() to have more readable diagnostics. You can always tweak the defaults later, but it's more convenient to do this by bringing the least possible modification to the test code itself. (That's why I can imagine accepting the default length as an argument to Test::LongString::import().)
Re: Perl Core Tests
Chromatic wrote in perl.qa : Stuff in t/op mostly can't use Test or Test::More because those modules rely on the features being tested. Most everything else can use Test::More. Barring any Unicode-related fiascos (of which I am proudly and blissfully unaware), they probably haven't been converted yet. t/test.pl is intended to be a lightweight replacement for Test::* for op/ tests. My goal was to improve coverage so every piece had at least nominal tests that could be improved, not to improve every existing test. Other people have had different goals. (It feels pretty good to port the tests to a more maintainable framework.) One improvement is to add names to tests. It makes them damn easier to track down when they fail.
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote: there are currently 4 dists on CPAN that only include a configure script (makepp-1.19, glist-0.9.17a10, swig1.1p5, shufflestat-0.0.3) 179 do not include any of Makefile.PL, Build.PL or configure. Quite a lot come with two or three of those files. Could we infer that a distribution that comes with several Makefile.PLs may have an overcomplicated build process, maybe indicating a low kwalitee ? See for example : http://search.cpan.org/~msergeant/XML-Parser-2.34/MANIFEST
Re: Phalanx / CPANTS / Kwalitee
Nick Ing-Simmons [EMAIL PROTECTED] wrote: Could we infer that a distribution that comes with several Makefile.PLs may have an overcomplicated build process, maybe indicating a low kwalitee ? Should I infer that to get Tk's kwalitee up it should build as a one monolithic .so ? I don't know, I'm asking. So it's necessary to have one separate Makefile.PL by .so built ?
Re: Phalanx / CPANTS / Kwalitee
Michael G Schwern wrote in perl.qa : This all suggests another check: stray files. Emacs backup files. CVS directories. Empty directories. #...# backup files. Makefiles shipped with Makefile.PL, Build and _build shipped with Build.PL, blib/... In other words, the contents of the default MANIFEST.SKIP.
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote in perl.qa : Hints that were in Leon's last release, but which I didn't port up to now: * POD errors * POD/Code ratio (what would be a good measurement?) use Pod::Coverage ? * testers results * number of releases
Test modules in 5.6.2
Folks, I've added and integrated a bunch of Test::* modules from bleadperl to 5.6.2. I've also roughly modernized the scripts t/TEST and t/harness with the bleadperl version, so that all *.t files are found, etc. Now if you're aware of a difference between bleadperl and CPAN or something, or if you find that this isn't a good idea, comments welcome. (Next step is MakeMaker. I needed the Test modules for it...) Change 20849 on 2003/08/22 by [EMAIL PROTECTED] Integrate Test::More, Test::Builder and Test::Simple, from bleadperl. Pulling in dependencies, I had to integrate if.pm as well (it's used in some tests.) Change 20848 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test 1.24 (from bleadperl) Change 20847 on 2003/08/22 by [EMAIL PROTECTED] Two tests were failing after the Test::Harness upgrade, because they use Test, that loads Test::Harness, that doesn't load FileHandle anymore. Change 20846 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test::Harness 2.30, and get t/harness from bleadperl (more or less, due to the different set of directories to scan for tests) -- perl -sleprint -- -_='Just another Perl hacker,'
Re: Testing for valid path names in CPAN distributions
Andrew savige wrote in perl.qa : Running variants of: tar tzf perl-5.8.0.tar.gz | perl -lne'print if tr|-_./a-zA-Z0-9||c' suggests only [-_./a-zA-Z0-9] are valid characters in a path name. Then I noticed 'perldoc perlport' lists the portable filename characters as defined by ANSI C and various other restrictions. What is the length limit of each path name component? What is the length limit of file extensions? I heard YAML changed from .yaml to .yml, for instance, yet Perl itself has many files with long extensions -- runtime.porting, for example. Also, don't ever include files that differ only by case. In the perl source distribution, Porting/check83.pl checks that filenames are friendly to 8.3 filesystems. What you want is probably more complex : a test to see if a *set* of filenames is portable. It'd be nice to have a standard test for valid portable path names. Does such a test exist? I noticed Archive::Any has is_impolite() and is_naughty() but didn't see any checks for basic path name validity. BTW, is Archive::Any a dead camel?
Re: Return of the Perl QA Wiki, this time for good
Michael G Schwern wrote in perl.qa : http://www.pobox.com/~schwern/cgi-bin/perl-qa-wiki.cgi Do you want a link to this from qa.perl.org ?
Re: Blurring the line between assertions and tests
Michael G Schwern wrote in perl.qa : The only part missing is the ability to shut the tests off once you've released it to production. You could perhaps use the assertion feature of perl = 5.9.0 (assertion.pm and -A switch -- yes I know it lacks docs.)
Re: [ANNOUNCE] Test::Warn::None 0.02
Fergal Daly wrote: Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, +1 for ::Auto. BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. (Avoiding to span perl interpreters at each test would be a bonus.)
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. There's Test::Warn, but I don't think it does anything special with registered warning classes. It doesn't support them for now, according to the docs. (Avoiding to span perl interpreters at each test would be a bonus.) I don't quite understsand what spanning perl interpreters means. qx// (like lib/warnings.t in the perl core) -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? No, its definately a test feature. Much easier to set up (no MakeMaker muckery), finer granularity (can be done on a per test file basis rather than a whole suite) and can distinguish between warnings and diagnostic output (ie. warn() vs diag() vs print STDERR). Besides, Test::Harness can't portably trap STDERR. If you can figure out a way to do it that would solve lots of problems. If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. Provided that all test scripts are written with a Test::Warn::None-compatible plan(). -- Don't use color combinations that cause problems for people with color blindness in its various forms. -- W3C, HTML 4.01 Specification, 6.5.1
Re: pls suggest me huge package in perl with testsuites
schwern wrote in perl.qa : Degenerative cases aside, a very good test of actual code anyone would use in production in real life for a Perl parsing attempt is Test::More (since it has a few odd constructs and a good test suite), Good advice. Test::More actually helped me to find bugs in B::Deparse, but that's because it's extensively used by perl 5.8's test suite. ExtUtils::MakeMaker and Test::Harness (both contain lots of old cruft and strange styles and decent test suites). And let's not forget t/japh/abigail.t in the perl 5.8.0 tarball ;-
Re: pls suggest me huge package in perl with testsuites
Vlad Harchev wrote: I'm testing some perl source code transformation tool (kinda perl source code prettifier). I would like to test it by running over some huge software package written in perl that have testsuites written for it available (i.e. I would like to transform some package's source, transform its testsuite's source, then run transformed testsuite to check whether transformed project still passes the tests). Could you please recommend me some such big perl packages with testsuites? Thanks in advance. You will get best coverage from the perl 5.8.0 test suite itself. As a matter of fact, the perl test suite already includes a rough mechanism to allow it to be run through some sort of filter : look in the perlhack manpage for the mention of the test.deparse make target, and scan the general Makefile and t/TEST script to see how it's implemented. With a little work you'll probably be able to run the perl test suite through your tool. HTH.
Re: Binary-wise is()
Mark Fowler [EMAIL PROTECTED] wrote: I'd like to have a custom version of is(), say binary_is(), that reports 'strings 1 and 2 differ at byte 635, got 0x92, expected 0x42' or 'strings 1 differ in length, got 3874, expected 3875'. Oooh, that would be really helpful. I often find myself writing tests which just currently do a ok($slurp eq $test_data, files match); as is() doesn't produce very helpful output See http://www.pobox.com/~schwern/talks/Writing_A_Test_Library/full_slides/ for details about using Test::Builder. plugSee also Acme::Test::Buffy (lame example testing module), and Test::Builder::Tester for help testing Test::Binary./plug Thanks. See http://search.cpan.org/author/RGARCIA/Test-LongString-0.01/ for a first version.
Re: Binary-wise is()
Mark Fowler [EMAIL PROTECTED] wrote: I'd like to have a custom version of is(), say binary_is(), that reports 'strings 1 and 2 differ at byte 635, got 0x92, expected 0x42' or 'strings 1 differ in length, got 3874, expected 3875'. Oooh, that would be really helpful. I often find myself writing tests which just currently do a ok($slurp eq $test_data, files match); as is() doesn't produce very helpful output See http://www.pobox.com/~schwern/talks/Writing_A_Test_Library/full_slides/ for details about using Test::Builder. plugSee also Acme::Test::Buffy (lame example testing module), and Test::Builder::Tester for help testing Test::Binary./plug Thanks. See http://search.cpan.org/author/RGARCIA/Test-LongString-0.01/ for a first version.
Binary-wise is()
Hi, here's an easy question for you Test:: experts : I write lots of test those days with is() comparing binary strings (mainly produced by combination of pack() and other algorithms.) The problem is that the output message of is() when those tests fail is not very helpful. I'd like to have a custom version of is(), say binary_is(), that reports 'strings 1 and 2 differ at byte 635, got 0x92, expected 0x42' or 'strings 1 differ in length, got 3874, expected 3875'. Is there already some module that does this ? If not, what's the best way to implement this myself ? (my tests using Test::More.)
Re: [ Memory ] Re: Thought
[EMAIL PROTECTED] wrote: For a more fine-grained view, you need hooks into Perl internals (such as the Perl malloc). This sounds like Devel::Peek::mstat(). But I never looked at this before.
Re: Why not a perl-current smoke test database ?
alian [EMAIL PROTECTED] wrote: * searchable for the past (and for keywords in failures or fulltext, like bigint Yep I will add this shortly. * spares me the smoke foo messages, that contain all Ok and fool me into thinking there was some smoke Sorry my so poor english doesn't understand that. Coud you explain more about that ? Matrices that contain only 'O's should be only optionnally displayed. In other works, he's saying (free translation:) [que l'interface web]... m'épargne les messages smoke toto qui ne contiennent que des OK et qui me feraient croire qu'il y avait là de la fumée. (car comme chacun sait il n'y a pas de fumée sans feu, c'est-à-dire sans caractères !=O dans la matrice.)
Re: Devel::Cover and v5.8.0 [PATCH]
Tels wrote in perl.qa :
--- Cover.pm.old Wed Sep 4 23:36:14 2002
+++ Cover.pm Wed Sep 4 23:38:46 2002
-144,6 +144,8 sub report
for my $sub (Todo)
{
+next unless $sub-[1]-CV-isa('B::CV');
That's a guard against a B::SPECIAL object, isn't it ?
Well, B::SPECIAL is for one of the internal constants '0', '1' and
'undef'. There ought to be a better interface to this, but I can't
really figure out what to improve.
In fact I think you really want
next if $sub-[1]-CV-isa('B::SPECIAL') == B::svref_2object(\undef);
(does this line fix your problem ?)
and there should be a shortcut for it.
+
if (class($sub-[1]-CV-START) eq COP)
{
# Determine whether this sub is in a package we are covering.
Re: Devel::Cover and v5.8.0 [PATCH]
Tels wrote in perl.qa :
Well, B::SPECIAL is for one of the internal constants '0', '1' and
'undef'. There ought to be a better interface to this, but I can't
really figure out what to improve.
I have no idea what you talk about - I am a total B:: newbie :)
The big story :
Each time a literal 1, 0 or undef is seen in perl source code, or
returned by a built-in, no new object is created by perl, but only
a reference to inner 'special' static constant.
Alternatively, can B::SPECIAL get a START() and ROOT() method or does this
not make sense?
Not at all. undef, 0 and 1 have no start or root, have they ?
You can still do
sub B::SPECIAL::AUTOLOAD { undef }
but I doubt this will be of any help.
Re: Devel::Cover and v5.8.0 [PATCH]
Tels wrote in perl.qa :
--- Cover.pm.old Wed Sep 4 23:36:14 2002
+++ Cover.pm Wed Sep 4 23:38:46 2002
-144,6 +144,8 sub report
for my $sub (Todo)
{
+next unless $sub-[1]-CV-isa('B::CV');
That's a guard against a B::SPECIAL object, isn't it ?
Well, B::SPECIAL is for one of the internal constants '0', '1' and
'undef'. There ought to be a better interface to this, but I can't
really figure out what to improve.
In fact I think you really want
next if $sub-[1]-CV-isa('B::SPECIAL') == B::svref_2object(\undef);
(does this line fix your problem ?)
and there should be a shortcut for it.
+
if (class($sub-[1]-CV-START) eq COP)
{
# Determine whether this sub is in a package we are covering.
Re: Devel::Cover and v5.8.0 [PATCH]
Tels wrote in perl.qa :
Well, B::SPECIAL is for one of the internal constants '0', '1' and
'undef'. There ought to be a better interface to this, but I can't
really figure out what to improve.
I have no idea what you talk about - I am a total B:: newbie :)
The big story :
Each time a literal 1, 0 or undef is seen in perl source code, or
returned by a built-in, no new object is created by perl, but only
a reference to inner 'special' static constant.
Alternatively, can B::SPECIAL get a START() and ROOT() method or does this
not make sense?
Not at all. undef, 0 and 1 have no start or root, have they ?
You can still do
sub B::SPECIAL::AUTOLOAD { undef }
but I doubt this will be of any help.
Re: [perl #15479] perl 5.8.0 segfault
Michael G Schwern wrote: I keep forgetting that I need to remember to ask this. Is there a FAQ for regression test writing? Well, an guide to so I want to write a regression test, explaining how to do it, how perl5's tests are structured to reduce interdependencies, use Test::More; when Test::More is not appropriate.. Porting/patching.pod So we have patching.pod, perlhack.pod (which is also at http://dev.perl.org/perl5/docs/perlhack.html ), pumpkin.pod (which has also useful information for non-pumpkings)... About the only thing that's missing is docs for t/test.pl. I added a short note about the existence of t/test.pl in t/README recently. Hey, that's another document ;-)
Re: use_ok w/version numbers
Andy Lester wrote in perl-qa :
I can do this:
use PHP::Session 0.10;
to ensure a version number, but I can't do this:
use_ok( 'PHP::Session', '0.10' );
The optional args to use_ok are for imports, not for version numbers.
[...]
Before I go digging into a patch, is this something that we even want to
allow? I know I'd like to allow it, because I'd like to have one .t
file that ensures that I have proper module prereqs for my entire source
tree.
You can do :
use_ok(PHP::Session);
ok(PHP::Session-VERSION(0.10),'PHP::Session version = 0.10 loaded');
or much cleaner, wrap the call to VERSION in an eval {} (it'll die
if the required version is not present.)
Re: use_ok w/version numbers
Andy Lester wrote in perl-qa :
I can do this:
use PHP::Session 0.10;
to ensure a version number, but I can't do this:
use_ok( 'PHP::Session', '0.10' );
The optional args to use_ok are for imports, not for version numbers.
[...]
Before I go digging into a patch, is this something that we even want to
allow? I know I'd like to allow it, because I'd like to have one .t
file that ensures that I have proper module prereqs for my entire source
tree.
You can do :
use_ok(PHP::Session);
ok(PHP::Session-VERSION(0.10),'PHP::Session version = 0.10 loaded');
or much cleaner, wrap the call to VERSION in an eval {} (it'll die
if the required version is not present.)
Re: Compiled programs to keep BEGIN blocks?
On 2002.01.13 22:25 Michael G Schwern wrote:
Why would this:
BEGIN {
push @INC, 'foo';
}
put 'foo' into @INC twice if it were compiled? The compiled program
should not be storing the post-BEGIN value of @INC, it should store
the original value at startup.
The compilation occurs at CHECK-time, that is, after 'foo' has been pushed
into @INC.
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On 2002.01.14 22:27 Michael G Schwern wrote: B::Deparse has slowly gotten very good at figuring out BEGIN blocks from 'use' statements and putting them in the right places. Hard fought knowledge. Steal from it. There are still problems with pragmas. (As I was working on B::Deparse the last few weeks, if you find new solutions, let me know.) I don't expect perlcc to magically become perfect overnight. What I do expect is that the 'compiled programs won't run code in BEGIN blocks' be treated as a bug and not a feature and to look around at other bits of B which are taking a stab at solving these problems.
Re: Compiled programs to keep BEGIN blocks?
On 2002.01.14 17:29 Michael G Schwern wrote:
On Mon, Jan 14, 2002 at 11:13:27AM +0100, Rafael Garcia-Suarez wrote:
On 2002.01.13 22:25 Michael G Schwern wrote:
Why would this:
BEGIN {
push @INC, 'foo';
}
put 'foo' into @INC twice if it were compiled? The compiled program
should not be storing the post-BEGIN value of @INC, it should store
the original value at startup.
The compilation occurs at CHECK-time, that is, after 'foo' has been pushed
into @INC.
I don't know if this is true, but it isn't relevent. Remember, BEGIN,
INIT, CHECK, etc... time is only relevent to the current module being
loaded/run. As this example shows, Bar.pm's code is run before even
Foo.pm's BEGIN block. Replace -MBar with -MO=C and you get the idea.
# ~/tmp/Foo.pm
package Foo;
BEGIN {
push @INC, 'foo';
}
print \@INC as Foo has modified it\n;
print join \n, @INC;
# ~/tmp/Bar.pm
package Bar;
print \@INC as Bar sees it\n;
print join \n, @INC;
Nah. You should wrap this code in a CHECK block : otherwise, in
your example, it will be run at BEGIN-time (i.e. when the Bar module
is use'd). That's what O.pm does.
$ bleadperl -I/home/schwern/tmp -MBar -wle 'use Foo'
and this should be -wcle, not -wle ...
@INC as Bar sees it
/home/schwern/tmp
/usr/local/bleadperl/lib/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/5.7.2
/usr/local/bleadperl/lib/site_perl/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/site_perl/5.7.2
/usr/local/bleadperl/lib/site_perl
.
@INC as Foo has modified it
/home/schwern/tmp
/usr/local/bleadperl/lib/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/5.7.2
/usr/local/bleadperl/lib/site_perl/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/site_perl/5.7.2
/usr/local/bleadperl/lib/site_perl
.
foo
With the modified Bar.pm :
$ bperl -MBar -wcle 'use Foo'
@INC as Foo has modified it
/opt/perl/src/lib
/home/rafael/perllib
/opt/perl/lib/5.7.2/i686-linux
/opt/perl/lib/5.7.2
/opt/perl/lib/site_perl/5.7.2/i686-linux
/opt/perl/lib/site_perl/5.7.2
/opt/perl/lib/site_perl
..
foo
Package `Foo' not found (did you use the incorrect case?) at -e line 1.
@INC as Bar sees it
/opt/perl/src/lib
/home/rafael/perllib
/opt/perl/lib/5.7.2/i686-linux
/opt/perl/lib/5.7.2
/opt/perl/lib/site_perl/5.7.2/i686-linux
/opt/perl/lib/site_perl/5.7.2
/opt/perl/lib/site_perl
..
foo
-e syntax OK
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On 2002.01.14 22:27 Michael G Schwern wrote: B::Deparse has slowly gotten very good at figuring out BEGIN blocks from 'use' statements and putting them in the right places. Hard fought knowledge. Steal from it. There are still problems with pragmas. (As I was working on B::Deparse the last few weeks, if you find new solutions, let me know.) I don't expect perlcc to magically become perfect overnight. What I do expect is that the 'compiled programs won't run code in BEGIN blocks' be treated as a bug and not a feature and to look around at other bits of B which are taking a stab at solving these problems.
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On 2002.01.05 23:45 Michael G Schwern wrote: Here's an interesting alternative. Do Clocal $^C = 0 just before running the tests, though that's pretty ugly. Interesting idiom, but I don't see when this can be done. But I rwally like the environment variable better, because with the package variable solution I need to set it unconditionally ( because for it to have effect it must be set in the init code, and in the init code I can't look at parameters, because parameters are passed in the call to compile, so I can't set it using a parameter ), and because I was hoping to keep B::C clear from hacks-to-make-the-testsuite-happy. From my PoV, I'm hoping to keep Test::Builder clear from hacks-to-make-perlcc-happy. :) The $^C thing is already a hack for B::Deparse. Instead of using an environment variable, you can use a global variable in the O namespace. Let's say $O::No_Test_Output defaults to 1 (set by O.pm). In Test::Builder (line #571) you would have return if $O::No_Test_Output; # Don't print headers under compiler backends instead of return if $^C; and B::C (and other backends that want to behave this way) could override this setting by doing $O::No_Test_Output = 0.
Re: installhtml needs a good beating out
On 2001.10.20 17:16 Jarkko Hietaniemi wrote: On Sat, Oct 20, 2001 at 02:02:59AM -0400, Michael G Schwern wrote: I think installhtml teeters heavily on the brink of Rewriting instead of Refactoring. It hasn't changed much since 1997. Refactoring is just rewriting in small pieces. By doing it in small pieces, you have a much better chance of succeeding and of staying backwards compatible. We are talking about a script that is run once by the Perl installation process, and by nobody else. There is no other backwards compatibility than producing the right output files: it's not like we have care about an API or the like. While we're at it : I noticed that the module Pod::Functions is used only by splitpod, that is in turn used only by installhtml. (Pod::Functions has a builtin list of all perl functions : it's only useful to split perlfunc into small pieces). But Pod::Functions is under lib/ in the source tree, and that means that it gets installed (by make install). This looks like a bug. Should Pod::Functions be moved under pod/ ? (And should it be removed from the untested modules list ?)
Re: Untested libraries update
Michael G Schwern listed: [...] warnings::register (almost no docs) There are no tests for warnings.pm either. Note that there are two distinct points here : 1. test the warnings issued by the perl interpreter; this is done by lib/warnings.t, that calls the various files in t/lib/warnings/*. (Some warnings are also tested by other scripts in t/ : see the test descriptions in MANIFEST). 2. test the *modules* warnings.pm (i.e. the functions warnings::enabled(), warnings::warn(), etc.) and warnings/register.pm. There are currently no tests for that. lib/warnings.t looks like it tests the 2d point, but in fact it tests the first. Probably the functionality implemented by lib/warnings.t should be placed in some new script under t/. (And this test should also succeed when doing 'make minitest'.) And lib/warnings.t should actually test warnings.pm.
Re: Untested libraries update
On 2001.09.19 17:37 Paul Marquess wrote: Nope, it does both. The test files that start with digits are intended to test the features of the warnings pragma itself along with it's interaction with $^W. All the other files test specific warnings. The tests for warnings::enabled and warnings::warn are in 9enabled. You're right, and it seems that the tests for warnings::register are in 9enabled too.
