Re: post-YAPC::Europe CPANTS news
Le mardi 12 septembre 2006 à 11:15, Chris Dolan écrivait: On Sep 12, 2006, at 9:24 AM, Salve J Nilsen wrote: Any metric that catches bad things, particularly bad technical things, is going to be just fine. Metrics that try to push good behavior are fraught with trouble, because they start pushing people in odd directions. Do you have an example on this? (Any pointer would be wonderful.) I have two: pod.t and pod_coverage.t. These are pointless to run on an end-user's machine. At best they are redundant to immutable tests already run on the author's machine and just waste processor cycles. At worst they fail and cause false negative test reports. The prevalence of those two tests in CPAN modules is almost entirely due to the influence of CPANTS. At least has_test_pod can be rewritten as no_pod_errors and achieve the same goal (check that the documentation is syntactically correct pod-wise). Since running Test::Pod on all .pm and .pod file doesn't require actually running the code itself, it sound perfectly acceptable for both parties (those who want to check that the pod is correct and those that think that multiple copies of t/pod.t shouldn't clutter CPAN). ... I just had myself motivated enough to write such a metric, when I discovered that Module::CPANTS::Analyse already has a no_pod_errors metric! That makes me wonder about the utility of has_test_pod, since no_pod_errors is even more interesting: we want to give points to people that *have* a correctly written pod, rather than to those who merely try, don't we? -- Philippe BooK Bruhat What everyone wants, nobody gets, What nobody gets, everybody wants. (Moral from Groo The Wanderer #47 (Epic))
Re: Testing code that forks
Le vendredi 14 juillet 2006 à 10:57, Gabor Szabo écrivait: Hi all, what is the current best practices for testing code that forks? I saw there was a recent discussion about patching Test::More to support forking. Is that going to happen or are there better ways to do it? I have tests for code that forks (with tests run in the various processes) in HTTP::Proxy. I use the following code before forking: my $test = Test::Builder-new(); $test-use_numbers(0); $test-no_ending(1); -- Philippe BooK Bruhat Eliminate a problem before it eliminates you! (Moral from Groo The Wanderer #65 (Epic))
Re: Unintended consequences
Le samedi 27 mai 2006 à 11:50, Michael G Schwern écrivait: If you wanted a way forward from this, a Module::Build::PhoneHome would be nice with its own environment variable, independent of PERL_MM_USE_DEFAULT, to switch it off. Then people can just use it and it will do the right thing, whatever that turns out to be. But then, why phone home ? Just like CPAN testers information is centralised in a mailing-list where everyone can use it and build up stuff like http://cpantesters.perl.org/, that information could be collected by a mailing-list. Léon Brocard started something like that 3 years ago. What happened to it? http://use.perl.org/~acme/journal/10623 -- Philippe BooK Bruhat Fantasy is a nice vacation but Reality is where you spend your life. (Moral from Groo The Wanderer #44 (Epic))
Re: CPANTS is not a game.
Le mardi 23 mai 2006 à 21:56, Thomas Klausner écrivait: And no, I won't take the fun out of CPANTS. Then why did you filter out the Acme modules from the prereq lists? Mmm? For example, see http://cpants.perl.org/dist/Bot-MetaSyntactic and http://cpants.perl.org/dist/Acme-MetaSyntactic-RefactorCode Both list Acme::MetaSyntactic as a prerequisite in Makefile.PL, but it doesn't appear in the Listed Prerequisites nor in the Modules/pragmas/etc use'd by Acme-MetaSyntactic-RefactorCode lists (and therefore doesn't get its well earned is_prereq point). Another side effect is that CPANTS gives false information. -- Philippe BooK Bruhat Out of the worst can often come the best. (Moral from Groo The Wanderer #57 (Epic))
Re: Private tests
Le mardi 15 novembre 2005 à 15:23, Chris Dolan écrivait: After reading some of the insightful comments posted on my blog, I've been convinced that the private tests should be included in the CPAN distribution, but disabled in some way (perhaps via a file extension other than .t?). That way, resourceful or interested users can run the tests but average users don't need to. What about a special environment variable, like RUN_PRIVATE_TESTS? -- Philippe BooK Bruhat When you do not think for yourself, no one thinks for you... (Moral from Groo The Wanderer #61 (Epic))
Re: kwalitee: drop Acme?
Le jeudi 08 septembre 2005 à 10:45, Ovid écrivait: Myself, I was happy to see CPANTs and I knew I put out good quality code, but in retrospect, I do see from the metrics that there are some areas where I can improve. I do wonder, though, why Acme:: files are included in there. The very nature of these modules frequently guarantees that Kwalitee scores will be dragged down. Taking a less than random example: Acme::Code::Police Take a less random example: Acme::MetaSyntactic CPANTS Score: 17 We should at least throw the poor module author's a bone and leave Acme:: out of this. Hey! that would decrease *my* score! ;-) -- Philippe BooK Bruhat History is made by the winners and written by those with the loudest voices. (Moral from Groo The Wanderer #10 (Epic))
Re: HTTP::Recorder
Le mardi 12 juillet 2005 à 19:35, Ian Langworth écrivait: I'd like to improve HTTP::Recorder. I've contacted Linda Julien (http://search.cpan.org/~leira/) via her CPAN email address, but I've received no response. The module hasn't been touched in over a year and every RT ticket seems to have gone unanswered (http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTTP-Recorder). Suggestions? As the author of HTTP::Proxy, a tool used by HTTP::Recorder, I'd be very happy to help. :-) A while ago, I discussed with Linda about using filter objects rather than a LWP::UA subclass for HTTP::Recorder, and she told me that the first version of HTTP::Recorder actually used filters. I think that using filters may be more appropriate (though I can't prove it right now :-). For instance, you could make HTTP::Recorder only record some sites, and not everything you visit. I've also fiddled with the idea of having a more general HTTP::Proxy::Filter class, that would contain both a HTTP::Proxy::HeaderFilter and a HTTP::ProxyBodyFilter, for complicated needs that must work both with the headers and the body. Follow-up to the HTTP::Proxy mailing list. PS: There is also a HTTP::Recorder mailing-list, but I do not know if it's still alive. -- Philippe BooK Bruhat Destroy the little and you destroy the large. (Moral from Groo The Wanderer #55 (Epic))
Re: reporting bugs to RT
Le mercredi 05 mai 2004 à 17:16, Andy Lester écrivait: On Thu, May 06, 2004 at 12:44:58AM -0200, Gabor Szabo ([EMAIL PROTECTED]) wrote: I guess this answer also means that there is no script similar to perlbug that would report bugs about CPAN modules ? Wouldn't this help increasing the use or RT ? Not everyone uses RT. Many authors ignore it, I'm sure. I wonder if rt.cpan.org is broken. I'm trying to close ticket #2658 for Log::Procmail, but I can't tell rt when it's been fixed, since it show only version 0.01 to 0.05, when CPAN already holds 0.08 (0.06 and 0.07 have come and gone, since I try to tidy up behind me). What's happening? Did I remove distributions too quickly from CPAN? -- Philippe BooK Bruhat Friends are people who are there when you need them. (also applies to dogs) (Moral from Groo The Wanderer #43 (Epic))
Re: [ANNOUNCE] Devel::Cover 0.35
Le lundi 08 mars 2004 à 22:44, Paul Johnson écrivait: Probably the most important change is that Devel::Cover will now work with programs that turn on tainting. I gather this is important for Phalanx. Hi Andy! Does Devel::Cover work with programs/modules that fork a lot? I tried to use Devel::Cover to have a peek at how my test suite covered my module's code. I just did what the documentation said: cover -delete HARNESS_PERL_SWITCHES=-MDevel::Cover make test cover But I did get an empty report. Did I forget something? I tried that with Devel::Cover 0.31 (I think) and HTTP::Proxy version 0.12. I'm sorry I didn't try yet with a newer version of Devel::Cover. -- Philippe BooK Bruhat The only certain bet in gambling is that it leads to more gambling (Moral from Groo #11 (Image))
Re: Distributed testing idea
Le lundi 23 février 2004 à 14:06, Michael G Schwern écrivait: I'm going with just straight, unsecured socket communications and an ad hoc protocol. At this point, encryption is not necessary. There's nothing worth encrypting. To see why, look at the example protocol conversation at http://www.makemaker.org/wiki/?AutomatedTestDistribution Its really that simple. Here are a few questions and proposals: * didn't you swap server and client in your example? * I plan to set up several boxes for testing (when I get one of those round tuits ;-), but I only have one IP. It would be great if the protocol could let the server be a front end to several smoke boxes. - the easiest way would be for the server to act as a client for the other smoke boxes (but that implies the test would be run on all available platforms) - or maybe the protocol could support having the server inform the client of what's available, and let the client decide There's still a need for server-to-server communication... - maybe it's not to much to ask that the various test platforms can access the web via a proxy. So that URLs could be passed around easily. * couldn't the work be done asynchronously? - so this part of the protocol would be useless: Server: Great. Hang around. Client: Waiting. Server: Please hold. Client: Waiting. ... - information about what went right or wrong would be sent back via email. Since we are talking of smoke boxes, the clients should be able to fetch the emails via POP3 or whatever. And get the useful information from them. - a client would connect to a test server and ask: Client: what test platform do you manage? Server: X1/Y1/Z1 X2/Y1/Z2 ... Client: (checks its matrice) Great. Test the code at this URL on the following platforms X2/Y1/Z2 X3/Y3/Z3 Server: OK - since you talk about a central repository of public keys, and testing platforms, the client does not really need to ask what's available, since the information should be cached in the central repository. So ideally, a script could check all the available test platforms from the central repository and contact only the server it wants. - the central repository would then just be a client that regularly ask for the available test platform on each of the server it knows and trust. * the reports could be send by email, but also be made available from the server. - For example, the client would say: Client: Test the code at this URL on the following platforms X2/Y1/Z2 X3/Y3/Z3 Server: X2/Y1/Z2 will be report number 1234 X3/Y3/Z3 will be report number 1235 - So the client could also fetch the report from the server by asking for its number. Or all the reports could also be stored in a central place (think Cc:), but then we need a scheme for unique report ids. - the central repository could also fetch the test reports regularly, rather than waiting for email (for example if we don't trust emails). The conversation could then be something like: Client: Any reports after xxyyzzz-1234? Server: Yes. I have: xxyyzzz-1235 xxyyzzz-1236 Client: Gimme xxyyzzz-1235 Server: Here goes: ... Client: Gimme xxyyzzz-1236 Server: Here goes: ... If you need help for coding parts of your client/server/protocol (no matter how much you like or dislike my proposals), I'd love to help. Small chunks, if possible, so that I can deliver on time. :-) -- Philippe BooK Bruhat Wisdom cannot be bought. It can, at best, be rented until you can find your own. (Moral from Groo The Wanderer #66 (Epic))
Re: Distributed testing idea
Le mercredi 11 février 2004 à 13:24, Michael G Schwern écrivait: So what I need is some way to set up a network of test servers such that I can say test this module for me and my testing client would ship it to as many test servers as it can find and get the results back all in just a few minutes. Yet another useful thing would be that the web test server could act as a gateway to several tests servers. For example, imagine someone that has several hosts, each having several Perl versions on their home network. There is only one IP leading to this network, so one web server should be enough to ask for the distribution to be tested on one or several of the available targets. -- Philippe BooK Bruhat Few things in life are so dependable as the incompetence of those who know precisely what they are doing. (Moral from Groo The Wanderer #5 (Pacific))
Re: JavaScript/Perl Question
Le jeudi 29 janvier 2004 à 07:22, Ovid écrivait:
--- Tony Bowden [EMAIL PROTECTED] wrote:
On Tue, Jan 27, 2004 at 10:37:48AM -0500, Potozniak, Andrew wrote:
To make a long story short I can not get access to the source of
the bottom
frame through JavaScript because of an access denied error.
This is a security feature in most browsers -
Andrew,
Hate to say it, but Tony's right. I've run into this before and the
problem is not insurmountable, but it means that you have to have your
app running on a server.
Or that you need a proxy that'll modify the page on the fly (by adding
the javascript you need).
My pet module HTTP::Proxy (available on CPAN) can help you do this. :-)
I suppose you mostly need a filter that'll add the necessary code to
load the javascript somewhere near the opening body tag of each and
every text/html response.
The code of such a proxy is as simple as:
use HTTP::Proxy;
use HTML::Parser;
use HTTP::Proxy::BodyFilter::htmlparser;
# define the filter (the most difficult part)
# filters not using HTML::Parser are much simpler
my $parser = HTML::Parser-new( api_version = 3 );
$parser-handler(
start = sub {
my ( $self, $tag, $text ) = @_;
$self-{output} .= $text;
$self-{output} .= YOUR JAVASCRIPT HERE if $tag eq 'body';
},
self,tagname,text
);
$parser-handler(
default = sub {
my ($self, $text) = @_;
$self-{output} .= $text;
},
self,text
);
# this is a read-write filter (rw = 1)
# that is the reason why we had to copy everything into $self-{output}
my $filter = HTTP::Proxy::BodyFilter::htmlparser-new( $parser, rw = 1 );
# create and launch the proxy
my $proxy = HTTP::Proxy-new();
$proxy-logmask( 1 ); # terse logs
$proxy-push_filter( response = $filter, mime = 'text/html',
host = 'www.example.com' );
$proxy-start();
And now you have all the javascript you need added to the HTML pages
you want. There is also a 'path' parameter to the push_filter() method,
you you want to add the javascript only to parts of the web site.
Note: I'm not very proud of the way I plugged HTML::Parser objects
into HTTP::Proxy. But HTML::Parser uses callbacks, just as HTTP::Proxy
(LWP::UA, actually) does. If anybody has better ideas, I all ears.
--
Philippe BooK Bruhat
Your reputation is what you make of it... and what you choose to take with
you. (Moral from Groo The Wanderer #48 (Epic))
Re: WWW::Mechanize 0.37 released
Le mercredi 05 mars 2003 à 19:38, Robert Spier écrivait: There really aren't many tests that are meaningful without that access. 00.load.t, 99.pod and add_header.t are all that seem to be valid without it. You could allow the user to choose between internal and external tests, where the internal tests are much simpler, maybe including a trivial self-contained webserver to make sure everything works. The server could be a HTTP::Daemon. That's how I test the basic workings of HTTP::Proxy. Some tests use google.com and other webservers. They can be skipped if the test script detects that for some reason the web does not work. (Oops, I seem to remember this is in version 0.08, which is not out yet. You can fetch a repository snapshot from http://http-proxy.mongueurs.net/ Have a look at t/22http.t and t/Utils.pm) -- Philippe BooK Bruhat Friends are people who are there when you need them. (also applies to dogs) (Moral from Groo The Wanderer #43 (Epic))
Re: WWW::Mechanize 0.37 released
web_ok();
+
ok( $t-get(http://www.google.com/intl/en/;)-is_success, Got Google );
is(scalar @{$t-{page_stack}}, 0, Page stack starts empty);
$t-_push_page_stack();
@@ -21,3 +25,4 @@
is(scalar @{$t-{page_stack}}, 0, Popped item from page stack);
$t-_pop_page_stack();
is(scalar @{$t-{page_stack}}, 0, Can't pop beyond end of page stack);
+}
--
Philippe BooK Bruhat
When you wander near evil, Security is only a function of foolishness...
(Moral from Groo The Wanderer #21 (Epic))
Re: WWW::Mechanize 0.37 released
Le mercredi 05 mars 2003 à 19:38, Robert Spier écrivait: There really aren't many tests that are meaningful without that access. 00.load.t, 99.pod and add_header.t are all that seem to be valid without it. You could allow the user to choose between internal and external tests, where the internal tests are much simpler, maybe including a trivial self-contained webserver to make sure everything works. The server could be a HTTP::Daemon. That's how I test the basic workings of HTTP::Proxy. Some tests use google.com and other webservers. They can be skipped if the test script detects that for some reason the web does not work. (Oops, I seem to remember this is in version 0.08, which is not out yet. You can fetch a repository snapshot from http://http-proxy.mongueurs.net/ Have a look at t/22http.t and t/Utils.pm) -- Philippe BooK Bruhat Friends are people who are there when you need them. (also applies to dogs) (Moral from Groo The Wanderer #43 (Epic))
Re: WWW::Mechanize 0.37 released
web_ok();
+
ok( $t-get(http://www.google.com/intl/en/;)-is_success, Got Google );
is(scalar @{$t-{page_stack}}, 0, Page stack starts empty);
$t-_push_page_stack();
@@ -21,3 +25,4 @@
is(scalar @{$t-{page_stack}}, 0, Popped item from page stack);
$t-_pop_page_stack();
is(scalar @{$t-{page_stack}}, 0, Can't pop beyond end of page stack);
+}
--
Philippe BooK Bruhat
When you wander near evil, Security is only a function of foolishness...
(Moral from Groo The Wanderer #21 (Epic))
Testing across forked processes
Hello, I am trying to test a module, but to that end, I must fork two processes, and the parent and the two kids each perform a series of tests. The output is such: 1..7 ok 1 - The proxy requests what we expect ok 1 - Got what we wanted ok 2 - The proxy requests what we expect ok 2 - Got what we wanted ok 1 - Served the correct number of requests not ok 3 - Got what we wanted # Failed test (t/20simple.t at line 84) ok 3 - The proxy requests what we expect # Looks like you planned 7 tests but only ran 3. (Before you ask: yeah, I know one of the tests fails, I am also investigating this) Each instance of the forked Test::Builder thinks it's all alone in the world, and starts at 1. Which is perfectly understandable. So I tried to add the following lines at the beginning of my test script: my $test = Test::Builder-new; $test-use_numbers( 0 ); But Test::Builder is still confused and only sees the three tests run by the parent process. 1..7 ok - The proxy requests what we expect ok - Got what we wanted ok - The proxy requests what we expect ok - Got what we wanted ok - Served the correct number of requests not ok - Got what we wanted # Failed test (t/20simple.t at line 87) ok - The proxy requests what we expect # Looks like you planned 7 tests but only ran 3. Ooh, I think I get it: the parent process' Test::Builder warns about the fact that it has not seen all tests (since most of them were run by the children). On the other hand, Test::Harness sees everything right, since it's looking at the test script output only. Hence with make test, I simple have garbled output due to the diagnostics. I guess my question is something like is there's a way for the children's test output to be taken into account by the main Test::Builder object? Must I really use some IPC to report back to the parent process' Test::Builder object? Or is it considered ok just to have the kids spit ok and not ok and to let Test::Harness organise the resulting mess? Be aware that the test results do not look that good (when no test fails): Failed 1/5 test scripts, 80.00% okay. 0/29 subtests failed, 100.00% okay. Not that great. So I guess I'll have to go the IPC way, after all. Any advice or success story? -- Philippe BooK Bruhat Even the worst guesser is right once in a while. (Moral from Groo The Wanderer #72 (Epic))
