Re: Discourage use_ok?
* On Mon, Nov 09 2009, David Cantrell wrote: On Mon, Nov 09, 2009 at 11:41:21AM +0100, Philippe Bruhat (BooK) wrote: On Mon, Nov 09, 2009 at 02:24:11AM -0800, Ovid wrote: Thinking about this more, what about a compile_ok()? compile_ok() would certainly be interesting with scripts shipped with a module, that usually have very little meat that needs testing (since most of the work is done in the modules), but that one would at least check that they compile. Why not test that the script *works*, not just that it compiles? Why use a script at all? They are clearly difficult to test, and code that is difficult to test is where the bugs always hide. (Yeah, this is a bit of an old thread, but I am behind on my mailing list mail :) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Making TODO Tests Fail
* On Mon, Jul 13 2009, Ovid wrote: How would Smolder (which we're not using since we use Hudson) help with this? With over 15,000 tests being reported for t/aggregate.t, I think a drill-down would be problematic here. Plus, tying the TODO to the appropriate test file being aggregated is needed. Thus, I thought about a BAILOUT or forced failure for the TODO at that point. Can't you just put the TAP into a database, and do a quick query to extract the file, test number, and line of passing TODO tests? Surely some code might need to be written, but it doesn't sound too hard. -- print just = another = perl = hacker = if $,=$
Re: Test::More::does_ok()
* On Wed, Apr 08 2009, Michael G Schwern wrote:
# Moose
sub DOES {
return $_[0]-meta-does_role($_[1]);
}
# Class::Trait
sub DOES {
return $_[0]-does($_[1]);
}
Why is the Perl 5.10 way ALL CAPS, anyway? DOES is not automatically
called by Perl, is it? (Follow-up question: why is isa not ISA?)
--
print just = another = perl = hacker = if $,=$
Re: Stupid prove tricks
* On Wed, Feb 25 2009, Michael G Schwern wrote: Here's a kind of crappy way to make TAP read from STDIN. $ prove --exec 'cat -' test.dummy test Now you can write TAP and finish with ctrl-d. But test.dummy has to exist. I just tried this, and it works without test.dummy existing (although it complains after you type the TAP). This doesn't happen if you use /dev/null, though (as in prove --exec 'cat -' /dev/null). -- print just = another = perl = hacker = if $,=$
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
* On Wed, Nov 12 2008, David Golden wrote: On Wed, Nov 12, 2008 at 3:17 PM, demerphq [EMAIL PROTECTED] wrote: IMO if the toolchain is to work this should happen at PAUSE (if it can detect this problem IMO it should just damn well fix it itself) or at extraction. It *is* being fixed at extraction. But it requires people to upgrade CPAN and CPANPLUS (maybe Archive::Extract as well). It was a faster fix to close the PAUSE indexing door than to get those fixes released. I agree with demerphq here, why can't PAUSE just fix this? It won't break signatures (since they sign file content, not file metadata), and it won't break the CHECKSUMS file (since that could be generated after the tarball is fixed). It could be weird if what you upload to CPAN isn't what you download... but it fixes a security problem, and it doesn't require authors to know that this problem exists. Abstraction++ Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
* On Sun, Sep 28 2008, Cosimo Streppone wrote: Hi! I don't know if I really understand the entire world-writable files security hole. Anyway, I think the average CPAN author doesn't really know or care about that, sadly. See also FWIW, this is true. I have never thought about it. Personally, I am confused as to why users have programs that do whatever an input file from the Internet tells them to do. If you don't want your tar command to create world-writable files, you should probably tell your tar command to not create world-writable files... right? That is much easier than convincing every person on the Internet to do what you want. It is also easier than convincing every CPAN author to upgrade MakeMaker. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: About tidying up Kwalitee metrics
* On Sun, Jun 29 2008, chromatic wrote: However, does making CPAN a better place require publishing a Hall of Shame on perl.org? http://cpants.perl.org/highscores/hall_of_shame Good point. The same could be said for CPAN Ratings also. Why should my module have 1 star next to it because any goof with a web browser can write a review? Why is the opinion of someone with no ties to the community considered relevant enough to show in the search.cpan search results? (The same goes for positive ratings. I've seen a lot of high ratings of modules that are rated highly for no good reason, or rated that way by its own author.) I personally don't care and generally ignore the ratings, but it's the same thing as Kwalitee, except not even objective. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: CPAN Ratings and the problem of choice
* On Mon, Jun 30 2008, Greg Sabino Mullane wrote: Why are people not rating modules, and how can we encourage people to do so? Probably for the same reasons they don't read this mailing list, contribute to perlmonks, attend YAPC, upload their own modules, etc. I don't know exactly what this reason is, but I have a feeling it's who cares or why should I bother. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: best practices for temporary files during testing
* On Sat, Jun 07 2008, David Golden wrote: On Sat, Jun 7, 2008 at 1:58 PM, Christopher Laco [EMAIL PROTECTED] wrote: Directory::Scratch..and it cleans up after itself. Module::Install-- (and a somewhat dated one, too) Module::Install with auto_install-- Yeah, auto_install needs to die. The recently-uploaded 0.14 release kills it :) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Munging output when running warning tests
* On Fri, May 02 2008, Eirik Berg Hanssen wrote:
nadim khemir [EMAIL PROTECTED] writes:
On Friday 02 May 2008 01.24.00 Eirik Berg Hanssen wrote:
use Test::More tests = 1;
use Test::Trap;
trap { warn 1\n2\n3 };
$trap-warn_like(0, qr/1\n2\n3/);
Ah! I like this. How did I miss this module??
Perhaps I just haven't been _quite_ shameless enough plugging it? ;-)
is it possible to have trap{} return an object/sub/whatever that is created
by
the trap{}. The automagic $trap is too automagic for me.
Possible? Sure, if you wrap it up for that. This is pure Perl,
after all. :)
Recommended? Not really. It kinda runs counter to the design. The
idea was for trap{}/$trap to mimic eval{}/$@; for one thing
list/scalar/void context is propagated into the block; for another,
$trap is a (package, but still) global, so you may localize it.
It seems to me any alternative interface will be either overly,
un-perly verbose or else severely restricted. But, granted, the
severely restricted interface may be enough for you.
I think the most sane interface would be:
my $trap = trap { ... };
is $trap-foo, 'foo';
is $trap-bar, 'bar';
You said you're trying to emulate $@, but $@ can be changed out from
under you rather easily, so instead of:
eval { foo() };
if($@){ error }
The defensive programmer will write:
my $result = eval { foo() };
if(!defined $result){ error } # use $@ for more details, if necessary.
This gives you more flexibility anyway:
my $a = eval { try_something };
my $b = eval { try_something_else };
if(!$a !$b){ die 'both alternatives failed!' }
Anyway, automatically setting variables should always be avoided,
regardless of whether or not it is perlish. I want correct tests, not
perlish tests.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: W3C validator without network access?
* On Sun, Apr 06 2008, Gabor Szabo wrote: Is there a W3C validator that works locally on my computer? HTML::Tidy is close. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Idea: CPAN Category Reviews
* On Sun, Apr 06 2008, Guy Hulbert wrote: On Sun, 2008-06-04 at 23:47 +0200, Philippe Bruhat (BooK) wrote: It still looks like a big job to me. Kobesearch's sources are available. See Jonathan Rockaway's last reply in this thread. His stuff looks really good. He pointed me to this (offlist): http://git.jrock.us/?p=MetaCPAN.git;a=blob_plain;f=HOWTO BTW, I meant for this to be public... but I didn't pay attention to where Reply sent the mail. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Idea: CPAN Category Reviews
* On Sat, Apr 05 2008, Shlomi Fish wrote: Hi all! In regards to the previous discussion about trimming down CPAN and finding better ways to find quality modules, I got an idea of making CPAN category reviews. The idea was originally derived from Freshmeat.net where they often have category reviews of the various software hosted there: http://themes.freshmeat.net/articles/section/category%20reviews/ Now I thought of importing that idea for CPAN. [cut] So what do you think - is there an interest in this? I think you should just do it. Then we can see if there is interest or not. Personally, I don't like reviews. I think reviews tend to aim for quantity over quality. For example, can you really become an expert in Template Toolkit, HTML::Mason, Template::Declare, and HTML::Template in a weekend, and then write an article? Of course not -- I use TT and TD extensively every day and I don't think I could give them a fair review. There are parts I like, but I don't think I could give you a full overview on exactly why or why not to use them. So the issue is that the reviews are very superficial unless the reviewer is an expert in all of the modules, which is rarely the case. If there are 5 similar modules, you are probably just going to pick one -- in which case, you won't be qualified to write about the other 4. So anyway, I prefer articles like here's a cool thing I did with Foo::Bar. People can see what's good about Foo::Bar in a natural way, instead of having some review shoved down their throats. If some like Quux::Foo better, then they can write an article about that. In this system, the experts write about their areas of expertise, and let everyone else make decisions for themselves. I think that's what we need more of. As an example: http://blog.jrock.us/articles/Devel%3A%3ABeginLift.pod I suppose you could categorize that as documentation, but I like it for the here's a module you haven't heard of before factor. Another example: http://blog.jrock.us/articles/Adding%20more%20methods.pod The goal there was to show what you can do with Class::MOP and Moose. It's probably something you weren't looking to do, but now that you know about it, you have a new tool in your toolbox. I think that is more valuable than comparing Text::Template and TT. Anyway, no need to worry about what I think. Just add yourself to Planet Perl and start writing. Instant access to 2000+ readers. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: cpan-testers in the inbox
* On Mon, Feb 11 2008, Andy Lester wrote: http://log.perl.org/2008/02/no-more-email-d.html Well I guess that settles that. :) This is unrelated to the usual whining about receiving FAIL reports in your inbox. Those are sent directly by the smoker, not via the cpan-testers mailing list. The cpan-testers mailing list is a mailing list that sends *every* cpan testers report; good for, say, irc bots that announce the results of testers reports live. Regards, Jonathan Rockway
Re: Find all the modules 'use'd in a directory
* On Fri, Feb 08 2008, Dominique Quatravaux wrote: Andy Lester wrote: First, install ack, either installing App::Ack or downloading the standalone version from http://petdance.com/ack/ Interesting. Would you be so kind as to implement grep -n-style output format for us Emacs users? Might as well use M-x rgrep from within emacs. Regards, Jonathan Rockway
Re: Find all the modules 'use'd in a directory
* On Thu, Feb 07 2008, Matisse Enzer wrote: I want to utility program that I can point at a list of files and/r directories and get back a list of all the unique modules/pragmas that are imported via 'use' Before i write my own, using PPI, does this exist already in the CPAN? What's wrong with Module::ScanDeps? It has options for static scanning (regexing the code, basically) or running the code and inspecting %INC. Also, it comes with scandeps.pl, so you don't need to write any code. Regards, Jonathan Rockway
Re: is_deeply and qr// content on 5.11
On Fri, 2008-01-18 at 17:22 -0600, Jonathan Rockway wrote: On Fri, 2008-01-18 at 16:57 -0600, Ian Malpass wrote: I got a failure message from CPAN testers for Pod::Extract::URI for 5.11.0 patch 33001 on Linux 2.6.22-3-amd64 (x86_64-linux-thread-multi-ld)[0] The failures were where I was testing to see if an arrayref of qr// patterns was the array I was expecting. is_deeply() has heretofore worked perfectly well. The test line in question is: is_deeply( $peu-stop_uris, [ qr/foo/ ] ); And the failure is: # Failed test at t/new.t line 42. # Structures begin differing at: # $got-[0] = (?i-xsm:foo) # $expected-[0] = (?-xism:foo) # Looks like you failed 1 test of 24. Are you positive you didn't mean to say qr/foo/i ? Are you sure that $peu-stop_uris should be returning qr/foo/i instead of qr/foo/? Sorry to reply to myself (it's Friday, what can I say)... but under 5.8.8 and 5.10.0, this test passes: is_deeply qr/foo/i, qr/foo/ # pass Honestly, I think it's a bug in the older versions and 5.11.0 gets it right. Those two regexes aren't the same. Since there's been some discussion on p5p about regex object internals, I'll forward the message over there so they know the behavior has changed. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
On Wed, 2007-12-19 at 03:30 +, Andy Armstrong wrote: I'm locked in correspondence with Marc now. His view: cpan-testers are incompetent, ego tripping, quasi-religious nuisances. Solution: get a mail filter. If he doesn't want reports, he should devnull them. Anyway, I think most authors like the reports. Personally, it motivates me to fix my modules when I know someone is actually trying to use them. (Smokers are nice too because I can fix my modules before a real person wastes their time trying to install my broken code :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Combatting attempt to censor Finance::FuturesQuote
On Tue, 2007-11-27 at 17:55 +0100, Dominique Quatravaux wrote: All publicly accessible BackPAN mirrors must pull this distribution manually, given that rsync-without-delete won't do it for you. Shucks! Too late. http://kilimandjaro.dyndns.org/~dom/FuturesQuote-0.01.pm Come on now. I have no idea whether that thing is any good, but these scare tactics from The Man are just silly. Agree here. One thing to think about: is this going to get the *author* in trouble? It would be nice to change the contact information there to avoid the author being sucked into a legal battle he can't afford. He doesn't deserve legal trouble simply because he wrote a useful CPAN module that someone doesn't like... but I can't afford to defend him against a $LARGE_COMPANY. I recommend we delete the AUTHOR information and distribute this module on thepiratebay. I will definitely seed the torrent. Finally, could the CD letter be made available? Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
On Tue, 2007-11-27 at 17:42 +0100, David Landgren wrote: All publicly accessible BackPAN mirrors must pull this distribution manually, given that rsync-without-delete won't do it for you. What legal precedent is there here? Violating the ToS is the responsibility of the user of the module, not people distributing the module. Let's not kill the free software movement by deleting anything that anyone with a lawyer requests to be deleted. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
On Tue, 2007-11-27 at 09:25 -0800, chromatic wrote: On Tuesday 27 November 2007 08:53:52 Jonathan Rockway wrote: What legal precedent is there here? Violating the ToS is the responsibility of the user of the module, not people distributing the module. Would you also distribute a module which effectively performed a DoS against search.cpan.org and *.perl.org? Please delete Firefox from the Internet, since users can click reload repeatedly and DoS a slow site. This module is just a web browser. Users are responsible for the actions of users, not the author of software that the user happens to use. BTW, I created: http://programming.reddit.com/info/61jsd/comments/ For general (snarky) discussion. This issue doesn't really concern perl-qa, since it's just going to be a big flamefest. Infecting technical mailing lists with flames and legal wanking isn't helpful to the community. My apologies for the messages so far, but this sort of thing makes my blood boil :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: New proposed CPANTS metric: prereq_matches_use
On Sun, 2007-11-18 at 18:51 -0800, Matisse Enzer wrote: On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote: Even if it's in the perl core, the developer may have compiled with -Dnoextensions=Encode In such a case Encode is not present. I have skipped Encode many times because it takes up so much time, others may do likewise. So, I think the bottom line here is: List them ALL in Makefile.PL/ Build.PL I've been yelled at in bug reports and on IRC for adding core modules as prereqs (think upgrading dual-life core modules on older Perl versions; I guess that's not always desirable.) I think the best solution would be something like: # Makefile.PL use 5.8.8; requires 'Encode'; # note that I'm not specifying a version; use 5.8.8 does that for me I think the real solution, though, is to agree that the perl interpreter without all of the core modules installed isn't Perl. (I'm not a big fan of core modules, but the concept is especially worthless if you can't depend on their existence.) Regards, Jonathan Rockway
Re: Deferred Plans
On Mon, 2007-11-19 at 17:08 -0600, Andy Lester wrote: On Nov 19, 2007, at 5:04 PM, A. Pagaltzis wrote: A deferred plan is clearly not as good as a predeclared plan, but is definitely much safer than no plan at all. But what if something blows up before getting to the deferred plan? Then you don't know. You've bypassed having a plan. More information is better than less information. Consider the case where you want to run n + 10 tests. With blocks in a deferred plan, you can't be entirely sure that n is correct, but you can be sure that the other 10 tests did run. Not perfect, but better than just saying 1..63 at the end and not knowing if the + 10 is included in that 63. Secondly, perhaps it's possible to refactor the test to turn an entire block of TAP into a single test. Compare files_are_valid(@FILES) to file_is_valid($_) for @FILES. Same effect, but with the first one you can declare the plan in advance. (OK, bad example because you know how many elements are in @FILES. But the concept still applies.) Regards, Jonathan Rockway
Re: get_resource_by_name() - Find full-path of something in @INC
Eric Wilhelm wrote:
If we're voting, I would prefer to avoid having non-modules in @INC.
I agree. How about using Module::Install to install files to a known
location (auto), and then File::ShareDir to get at those files? I have
had pretty good success with this approach. (My CatalystX::Starter on
CPAN does this, and people don't seem to be having any problems with it.)
FWIW, Catalyst takes the approach of looking at $INC{Your/App.pm} to
find the path to your main application class, and then uses that path to
look for shared resources (TT templates for example). You might like
that approach best.
Full details are in Catalyst::Util::home:
http://search.cpan.org/src/MRAMBERG/Catalyst-Runtime-5.7011/lib/Catalyst/Utils.pm
Hope this helps.
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: Test::Load, anyone?
Ovid wrote: Yeah, it's a crappy name. Test::Use? Test::UseOK? Test::UseAllOK, Test::JustLoadMyFrigginPackages? : I'm fine with Test::Load. I immediately guessed what your module did by the name :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Module metadata
David Golden wrote: (Which reminds me to go update my module metadata on CPAN::Reporter since I've changed license and abstract since I first registered. The changes are in my META.yml, of course, but I forgot about PAUSE.) This is a pretty good point and has caused me to change my mind. It would be nice to put all this stuff in META.yml. Keeping data in multiple places consistent is much more painful than uploading to the CPAN. Anyway, should the DSLIP stuff be added to the META-spec? (I see that some stuff, like the S and L parts, are already covered by META.yml. Is the rest worth adding, or is it time to forget about it?) As for keywords, can I use those for anything? It would be nice to replace the manually-generated categories on search.cpan (and other places) with popular tags. Maybe that's too web 2.0y but I think it might be nice :) Regards, Jonathan Rockway
Re: Test::Pod / YAML explodes (and taking cpants with it...)
David Cantrell wrote: Number::Phone::UK::Data contains a big chunk of binary gibberish at the end of the file (it's an embedded DBM::Deep database), in a __DATA__ segment. That includes several lines that match /^=/ and so might look like POD, and hence confuse things. I'd argue that this means there's a bug in Pod::Simple::Checker and/or Test::Pod, if they're looking at stuff in __DATA__. You might like File::ShareDir for this. That way you can keep the big data file out of band, and avoid having to maintain a database inside your perl file. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Bug fix in Test::More 0.71 may reveal failures tests
A. Pagaltzis wrote: • AIX::Perfstat (disk.t) • Business::BR::Ids (002_cpf_test.t 015_pis_test.t) • Cache::FastMmap (6.t) • CGI::Application::Plugin::LogDispatch (singleton.t) • CGI::Application::Plugin::TT (04_singleton.t) • CGI::Uploader (up_table_map.t) • Data::FormValidator::FromDBI (01-generator.t) • Date::Span (from_unit.t) • DBD::Sybase (place.t) • DBIx::AsForm (basic.t) • DBIx::LazyMethod (MySQL.t) • DBIx::Simple (sqlite.t) • DTS (AssignmentTypes.t) • Gaim::Log::Parser (002DateTime.t) • HTML::DBTable (02__DBSchemaPatched.t) • HTML::TableParser (contents.t) • Image::MetaData::JPEG (JPEG_0_records.t JPEG_1_segments.t JPEG_2_JPEG_class.t) • jsFind (04words.t) • Mail::Audit (shorthand.t) • Mail::SpamAssassin::SimpleClient (result-spam.t) • Mail::Toaster (maillogs.t) • Net::FTPSSL (10-complex.t) • Oracle::Debug (oradb.t) • POE::Component::SNMP (20_snmp_getnext.t 60_errors.t) • Purple (api.t) • RDF::Sesame (98-debug.t) • sapnwrfc (06test_data_z.t 08deep_z.t) • Search::Estraier (5_Node.t) • Solaris::Disk::Mnttab (05half-calls.t) • Solaris::Disk::VTOC (15size2.t) • SVN::Notify (html.t) • Test::MinimumVersion (pod-coverage.t) • Text::Aspell (05-core.t) • Text::Capitalize (003-captitle-preserve_whitespace.t) • Tuxedo::Admin (1.t) • WWW::Ofoto (14-upload_lots.t) Aristotle++. Your method was much better than my try installing stuff I need and see what fails technique :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Bug fix in Test::More 0.71 may reveal failures tests
Michael G Schwern wrote:
Test::More 0.71 fixed a subtle bug where a call to use_ok() inside a BEGIN
block without a plan would be silently ignored. That is...
use Test::More;
BEGIN { use_ok('Exporter') } # for example
plan tests = 1;
pass();
would pass when it should have failed. This commonly takes the form...
use Test::More;
if( ...something we need isn't there... ) {
plan skip_all = Missing something;
}
else {
plan tests = 2;
}
BEGIN { use_ok('Some::Module') }
XML::LibXML does this. Attached is a patch to fix it.
Regards,
Jonathan Rockway
--- t/40reader-BROKEN.t 2007-09-15 22:31:56.0 -0500
+++ t/40reader-FIXED.t 2007-09-15 22:34:45.0 -0500
@@ -3,13 +3,15 @@
use warnings;
use Test::More;
-if (XML::LibXML::LIBXML_VERSION() = 20621) {
- plan tests = 92;
-} else {
- plan skip_all = Reader not supported for libxml2 = 2.6.20;
-}
+use XML::LibXML;
BEGIN{
+ if (XML::LibXML::LIBXML_VERSION() = 20621) {
+ plan tests = 93;
+ } else {
+ plan skip_all = Reader not supported for libxml2 = 2.6.20;
+ }
+
use_ok('XML::LibXML::Reader');
};
signature.asc
Description: OpenPGP digital signature
Re: The Wiki Has Been Spammed
Clint Moore wrote:
On 12/4/06, Michael G Schwern [EMAIL PROTECTED] wrote:
Thanks for reporting this, but its also nice to clean up what you
see. It a wiki, edit it.
I had that attitude once. Sort of like when I believed in Santa
Claus. Then I decided to clean kwiki.org and rjbs's email project
kwiki off and on for about a month. Wiki spammers can beat the
oo-it's-a-wiki-share-contribute-learn feeling out of you surprisingly
quickly.
I tend to password protect my wikis with a generic account like
username foo, password bar. Won't upset any lazy humans that want to
contribute, and the spammers haven't figured it out yet. I was shocked
that my non-googlable trac site was getting problem ticket spam* within
a day or so of me launching it. Stupid, stupid spammers.
* Type: defect. Subject: ENLARGE YOUR DONG. Priority: major.
Milestone: 1.0
They actually picked sane values for the metadata. Sad.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: CPAN.pm to install only flagged versions of modules
On Monday 30 October 2006 18:16, David Golden wrote:
Bundle gives the option of either freezing a particular version (by
specifying a distribution file) or else fully upgrading to the
absolute latest version (by specifying a module).
The problem I've experienced with this method is that authors tend to delete
their modules from the CPAN (at the strong urging of messages on the PAUSE
website). This leads to broken bundles (or ports in my case), which is
mildly irritating. However, adding logic to get the files from the backpan
would eliminate this problem. (But then there's the bandwidth issue -- do we
really want automatic tools hitting the backpan?)
The other issue is of security updates. I would hate to lock people into
insecure versions of modules. Maybe there needs to be (another :) flag that
says don't distribute this version anymore, use x.y.(z+1) instead.
Problems like this might be too late for the 5pan to solve, though. (I'm not
sure I like any of the 6pan proposals, though, so fixing the current CPAN is
not necessarily a bad idea or a waste of time.)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgp4pMn9HLdEV.pgp
Description: PGP signature
Re: Sparse Test Output
There is already a libtap
Ah! Thanks for pointing that out. I was planning a libtap to *parse*
TAP, whereas this libtap *emits* TAP. If necessary, the name could be
changed to libparsetap or something :)
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Suggestions for cpantesters
CPAN Testers reports must be sent to the cpan-testers mailing list. As
with
most mailing lists, email from non-subscribed addresses is held for manual
review.
CPAN Test reports follow a fairly rigid format that computers can easily
detect. I think it's worth auto-whitelisting messages that look like
FAIL Foo::Bar 3.14_15 or PASS Hello::World 2.71. The CPAN::Reporter
(?) and CPANPLUS mails look about the same, and that's the bulk of the
traffic. If you allowed those and had to moderate replies from the
author, requests for more info, etc., I think that would reduce the need
for human intervention. (Maybe you're already doing this... I don't know.)
Another idea is to have a BitCard (or something) -protected area where
you (or your software) can upload test reports on your behalf. I have
machines that I'd like to send test reports from, but don't run an MTA
(Cygwin). If I could HTTP POST the reports somewhere, that would be
good. Plus, if someone starts spamming, you can just shut off their
BitCard account.
My $0.02.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: TAP 2.0
I like the YAML syntax, but can we live with:
got: |
this is line 1
this is line 2
expected: |
this is line 1
this is line 2
Instead? That way a real YAML parser can parse the output of TAP, which
could be important for adoption by other languages. Rather than require
others to write a TAP parser, we can just tell them to use their YAML
parser in streaming mode. Since we aren't using *all* the features of
YAML here, we can still have a light implementation for Perl. (Not that
I'm against using a full YAML parser... but I think others are :)
got: this is line 1
this is line 2
this is line 3
expected: this is line 1
this is line b
this is line 3
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Send me unusual make error strings for CPAN::Reporter
Of course. Locales. It all seemed too easy.
Time for plan B.
Looking for stars might be the best approach:
GNU make reports failure:
template.l: In function `yylex':
template.l:38: error: syntax error before '%' token
gmake: *** [template] Error 1
BSD make errors out like this:
template.l: In function `yylex':
template.l:38: error: syntax error before '%' token
*** Error code 1
Stop in /home/jon/template-test (line 7 of Makefile).
Unfortunately dmake (as shipped with Strawberry perl) prints:
dmake: Error: -- flex: No such file or directory
I don't have nmake around to see what that does...
Error is a common string, but only in English :/ I think the tee
mechanism needs to be rethought -- maybe a small wrapper around make
that gets the exit code and prints makewrapper: *** MAKE FAILED WITH
CODE 123!?
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Testing for test labels
Override Test::Builder::ok to croak if it doesn't get a test name argument.
Package that up in a module and shim it in with PERL5OPT or
HARNESS_PERL_SWITCHES.
I kind of dislike this approach. If my tests are failing, I want them
to fail because my program is broken, not because my tests are broken.
I also don't want missing comments to stop my test from running...
sometimes you need to quickly fix something, run the tests, and *then*
make everything pretty.
So I would prefer that t/style.t fails due to No description of test
on line 31 of frob.t, rather than t/frob.t failing (or croaking!) for
the same reason.
Unfortunately, this is sort of a only-perl-can-parse-Perl issue. You
don't know that you didn't have a description until you've run the test.
The best thing I can think of is to have the harness check for comments,
and report an error at the end if some were missing. Maybe it could
make up a test, so the output looks like:
-
t/real.t.ok
t/foo.t..ok
t/tap_comments...23
# FAIL: t/foo.t test #42 needs a comment
...NOT OK
Failed 1/96 tests, 98.96% okay
Failed Test Stat Wstat Total Fail List of Failed
---
tap_comments 481 23
Failed 1/1 test scripts. 1/96 subtests failed.
Files=2, Tests=96, 4 wallclock secs ( 0.11 cusr + 0.06 csys = 0.17 CPU)
Failed 1/3 test programs. 1/96 subtests failed.
-
This has the added benefit of restricting this test to the developer --
it's unlikely that end-users of your module care about the TAP comments.
I think this would be pretty easy to implement, too.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: OT: cross-platform path handling
I've uploaded a version that works as advertised and runs its test suite successfully on MSWin32, Cygwin, OpenBSD, and Linux. If you happen to have a more obscure OS around, I'd love to hear whether or not it works. (Of course, any other comments are also welcome!) Directory-Scratch-0.09.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JR/JROCKWAY/Directory-Scratch-0.09.tar.gz size: 36142 bytes md5: 7ae1eb53cbe07a6dcb2b5cba9b9c45ac Regards, Jonathan Rockway Jonathan Rockway wrote: BTW, my Directory::Scratch module is meant to solve this problem. At the top of your program you: use Directory::Scratch YourOS and all path names passed to the module are interpreted as though they're from YourOS, even when running on some other OS. This means that you can use UNIX path names in your tests, and they'll work everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS paths, also; but UNIX is the default.) The version of D::S on CPAN right now is kind of embarrassing (got a few patches and applied them even though I felt uneasy about them), but I'll have a fixed version up tonight. So don't try the module yet -- I'll send another note to the list when I'm happy with it :) Regards, Jonathan Rockway (Disclaimer: nothing is broken in the current version, but it does assume that you're using your native OS's paths. So if you don't care about cross-platform usability, go ahead and use it now. In addition, the tests are kind of icky, as are some of the features. YMMV. :) A. Pagaltzis wrote: * David Golden [EMAIL PROTECTED] [2006-09-18 12:30]: Many of the test failures can be attributed to: * non-portable path expectations Btw, is there a chance of Path::Class becoming core? It is *so* *much* better than File::Find, File::Basename, File::Spec and the rest of the entourage it’s not even funny. And it’s also sane, as opposed to IO::All. Regards, signature.asc Description: OpenPGP digital signature
Re: OT: cross-platform path handling
BTW, my Directory::Scratch module is meant to solve this problem. At the top of your program you: use Directory::Scratch YourOS and all path names passed to the module are interpreted as though they're from YourOS, even when running on some other OS. This means that you can use UNIX path names in your tests, and they'll work everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS paths, also; but UNIX is the default.) The version of D::S on CPAN right now is kind of embarrassing (got a few patches and applied them even though I felt uneasy about them), but I'll have a fixed version up tonight. So don't try the module yet -- I'll send another note to the list when I'm happy with it :) Regards, Jonathan Rockway (Disclaimer: nothing is broken in the current version, but it does assume that you're using your native OS's paths. So if you don't care about cross-platform usability, go ahead and use it now. In addition, the tests are kind of icky, as are some of the features. YMMV. :) A. Pagaltzis wrote: * David Golden [EMAIL PROTECTED] [2006-09-18 12:30]: Many of the test failures can be attributed to: * non-portable path expectations Btw, is there a chance of Path::Class becoming core? It is *so* *much* better than File::Find, File::Basename, File::Spec and the rest of the entourage it’s not even funny. And it’s also sane, as opposed to IO::All. Regards,
Re: A Suitable Iterator for TAPx::Parser
You of course are aware of what a pain it is to apply this logic?
Yes, which is exactly why you shouldn't mess around with references
where they're not necessary. I suggest:
my $foo = Foo::Bar-new({path = $path});
or
my $foo = Foo::Bar-new({data = $data});
Foo::Bar::new looks like:
sub new {
my $class = shift;
my $args = shift; # or you could do
# eval { %args = @_ }; croak ... if $@
my $self = {};
if($args-{data}){
$self-{data} = $args-{data};
}
elsif($args-{path}){
open(my $fd, '', $args-{path}) or die ...;
$self-{data} = do { local $/; $fd };
}
else {
# informative error message
die Foo::Bar::new: blah blah blah RTFM;
}
}
--8---
This makes it very clear exactly what is going on, and prevents any
confusion with what gets stringified where. Feel free to come up with a
better name than data though. (I like it, others don't.)
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: post-YAPC::Europe CPANTS news
I could be wrong here, but I think the check is to make sure that tar doesn't set +x on Makefile.PL or Build.PL, thus forcing the user to run the proper version of perl instead of automagically running the perl that shebang points to. (Example: Makefile.PL says #!/usr/bin/perl, but you really want to run /home/jon/blead/bin/perl. Forcing you to type this out is a good thing.) I personally don't see the value of this, I always run perl Makefile.PL anyway. Do +x *.PL files cause problems with CPAN installs? (Or am I completely wrong in my interpretation of this test? :) Regards, Jonathan Rockway chromatic wrote: On Wednesday 06 September 2006 02:53, Thomas Klausner wrote: - buildtool_not_executable Check if the buildtool (Makefile.PL, Build.PL) are not executable (and thus need to be called with 'perl Build.PL' thereby specifying which exact version of Perl you want) I'm not sure of the value of this one; how does an author make the buildtool executable on Windows, for example? I have the impression (not using Windows) that users must always call the tool with 'perl Build.PL' on such platforms. Am I mistaken? -- c
Re: Kwalitee metric: Broken Installer
I see two resolutions to this problem: 1) Module authors need to re-release their modules whenever Module::Install is updated. This is extremely inconvenient, but not a terrible demand. If other authors are like me, they accumulate small minor changes to their modules, and then release when something important comes along. A new M::I is important and would force us to keep our stable CPAN modules up-to-date with our svn repositories or whatever. That's a good thing ;) , but probably not the right way of going about it. (For the record, all my M::I modules use the latest version, and I went to no special effort to ensure that. So maybe this isn't as hard as it sounds.) (The right way of going about this, BTW, is out of the scope of this e-mail... but I do have some ideas...) 2) Get M::I into the core of perl, so that everyone has a known-good tested-everywhere version. This is the best idea. CPAN works so well because everyone has it and it's a good piece of software (lately CPANPLUS has gotten rather buggy and I've gone back to regular CPAN!). The other solutions (like kwality or whatever it's called) are stopgap measures that don't fix anything. Anyone that knows about the kwality site probably reads this list ;) and knows to update M::I anyway. The other 90% of the modules are one-offs whose authors have better things to do, probably, than re-release their module whenever a point release of some obscure dependency is released :). For the time being, maybe someone just needs to download the broken modules, fix the inc directory, and upload them back to the CPAN ;) That would actually solve the problem. (And introduce many others, but...) Actually now I see a third resolution: don't use M::I for CPAN modules. CPAN (the software) handles dependency installing, it's standard with perl, good enough. I do like M::I, I just can't think of why it's really necessary for CPAN modules. (For non-CPAN perl packages, though, it's a GREAT idea.) Regards, Jonathan Rockway I don't think I like it. It makes me nervous for some reason... For example, who's to say what constitutes a bad version of an installer (actually, this only applies to M::I, since the other installers aren't generally bundled, but I don't mind defending M::I here). In this case, you've declared every version prior to some arbitrary release to be bad. I doubt that is the case. I think there might have been problems with one or two releases, but being an old release is not the same as being a flawed release.
Re: Fw: Fixing SKIP:
I retract my previous comment. My prototype was, in fact, completely bogus :) Let's make that array a reference to a list and everyone will be happy: can_ok($object, [qw(foo bar baz)], 'reason'); Hopefully that works and makes sense. If !ref $_[1], then just treat it as a single method name. Everyone's happy :) Time for sleep! Regards, Jonathan Rockway Jonathan Rockway wrote: I do not think that prototype means what you think it means. It means what I think it means. Same syntax as we have currently, no. You would have to do this: my @methods = qw(foo bar baz) can_ok($object, @methods, 'reason') Instead of: can_ok($object, qw(foo bar baz), 'reason') Note that in my original post I specified array instead of list for a reason :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Fw: Fixing SKIP:
I do not think that prototype means what you think it means. It means what I think it means. Same syntax as we have currently, no. You would have to do this: my @methods = qw(foo bar baz) can_ok($object, @methods, 'reason') Instead of: can_ok($object, qw(foo bar baz), 'reason') Note that in my original post I specified array instead of list for a reason :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Fw: Fixing SKIP:
Re-reading the man page, it looks like isa_ok and can_ok can't even accept a test description? can_ok cannot accept a description because it accepts a list. This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]). What's the reasoning behind accepting an array, anyway? Can't you just do: can_ok($object, $_, can object $_?) for @methods; This would then run (scalar @methods) tests, but I'd think you'd want that anyway. It doesn't make sense for a test for -can(foo) to fail when -can(bar) fails. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Time for a Revolution
Or, perhaps we need the Perl CPAN Cookbook -- which would be like the Cookbook but focuses *only* on the greatest-hits modules across all the same categories. If CPAN is one of Perl's greatest strengths, shouldn't that get more attention, too? Er, right. Now let me don my editor hat. Authors welcome! A book like this is something that's been in the back of my mind for a while. If there were real interest in this topic (and I think there is), I would be happy to help out in a significant way, like writing several chapters. If someone is interested, maybe we can hash out a ToC / outline and submit a proposal to O'Reilly? That would be pretty neat :) Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
While I agree with David, this argument is almost completely pointless. Nobody reads the raw TAP output! If you want your TAP harness to display got and expected, let it. If you want it so say foo and bar (so they line up :-P), then great. The actual TAP is going to live in a protocol document for implementers to read. The end-user will likely be using a harness and Test::More (or $LANGUAGE_OF_CHOICE equivalent), so this doesn't matter at all. TAP will be equally useful whether or not we use got and expected. When was the last time you netcat'd to slashdot to get the list of articles? Never? Exactly -- because you have software to handle the protocol for you. (Yes, yes, people telnet to port 80 and type GET / or whatever to debug their server. But it's not normal behavior, and 99.99% of HTTP users have no idea what an HTTP header even is.) Regards, Jonathan Rockway David Landgren wrote: demerphq wrote: On 7/12/06, Smylers [EMAIL PROTECTED] wrote: David Landgren writes: Expected and actual has a long tradition in scientific endeavour, And are still sucky as they are different lengths meaning the two outputs are offset on the screen making it harder to see the failure. Yves, that is absolute nonsense. The current output already has it that way: % perl -MTest::More -e 'plan(tests = 1); is(slothrop, porpentine)' 1..1 not ok 1 # Failed test in -e at line 1. # got: 'slothrop' # expected: 'porpentine' # Looks like you failed 1 test of 1. They look lined up to me. They strike me as the teams most intuitively recognizable and least open to misinterpretation. I choose to disagree. I think its more important to instantly see the difference between two simple outputs than it is to use the most absolutely appropriate terms. But you cannot instantly see with what you suggest, since the two words are *exactly the same length*! With 'expected' and 'actual', the lengths are different, that's the whole point. And of course, they would be appropriately right-justified to line up their values. Also how can people misinterpret: Want: X Have: Y They are not very typographically distant. David
Re: TAP diagnostic syntax proposal
are you serious? listen to what they people here are saying - we _all_ read the raw TAP output, all the time, and not because we're TAP developers interested in the underlying implementations. as users, the (current) raw TAP diagnostics helps us figure out why a test failed, and if it doesn't make sense due to bad wording or reversed expectations then it's that much harder than it needs to be. No, you're reading diagnostic output that your program prints. got and expected aren't part of TAP, they're comments in the TAP stream that some emitters emit and that harnesses print. Look at the TAP grammer here: http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg There's no got or expected part of TAP, there's ok 1 not ok 3, 1..34, and # this is a comment. So if we're going to add this to TAP, which I think is the whole point of this thread, then it doesn't matter what it's called. Your tap parser just needs to pick out a token, and throw a certain event if it finds that. It's up to the TAP harness (a level or so above the lexer/parser) to print got: foo expected: foo. So if you don't like got or expected, that's fine, just change the harness. I'm sure in some instances there won't be even be a line like that printed -- there will be a HTML table or something. That's the advantage of making these part of the TAP protocol; you won't have to worry about the semantics of got or expected... that will all be handled for you by the parser and then be presented nicely. To summarize, right now got and expected are artifacts of Test::More (etc.), not the TAP protocol. Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
wow, my code is being used in a flame war! *blush* :-) Sorry! I didn't want this to come across as a flame. I just wanted to make sure I (and other people ;) have the distinction between TAP and uses of TAP clear in their minds. The sooner we can agree over what the protocol should call got and expected, the sooner we can write a TAP harness that conveys that meaning to the end-user in whatever language they prefer. :) To summarize. What TAP uses is irrelevant, as long as it works. What the Harness prints is relevant, but easy to fix any time. No worries about TAP 1.0 vs. TAP 1.1, just download the new Test:Harness from CPAN and everything will work. Right? Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
Did you guys consider the problem of newlines in content? This is a good question. Implementing your own file format means you have a big-bag-o-quoting problems. How do you print a verbatim newline? What about a verbatim single quote? What about Unicode? What about a new line then not ok - ++$counter? :) http://cr.yp.to/qmail/guarantee.html says: When another programmer wants to talk to a user interface, he has to /quote/: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data. This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way. Things to think about :) Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
I can see why we wouldn't want to include YAML, and won't cry for *too long* if it doesn't go in ;), but here are some reasons why I'd like for full YAML to be a part of the spec: - marshaling data structures between the application being tested and the test harness (strings are nice, but full Perl/!!YAML objects are nicer) - infinite extensibility (then again, it was a little bit too easy for people to add proprietarytag to HTML, and look at what that got us) I just think having all of YAML at our disposal would let test authors and test harness authors do pretty much anything they want. YAML is pretty hard to parse, but fortunately the Hard Work has been done for us. YAML::Syck supports all the YAML we need and it has bindings for pretty much every language. I wouldn't call it lightweight, but the 300k of additional memory it uses is worth the potential benefits. I dunno, maybe I *am* overthinking this. It's just TAP. I guess what I really want is for the perl interpreter to be able to serialize itself so I can debug failing tests more easily. That's not really a TAP issue,though :) Regards, Jonathan Rockway Adam Kennedy wrote: Whoa whoa whoa slow down there folks... Some people seemed to have misrecognised those keys as YAML. It was NEVER meant to be YAML. The idea was to use something more like MIME headers. We all agreed that we DIDN'T want the format to be too heavy, and going with MIME or MIME-alike seemed the sweet spot in terms of ease of parsing and standardization vs extensibility. Having YAML in the TAP spec would complicate things greatly, especially as the YAML spec includes things like multi-line strings. And it would mean that we'd have to deal with YAML error events, JSON-style parsing and a bunch of other things that are problematic. It's NOT ease to parse at all, not compared to the current relative simplicity of TAP at the moment. Adam K Jonathan T. Rockway wrote: not ok 2 - omg t3h sooper test!!1! --- TAP diagnostics file:foo.t Why aren't we commenting the YAML block so that it's compatible with current TAP parsers? I'm thinking something like this: not ok 2 - ensure that foo is equal to bar # --- !!tap/diagnostics # file: foo.t # line: 42 # got: # - !!perl/foobar # key: value # expected: # - !!perl/foobar # key: ~ # etc: (and so on) The commented section is raw YAML goodness, AND this format is compatible with current TAP parsers. I'm liking this a lot, especially since I can use it Right Now (tm) by doing diag(Dump($data)). Any reason this shouldn't be the standard? It's easy to parse, it's easy to read. Would it be acecptable if I patched Test::More to start outputing it's expected/got messages in YAML instead of a plain text format? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: TAP diagnostic syntax proposal
if i recall correctly, syck doesn't handle utf-8/16. does/will tap care about that? That's true -- I think Audrey patched the perl version to work properly, but I forgot that other languages are without that functionality. Ruby doesn't properly support Unicode either, so Unicode support probably doesn't matter to them. (I think Syck is originally a Ruby project, and Ruby has some moral qualm with Unicode, so that's why Syck doesn't work with Unicode.) As for Python, dunno. I do actually do test UTF-8 data structures in some of my tests, so this is actually a relevant concern. I think things will work fine if you're just outputting UTF8 data to your UTF8 terminal, but if you're doing colation or charset conversion (maybe your terminal is EUC_JP for example), then you'll run into problems. This is something to look into, if we want YAML TAP to work for languages other than Perl. What else is TAP targeted to? C / C++ / Java? oh, and while i'm thinking about it, i think it would be wise to include a tap version in the tap header, so as this protocol changes, parsers will have a chance to handle different tap versions gracefully. Good idea.
Re: TAP diagnostic syntax proposal
Aside from the fact that many languages are already using the TAP protocol and we'd create something they *don't* use, what happens when my 4,000 test lines all of a sudden become 16,000 test lines because the format has been changed? Do you pay for CPU time on a per-newline basis? :) Good point, though. If we put YAML in comments then we remain compatible with all past parsers and emitters. However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use YAP (YAML Anything Protocol? :), then most applications would probably never notice. However, emitting a raw YAML stream means that the application can never emit any other output, otherwise the YAML will become invalid. If we use comments and --- yaml ..., then non-TAP output should still be acceptable. OK, you've convinced me. All-YAML TAP isn't a good idea. I might play with it a little more though, just for fun. Regards, Jonathan Rockway
Re: Testing various HTML constructs
Andy Lester wrote: On Jul 8, 2006, at 10:31 PM, Michael G Schwern wrote: If your XPath parser balks at non-XHTML HTML then just run it through HTML::Tidy-clean which will convert it to XHTML. Usually. If usually isn't good enough, you can always write your own HTML converter with HTML::TreeBuilder. I do this in my blog software: http://trac.jrock.us/trac/blog_software/browser/lib/Blog/Format/HTML.pm This has the added advantage of allowing you to remove nasty HTML, if that's relevant in your application. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: TAP extension proposal: test groups
Anything else Any output line that is not a plan, a test line or a diagnostic is incorrect. How a harness handles the incorrect line is undefined. Test::Harness silently ignores incorrect lines, but will become more stringent in the future. This leads me to another question -- what to do about output that the program prints to STDOUT or STDERR? There are some modules that I use that insist on Cwarn-ing whenever something weird happens... will these mess up my tests? (They don't *now*, but that's because Test::Harness is being overly nice.) What would happen if TAP dictated that TAP output be sent to an extra filehandle? For example, prove could open filehandle 3, fork the test process, and collect TAP data on descriptor 3 while the usual program output is written to STDOUT and STDERR. This would make diagnostic output easier; it's just a normal print statement. If you wanted to truly please DJB (with his don't parse mantra), then you could open two extra filehandles, one for 'ok' and one for 'not ok', and print the number of the test mod 256 (i.e. one byte per test, no newline; just the byte) to each handle. If it comes in on pipe one and the number is where it should be, it's a 'ok #', if it comes in on that second pipe, it's a 'not ok #'. Now that I think about it, though, I'm not sure if this causes problems or solves problems. :) Comments? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
