Re: CPANTS Site Seems... Confused
Randy J. Ray a écrit : I've only taken a cursory look at the internals of the Module::CPANTS::Analyze code, but I noticed that if there is neither Build.PL or Makefile.PL, you can still trigger an executable build file flag-- line 101 of Module::CPANTS::Kwalitee::Files.pm uses the same internal field to indicate this lack as is used to indicate that they're executable. This, combined with the fact that most or all of the other red flags seem to be centered around file issues, leads me to suspect that maybe whatever area the distros are being un-tarred into is having disk issues? If you have already installed Module::CPANTS::Analyse, then you can use the cpants_lint script to locally check the CPANTS metrics of your distribution before uploading. This makes the game *much* easier ;-) For example: $ cpants_lint ../releases/Win32-Mock-0.04.tar.gz Checked distWin32-Mock-0.04.tar.gz Kwalitee rating 112.50% (27/24) Failed optional Kwalitee tests and what you can do to solve them: * prereq_matches_use List all used modules in META.yml requires * build_prereq_matches_use List all modules used in the test suite in META.yml build_requires -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Smoking private dists?
Thomas Klausner wrote: And I presume that the various CPAN smoking tools don't fit my needs, because they are designed to either smoke the whole of CPAN, or to send back test results after installing a given CPAN dist. Remember that you can always bind your own local view of the CPAN with CPAN::Mini and CPAN::Mini::Inject » http://search.cpan.org/dist/CPAN-Mini-Inject/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: New proposed CPANTS metric: prereq_matches_use
Thomas Klausner wrote: I'm currently thinking about a new CPANTS metric (and I even have a half-finished implementation..), and I'd like to get some feedback on it, before spending more time on it (or even releasing it..) The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) As you might know this is quite tricky, because some modules live in strange dists (e.g. HTTP::Request - libwww-perl) There was already a module that does this, I can't remember it's name, and it insisted that each module after a use was listed in PREREQ_PM, which was quite bothersome because it wanted both LWP and HTTP::Request to be listed for example. and some modules are in Core (I'll check this with Module::CoreList). Each time I here checking with Module::CoreList, I wonder which version will be tested against. [...] What do you think? +1 for the rest -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Devel::CheckLib: Please try to break our code!
Hello David, I should have answered your mail earlier, but I keep forgetting things.. David Cantrell wrote: NB: this has been sent to several mailing lists. Watch those replies! Dave Golden and I have been hacking on Devel::CheckLib, which should be on a CPAN mirror near you soon. It's similar to Devel::CheckOS, in that it will let module authors specify dependencies which aren't just other perl modules - if they need, eg, libjpeg, then they can use this module in Makefile.PL / Build.PL to make it a pre-req, and if it's missing then the CPAN testers will SHUT THE HELL UP ABOUT IT and not annoy the author. It's still in something of a state of flux so not ready for real- world use yet, but we're at the stage where we need lots of people to beat it to hell and back. Please try to run the tests on as many platforms as possible, with as many perls as possible, and in particular using perls built with as many compilers and linkers as possible. I had begun working on a module like this last year. It would have been part of the refactoring of the Makefile.PL of Net::Pcap, itself borrowed from XML::LibXML's, then improved. The first part is already on the CPAN as the module ExtUtils::FindFunctions, which tries to detect the functions present in a library. The second is is ExtUtils::FindLibrary, not yet released, which is mainly the have_library() function in Net::Pcap Makefile.PL. It's more heavyweight than the code current present in Devel::CheckLib, but it works nice on Unix, Win32 and Cygwin given that Net::Pcap only had PASSes for the last stable releases. The more alert of you will have noticed that there is a bootstrapping problem in using this from within a Makefile.PL - relax, it will come with a script to bundle itself in an inc/ directory. ExtUtils::FindFunctions and ExtUtils::FindLibrary do this as well with their included commands. The code is simple but you can copy it if you want. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Test::Kwalitee
Nathan Haigh wrote: I hope this is the correct place for this question! I'm trying to use Test::Kwalitee with the following test script: Note that the script can be simplified to use strict; use Test::More; plan skip_all = Test::Kwalitee required for checking distribution kwalitee unless eval use Test::Kwalitee; 1; I use similar scripts for Test::Distribution, Test::Pod, Test::Pod::Coverage, Test::Portability::Files and the like. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: a safer way to use no_plan?
David Golden wrote:
More often, I find myself creating some data structure to define test
cases and then:
plan tests = $fixed + $tests_per_case * @cases;
Once I've defined the basic tests, I'm usually adding cases rather
than changing the per-case test count, so the total test count takes
care of itself.
I often use this solution, and, for the test scripts that don't fit
this, I usually count tests by small blocs, letting Perl calculate
the total:
use Test::More;
my $tests;
plan tests = $tests;
BEGIN { $tests += n }
# paragraph of code with n tests
BEGIN { $tests += m }
# paragraph of code with m tests
# etc
That's very simple and when adding new tests, I only have to update
the number of tests in the BEGIN that immediately precedes the
corresponding code.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: a safer way to use no_plan?
Dominique Quatravaux wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Lester wrote: Good Lord do I get frustrated at the handwringing over test counting. Look, it's simple. You write your tests. You run it through prove. You see how many tests it reports. You add it at the top of the file. Voila! And what if you are running a variable number of tests depending on stuff such as compile-time options, maintainer mode enabled or not, or whatever? So what? Just skip the tests you can't execute under these conditions, it's precisely here to address such issues. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Module proposal: Syslog::DevKit
Brad Lhotsky wrote: I'm in the process of implementing a large scale central syslog architecture based on syslog-ng and POE. syslog-ng buys me compliance while I finish building my custom correlation engine with POE. If you're trying to implement a syslog server in POE, did you take a look at POE::Component::Server::Syslog? » http://search.cpan.org/dist/POE-Component-Server-Syslog/ (And if the programs emitting syslog messages are in Perl, I strongly advice you to upgrade to the latest CPAN version.) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Module::Build and the Test Harness Report in the CPAN Testers
Shlomi Fish wrote: Hi all! Hello Shlomi, Yuval Kogman claimed that Module::Build generates CPAN testers reports with no output from the test harness. Now, I released Math::GrahamFunction, which is based on Module::Build, a few days ago and today received this failure error report: http://nntp.x.perl.org/group/perl.cpan.testers/397523 And indeed it does not contain the output of the test harness. Is this a known problem with Module::Build? Is it intentional, or are people otherwise working on resolving it? Is there anything I can do about it? This is a known issue. See ticket CPAN-RT#9793 » http://rt.cpan.org/Public/Bug/Display.html?id=9793 -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: which modules can be used on an older version of perl?
Gabor Szabo wrote: On 12/4/06, Michael G Schwern [EMAIL PROTECTED] wrote: David Romano patched up Test-Simple to restore 5.4.5 compatibility. I'll see about releasing that as 0.66. That might make a whole lot more of CPAN happy on 5.4.x. PS I don't see 5.4.5 in your list. sqlite select count(*) from reports where perl LIKE '5.4.5'; 0 that's from the cpantesters database. Maybe your database is incomplete because I know I've sent a few reports with 5.004_05 » http://www.nntp.perl.org/group/perl.cpan.testers/259982 » http://www.nntp.perl.org/group/perl.cpan.testers/281901 But I note that on the reports page, they incorrectly appear as 5.4.4. (Also note that to make Test::Reporter work with old Perls, you need the patch from CPAN-RT#14148) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Modules dealing with data files
David Landgren wrote: [...] Does that sound sane? Does anyone have some pointers on how to deal with the placement of datafiles on the local system with one module, and having the other module know where to find them? Or am I making this unnecessarily complicated? (I could just bundle the data file with the distribution, but the size of the data file, and the probability that the format is unlikely to change invites the above approach). Adam Kennedy wrote Data::Package after discovering fake modules that actually are just data. Not sure if it solve your problem: http:// search.cpan.org/dist/Data-Package/ Preferring simple solutions, I'll tend to use the traditional way for this: put the data in raw form alongside the Perl module, and find it in %INC. And I would also include the data with the distribution in order to avoid the internet access problem. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Modules dealing with data files
Sébastien Aperghis-Tramoni wrote: [...] Er, sorry for mixing things up; my previous mail should have been sent to module-authors@perl.org, not to [EMAIL PROTECTED] -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: todo tests in the TAP Plan
Selon Ovid [EMAIL PROTECTED]: As one can see, the 1..5 plan is followed by the todo 3 2; directive. This is supposed to indicate something about plan ahead todo tests. [...] I'd like to know what I should do about this feature, because right now I'm trying to convert Test-Run to use TAPX::Harness, and this is giving me problems. Hmm, that's curious. However, if it's undocumented I would argue against supporting it right now. What benefit does it gain us? This comes from the Good Old Test.pm module: $ perl -MTest -e 'plan tests = 10, todo = [2,4];' 1..10 todo 2 4; As there are quite some test scripts out there that use it, staying compatible with it sounds like a prerequisite. We can only allow the todoList on a leading plan because one on a trailing plan means we can't know the test results until the test run has completed (which would suck in the case of infinite streams). However, even allowing this on a leading plan is still problematic because either the programmer needs to know the test numbers in advance to add that list or the code somehow would need to deduce them. Then, we'd have to started defining the semantics of what happens if we have that leading todoList in case of one of those tests having a SKIP or TODO directive. I'm guessing that means that leading todoList test numbers would be ignored in that case? I would suggest that this is not a feature we want unless we can nail down its intent and semantics quite carefully. Test.pm could only handle predefined test numbers (it doesn't have a no_plan option like Test::More). -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Devel::Cover hackathon
James E Keenan wrote: The ex-typographer in me has to carp, however, at some of the changes in the HTML output. The rules bordering boxes need more attention, as the mixture of light and heavy rules is not very pleasing and, IMHO, a step backward from 0.55. I've posted two screenshots from different browsers to illustrate this: I am the one to blame for this. I changed the CSS a bit in order to lighten up the rendering for the main code view. I agree that with the Html_minimal and Html_subtle reports, the CSS may need a little more work. Attached is a better patch for these reports. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO. Devel-Cover-style2.diff Description: Binary data
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
demerphq wrote: On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on the CPAN. I dont agree with this. Or rather, I dont agree that the core is over-crowded. I do agree that as many modules should be dual-lifed as possible however, but that is just so you can upgrade without upgrading perl. Yes, and if some of these modules can be made to work on older Perl as well with one- or two-lines patches, isn't it even better? :-) Personally i think the core is too big argument is a red-herring given that bandwidth is as cheap as it is these days. Adding a couple of modules to core would increase the rsynch time by what a second or two? It would suck up a couple of extra K, something like 1% of what most of use for our web-browser cache. So the size argument IMO doesnt hold water. I don't think that the problem of core is too big is a matter of disk size, but more a matter of number of modules. P5Porters time is a scarce ressource, and they already lack the time to do all the work they'd like to do just on the interpreter. Making core modules dual-life is a way to handle these to someone else who has spare time and who doesn't need to have deep XS or Perl guts knowledge. At least I think that's the reason, otherwise why was I accepted as the maintainer of two such modules (XSLoader and Sys::Syslog)? Also, there is a tension in the community relating to this issue that i dont think we will see any resolution of soon. Many module authors set a design objective of making their modules dependent only on core modules. This is a comment that I see on a regular basis. When I hear or read that, I always wonder if the author realised that core modules is something dependant on the Perl distribution version. For example a module as important as Test::More was included in the core in 5.7, which really means 5.8. Maybe the problem is that, like Abigail pointed it in P5P, there were fewer Perl releases in the past years, and more precisely we're at the same branches (5.8 / 5.9) since a long time, therefore reducing the cycle of potential inclusion of new modules. IMO this objecitve is in direct contradiction of the purported P5P objective of not adding stuff to the core and just makes omissions from the core even more critical. Anyway, i just wanted to add this because I dont think that you can take it for granted that all perl5porters believe the core module set should be as restricted as possible. I dont. I believe that the core should contain out of the box enough support for the various platforms that perl runs on that when people write code based only on core modules they can do a good job without reinventing wheels or code duplication. In a sense, my opinion does not really matter here: the facts are that many P5Porters in general, and the Pumpkings in particular, dislike adding new modules to the core, on the basis that installing modules from the CPAN is easy. You're more active on P5P than I am, so I don't have to recall you all the discussions that preceded the inclusion of CPANPLUS and Module::Build, and how making them work everywhere doesn't look an easy task. But note that I don't necessarily disagree with you: I would welcome a Perl distribution that offer more modules, but when I need to write a portable program, that must run on older Perl, the new features in the core can't be used anyway. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Where did I see this use of plan()?
Yitzchak Scott-Thoennes wrote:
I remember working with some module that had tests something like:
use Test::More;
plan tests = numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Didn't see that one, but if you want to simplify the count of the
number of tests, a simple solution is to use BEGIN blocs:
use Test::More;
my $tests;
plan tests = $tests;
BEGIN { $tests += XX }
# bloc of tests
# ...
BEGIN { $tests += XX }
# bloc of tests
# ...
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
Tels wrote: Moin, Hello Tels, OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. You forget that there's more than one way to use Perl :-) When Perl is used for sysadmin tasks, most of the features you listed (and I could add threads support, new IO implementation, signals handling, subroutines attributes) are of no to little use because such Perl scripts are run for executing tasks that do not require advanced Perl features like those just listed. Remember that on Unix systems, Perl is like Bash, Sed and Awk, only more powerful (even if it's by one or two orders). Do you replace your /bin/sh on your Solaris with the latest Bash just because it has very new and cool features? Usually you can't. Mainly because it could break things, and has little to no added value. Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. But the Perl interpreter (which is what the P5Porters are working on) and the Perl modules are mostly disconnected (*). Where would be the interest to use an interpreted language if it were tied to a specific version of the interpreter? Most Perl code out there don't require recent features. To continue with my previous analogy, there are also many people that work hard on the Linux kernel, the GNU system, and all the different parts that compose a GNU/Linux distribution, but when a server is in production, you can't upgrade it at your wish. (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on the CPAN. I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to touch the system? My current $work is to write a Perl program that must execute on about 1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I can't upgrade Perl on these because they have different kernel / glibc / gcc versions. But that's not a problem because I don't need to upgrade Perl or the modules on said systems, just to put the modules I need in a directory and use lib /that/directory. Of course I need to use modules that work with 5.004, or patch them so they work with 5.004, but you could be surprised to see how little some of the patches are. Can be as simple as removing require 5.6 (as for File::Temp). Most of the patches I've sent were less than 10 lines of differences. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Request for Comments: Package testing results analysis, result codes
Barbie wrote: 12. System is incompatible with the package. Linux::, Win32::, Mac:: modules. Irreconcilable differences. Not sure how you would cover this, but point 12 seems to possibly fit. POSIX.pm is created for the platform it's installed on. A recent package I was testing, File::Flock (which is why I can't install PITA) attempted to use the macro EWOULDBLOCK. Windows doesn't support this, and there doesn't seem to be a suitable way to detect this properly. This is just one example, I've come across others during testing. Also note that the name alone does not signify it will not work on other platforms. There are some Linix:: distros that work on Windows. Same with some Mac:: and Win32:: modules that perfectly work on other platforms because they're pure Perl modules. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Default tests, beta testing, etc.
Bryce Harrington wrote: Default tests - Like probably a lot of perl module writers, I don't write tests nearly as often as I should, but I have collected a few simple default tests that I can toss into a new module and reuse without modification. For example: http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/00_initialize.t A similar one is created when creating a distribution with Module::Starter. http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/ 01_script_compile.t http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/zz_dump_config.t It would seem to be useful if CPAN were to have a couple really basic tests like this to run for perl modules that haven't created any tests themselves. Might be useful, but you can unfortunately assume very little as you don't know anything about the distribution. For example, Test::Distribution (as someone else mentioned it in another mail) is very useful, but doesn't work in every cases. I had to disable some of its tests for some of my modules because of the way the distribution are made. Beta testing - CPAN tracks intra-module dependencies, and does automated testing, but only on released modules. It would seem useful to allow an author to upload a beta version of their module, and then run the tests of a dozen or so modules that depend on it. This way, you would gain confidence that your next release won't break everyone else's code (or be able to explain why, if it must.) Using CPANTS to know what modules depend upon yours and PITA for the testing subsystem will be a way to test such things. Obviously, this testing would mostly just benefit core modules, but you could argue that those are probably the ones most in need of solid QA. This could save worry time for the core module authors, allowing them to focus more of their energy into improvements. For core modules, there's already a better system: we can send patches to P5P and ask for test on the smoke boxes. They cover more systems than CPAN Testers, including commercial Unix like Solaris, HP/UX and AIX, and even rare systems like OSF and VMS. I imagine this process could become extremely invaluable for doing large scale upgrades to bring modules forward into Perl 6. For instance, if it is decided to switch MakeMaker or other low level modules, then the ability to programmatically generate patches to upgrade modules would probably help push authors to upgrade their modules much faster. For core modules, there're only two words: backward compatibility. Micheal Schwern has already expressed several times why he mostly couldn't add new feature in ExtUtils::MakeMaker: because all the Makefile.PL that currently exist must continue to work with any new version of EU::MM, and unfortunately, many use it in strange and twisted way that could easily be broken by new features. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: bug with Test::Exception? or imacat's autotest box?
Tyler MacDonald wrote: Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? CPANPLUS sent the report to your module because its tests failed, because it uses Test::Exception which uses Sub::Uplevel which wasn't available during the test phase. The reason why Sub::Uplevel is missing may come from a problem in IMACAT's box, or maybe not. Details are missing because of the still present interaction problem between CPANPLUS and Module::Build. What you call line noise is most probably File not found in Chinese or Taiwanese. The best thing is to ask IMACAT to send you a more detailed report. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Adam Kennedy wrote: Module::Install... 1) I'm allergic to this module, 2) I want to keep the backward compatibility with Perl 5.004, and Module::Install is not compatible with that version. Are you absolutely sure about that? It says it wants to be (and perlver can't pick up anything obvious in it). $ /usr/local/perl/5.4.5/bin/cpan cpan shell -- CPAN exploration and modules installation (v1.83) ReadLine support enabled cpan install Module::Install ... CPAN.pm: Going to build A/AU/AUTRIJUS/Module-Install-0.54.tar.gz Modification of a read-only value attempted at inc/Module/Install/Metadata.pm - lib/Module/Install/Metadata.pm line 29. Running make test Make had some problems, maybe interrupted? Won't test Running make install Make had some problems, maybe interrupted? Won't install This is the same problems that I already reported once, with the strange effect (not visible in this case) that the printed path is composed of two paths, the second being the one corresponding to the author's system. In the case I reported, it was more obvious because it printed a Darwin-type path following a Linux-type path. And for the record, there are modules with incorrect Crequire concerning the Perl version. For example, some ask a Perl 5.005 while they perfectly work on 5.004, like File::Temp and Test::Reporter. That's how I can send CPAN Testers reports under 5.004: http://testers.cpan.org/show/Net-Pcap.html And there are several modules that works on 5.004, but not their test suite (like Test-Simple IIRC), or modules which depend upon modules that requires a higher version of Perl than themselve. But don't worry too much for now, conclusive version-dependency prooving is on the to-do as well, so I'll deal with it later on. Yes, but I need Net::Pcap to work on 5.004 now, and as the code itself (and its test suite) works on 5.004, it would be very uninteresting for me to use something that require a higher version of Perl. Then there's the fact that I'm still allergic to this module :) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Adam Kennedy wrote: That said, I'd also like I need libfoo 1.41 declarations and other similar things, so we can really make the auto-packagers work some hardcore magic. /me takes the Net::Pcap maintainer hat I'd really like to see something like that, this would allow for a much simpler Makefile.PL (and maybe avoid rants on use.Perl or elsewhere), but as I discovered with Net::Pcap and the need to support 4 different versions (2 on Unix, and 2 on Windows) at the same time it's not really easy to cope with every situation (although I agree it wasn't that hard since it now somehow works). But I currently see now simple way to allow for automated build under Windows, because of manual interaction it requires. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Binary distributions
Gabor Szabo wrote: I think I agree. That's what I would like to see solved. If I stick to the standard apt-get (or whatever) of my distribution I would like to be able to get all the CPAN modules by saying # apt-get install Module::Name Did anybody here have played with CPANPLUS::Dist::Deb? http://search.cpan.org/dist/CPANPLUS-Dist-Deb/ Believing its documentation, it should build a valid Debian package and take care of its dependencies (dunno if that means just listing or actually adding them in the package). -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Adam Kennedy wrote: (*If* the author fixes the problem. I still can't get my patches for Sub::Uplevel high enough in Schwern's queue. Have you considered offering to take it over, or just co-maint the module for one or two releases? He's given away modules before to people that have more time to give them love than he has. And for some modules, he's even eager to give them away :) General question: Are failed prerequisite versions a FAIL or a Not Applicable if the smoke tester isn't set to automatically try to upgrade them? Well purely logically they aren't a FAIL... I think testers currently does email in a FAIL for the dep itself. Not sure what happens to the parent module. I haven't been able to find (although I haven't looked to hard) for a documented set of result codes. But either DEPFAIL or N/A makes sense. N/A status is already available with Test::Reporter: grade meaning - --- pass all tests passed fail one or more tests failed nadistribution will not work on this platform unknown distribution did not include tests CPANPLUS only sends FAIL for the module that failed, not for the module which depended upon the module that failed. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Adam Kennedy wrote: Could you have a look at the COOKBOOK section of the Module::Install docs on CPAN, is that File::HomeDir example sort of what you would need? Module::Install... 1) I'm allergic to this module, 2) I want to keep the backward compatibility with Perl 5.004, and Module::Install is not compatible with that version. The COOKBOOK section is fine for pure Perl modules, but in the case of XS modules that interface to a library with a varying API, it's of no use. Take a look at Net::Pcap's Makefile.PL -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: how to detect that we're running under CPAN::Testers?
Tyler MacDonald wrote: Hello, Is there any way to tell if my package is being tested automatically under CPAN::Testers? For CPAN smokers based on CPAN::YACSmoke, the answer is: test the presence of the AUTOMATED_TESTING environment variable. See also the following page for more details: http://search.cpan.org/dist/CPAN-YACSmoke/lib/CPAN/YACSmoke/FAQ.pod -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: how to detect that we're running under CPAN::Testers?
Tyler MacDonald wrote: Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: For CPAN smokers based on CPAN::YACSmoke, the answer is: test the presence of the AUTOMATED_TESTING environment variable. See also the following page for more details: http://search.cpan.org/dist/CPAN-YACSmoke/lib/CPAN/YACSmoke/FAQ.pod Awesome, that's what I was after. :) Are there any other automated testing environments that post their results to testers.cpan.org I should worry about? AFAICT, serious smokers (the ones that automatically and regularly send CPAN Testers reports) all use CPAN::YACSmoke. The previously used one was cpansmoke, included with previous versions of CPANPLUS: http://search.cpan.org/dist/CPANPLUS-0.0499/bin/cpansmoke I don't think it provided a hint for telling a module whether it was automated testing or not, but I don't think that anybody still use it. That's something not indicated in the CPAN Testers Statistics site, which was finally made available (but very silently) by Barbie: http://perl.grango.org/ Other reports may be send by people like me when they interactively install modules using CPANPLUS, or by hand using Test::Reporter. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Problem with perl code - coverage during build
Selon Dharmesh Vyas [EMAIL PROTECTED]: Hello Group, I am trying to test the perl component and find the code coverage for the same.I have wrote a parser that analyses the generated perl test log files. I am using the version 5.8.7 of perl. I am trying to do the code coverage using bullseye. But while I am trying to build the component I am getting the following error. Does any one have any idea on this. It would be great if someone can suggest me something. If you're trying to calculate the code coverage of the Perl code itself (as opposed to the code coverage of a module), you can take a look at how it is done using gcov and maybe adapt it for Bullseye. The gcov way is to add the -fprofile-arcs -ftest-coverage flags to Configure ccflags and ldflags, -O0 -g to optimize, and then execute the perl.gcov target: ./Configure -Dusedevel -Doptimize='-O0 -g' \ -Accflags='-fprofile-arcs -ftest-coverage' \ -Aldflags='-fprofile-arcs -ftest-coverage' make perl.gcov Then, using Devel::Cover tools, you can generate something like this: http://www.maddingue.net/perlcover/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: First (developers) Release of Test::Shlomif::Harness
Andy Lester [EMAIL PROTECTED] wrote: The real issue is that, if Shlomi had come to me and discussed the issues rather than I want to fork Test::Harness, we could have worked together. Instead, it's I want color-coding of tests, and T::H doesn't do what I want, so I'm gonna go fork it, OK? http://www.nntp.perl.org/group/perl.qa/4799 Maybe I'm overlooking something but if what Shlomi wants is a nice looking output of Test::Harness, why not using something like Test::TAP::HTMLMatrix? http://search.cpan.org/dist/Test-TAP-HTMLMatrix/ Or he could even build his own thing around Test::TAP::Model. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: New kwalitee test, has_changes
Selon Thomas Klausner [EMAIL PROTECTED]: Hi! On Wed, Sep 21, 2005 at 11:58:36AM +0200, David Landgren wrote: To me, this is a mark of Quality. It would be good to have it as a Kwalitee metric, but I see no easy way. The simplest way I can see would be to have a META.yml key that contains a URI to the HTML D::C report. I would rule out adding a cover/ subdirectory to the distribution due to the impact it would have on CPAN repositories. CPANTS will never use Devel::Cover directly, because CPANTS doesn't run the code it's looking at. I think somebody once suggested a central server/service to collect Devel::Cover statistics. Maybe slightly parallel to how testers work, but I'm not sure and haven't got any time ATM to ask google.. I proposed a similar idea using the CPAN Testers infrastructure to collect the statistics. The idea is to just add the cover information in the mail sent by the smokers (which would have the corresponding option enabled). Currently, CPANPLUS and CPAN::YACSmoke are running the test suite and sending a PASS report if it successes, or a FAIL report with details if it fails. The idea is to re-execute the test suite with Devel::Cover once it already succeeded, pack up the cover information and then send the PASS report with the coverage information. Or it can be sent in another email. Then CPAN::WWW::Testers could be extended to gather the statistics and present them. I didn't provided the code yet because I got distracted by other modules and other hacks I was trying to add to CPANPLUS. Something important is to check whether it is possible to send coverage information without taking too much space and bandwith. A quick test shows that the Storable files used by Devel::Cover seem to compress quite well with gzip, so an option may be to just send it this way. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: rantTesting module madness
You wrote: This is a mini-rant on how complex the tesing world for Perl modules has become. It starts harmless, like you want to install some module. This time it was CPAN-Depency. Since for security reasons your Perl box is not connected to the net, you fetch it and all dependencies from CPAN and transfer them via sneaker net and USB stick. It includes some gems like: 'Test::Deep' = 0, 'Test::Warn' = 0, Huh? Never heard of them, but if it needs them, well, we get 'em. Presumable they are only needed for testing the module, but who knows? However, as you soon find out, Test::Deep needs these two: Test::Tester = '0.04', Test::NoWarnings = '0.02', Put on your high-speed sneakers, grumble shortly and fetch them. Hey! Don't blame me on that! At least I listed the dependencies. There are still many modules that even don't list the test modules they are using. I think I have already changed them from required to recommanded for the next, unreleased version, and skip gracefully if they're not present. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: rantTesting module madness
Either they're valuable enough that you install their prerequisites or they're not. But how am I supposed to find this out? I dont even know whether the required modules are used for the tests only, without digging through the source... Usually, Test::* modules are only used for the test phase. Maybe there could be some sort of bundle installer that grabs a module and all of its dependencies for people who do offline installations. That might be a great thing. But I'd still need to install all the testing modules just to run the tests prior to install the module itself. Hm. It should be possible to take the offline-prepared bundle and run the testsuite, and only then install the module and the absolute nec. dependencies. What we also miss are the test_requires/test_recommands in Module::Build. This was discussed at some time but I don't remember whether they were added or not. This doesn't solve the problem when you're using Makefile.PL but it can give you hints. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Test::Exception and XS code
Hello all,
I have posted this question on CPAN Forum but nobody answered, so I
also post it here in case someone has an idea.
While rewriting Net::Pcap test suite, I quickly stumbled upon this
problem: it looks like Test::Exception can't catch croak() or die()
thrown from XS code. Here is an example:
use strict;
use Test::More tests = 1;
use Net::Pcap;
eval use Test::Exception;
my $has_test_exception = !$@;
SKIP: {
skip Test::Exception not available, 1 unless
$has_test_exception;
dies_ok {
$dev = Net::Pcap::lookupdev(undef)
} '/^arg1 not a reference/',
calling lookupdev() with no reference
}
When executed, this script gives the following:
$ perl 02-lookupdev.t
1..1
arg1 not a hash ref at 02-lookupdev.t line 15.
# Looks like your test died before it could output anything.
I checked that the exception can be caught using eval{} or eval:
$ perl -MNet::Pcap -le 'eval{Net::Pcap::lookupdev(undef)}; print
after'
after
But if I try to do the same thing with Test::Exception, wrapping the
lookupdev() call within an eval{}, it throws me a new kind of error:
$ perl 02-lookupdev.t
1..1
Can't call method dies_ok without a package or object reference
at 02-lookupdev.t line 14.
# Looks like your test died before it could output anything.
Using the parens form of dies_ok() resolves the syntax error but then
the test always successes.
Am I doing something wrong?
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: Test::Exception and XS code
Sébastien Aperghis-Tramoni wrote:
While rewriting Net::Pcap test suite, I quickly stumbled upon this
problem: it looks like Test::Exception can't catch croak() or die()
thrown from XS code.
[...]
Ok, I corrected a mistake (I was using dies_ok() instead of
throws_ok()), and reduced the problem to this test case:
use strict;
use Test::More tests = 2;
use Test::Exception;
use Net::Pcap;
throws_ok(
sub { Net::Pcap::lookupdev() },
'/^Usage: Net::Pcap::lookupdev\(err\)/',
calling lookupdev() with no argument
);
throws_ok
{ Net::Pcap::lookupdev() }
'/^Usage: Net::Pcap::lookupdev\(err\)/',
calling lookupdev() with no argument
;
Executing this script works as expected:
$ perl -W exception.pl
1..1
ok 1 - calling lookupdev() with no argument
ok 2 - calling lookupdev() with no argument
# Looks like you planned 1 test but ran 1 extra.
Now, if I move the use Test::Exception inside an eval-string and
execute the new script:
$ perl -W exception.pl
1..2
ok 1 - calling lookupdev() with no argument
Usage: Net::Pcap::lookupdev(err) at exception.pl line 13.
# Looks like you planned 2 tests but only ran 1.
# Looks like your test died just after 1.
Aha! The first test, which uses the normal form of throws_ok() passes,
but the second one, which uses the grep-like form, fails.
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: Test::Exception and XS code
Yitzchak Scott-Thoennes wrote:
The throw_ok { ... } syntax only works because the throw_ok sub exists
and has a prototype that specifies a subref is expected; if you don't
load Test::Exception by the time the throw_ok call is compiled, it
is parsed as an indirect object call of the throw_ok method on the
object or class returned by the {} block:
$ perl -MO=Deparse,-p -we'throws_ok { Net::Pcap::lookupdev() }
/^Usage: Net::Pcap::lookupdev\(err\)/, calling lookupdev() with no
argument'
BEGIN { $^W = 1; }
do {
Net::Pcap::lookupdev()
}-throws_ok('/^Usage: Net::Pcap::lookupdev(err)/', 'calling
lookupdev() with no
argument');
-e syntax OK
which is perfectly valid perl, but unlikely to do what you want.
Understood. Thanks for the explanation.
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: Need to talk to an EU patent attorney
Tels wrote: On Tuesday 12 July 2005 23:00, Michael G Schwern wrote: Barbie's journal, via Ovid, made me aware of patent EP1170667 Software Package Verification granted last month in the EU. http://gauss.ffii.org/PatentView/EP1170667 It appears to patent basic software testing frameworks. This entire patent system is becoming so silly. :-( For what it is worth, this patent would be not legal/not enforcable in Germany due to be software only. (It would also probably not quality on grounds of being obvious, I fail to see what is so patent-worthy on this patent. Even I could have come up with a testsystem.) As for the rest of the EU, software-only patents are very probably not enforcable, anyway. (Although I lost track over how the issue now really is, the last thing I heard there was a victory for the no-software-patent crowd (yeah!), but then maybe it just cemented the status quo (namely, everything under the sun gets patented left/right). Indeed, there was a great victory for the no-software-patent side, as the EP massively voted against software patents (648 against, 14 for, 18 nulls). See FFII press releases: http://wiki.ffii.org/Ep050706En http://wiki.ffii.org/SpinPr050708En What this means is that, at the European level, we're back to the statu quo which is: software isn't a technology, therefore it is no patentable (Munich Convention of 1973, confirmed by article 27.1 of TRIPS). Consequence is that the currently 30,000 patents granted by EPO are not legal, hence not enforceable. Of course, IANAL, but that's what MEP and people who actually reading the texts say. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: what slow could be in Compress::Zlib? (was RE: 5.004_xx in the wild?)
Paul Marquess wrote: Whilst I'm here, when I do get around to posting a beta on CPAN, I'd prefer it doesn't get used in anger until it has bedded-in. If I give the module a version number like 2.000_00, will the CPAN shell ignore it? Indeed, if a distribution is numbered with such a number, it is not indexed by PAUSE, and therefore can't be installed from CPAN/CPANPLUS Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: How to force tests to issue NA reports?
David Cantrell wrote: Let's take my module File::Find::Rule::Permissions as an example. I know it doesn't work on Windows, but not having access to a Windows machine, I have *no idea* what $^O should be on that platform, especially for any odd Windows environments like Cygwin or WinCE. I also know it doesn't work on VMS. perlport to the rescue: http://search.cpan.org/dist/perl/pod/perlport.pod#PLATFORMS Oh, and to the list of fields at http://module-build.sourceforge.net/META-spec-new.html how about adding 'requires_application'. Mac::iTunes::Applescript has an obvious prerequisite. The module Net::P0fq that I am slowly working on requires a running copy of p0f. http://search.cpan.org/dist/Net-P0f/ Maybe we should join our forces here :) On a side note, the tests would just check for the availability of p0f. If it's not present, just skip the tests that require it. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Phalanx
Selon Gabor Szabo [EMAIL PROTECTED]: So I guess my question is, what exactly am I supposed to do to improve test coverage? Am I supposed to modify the existing scripts so they execute more functions exported by the module? Are any of the other modules currently being tested not using the t/ framework? I would start by replacing the test.pl file with test scripts in the t/ directory and start using Test::More. Then I would split it up to several scripts and start testing more functions just as you suggested. Note that test.pl actually calls scripts in the examples/ directory by running them throught backticks: $res = `$perl examples/passwd-cb.pl $key_pem.e secret`; So the code is already splitted, but in a quite twisted way :-/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: I have an itch. It just came to me while surfing PerlMonks and CPAN. I noticed the new Test::Strict module which keeps me honest by making sure I always 'use strict'. I'll be adding that to my modules this evening. [I wish is did use warnings too]. My second thought was wouldn't it be cool if there was something like Test::CPANTS in which I could always verify that my modules were at least at a kwalittee rating of x or more during make test? Any thoughts? I've looked at the CPANTS modules and it looks possible, and I'm willing to take a crack at it it anyone thinks it will be of some use. I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. Test::Prereq ? I don't know if it handle all those cases though. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? That's a quite classic troll starter I think :-) Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: CPAN modules coverage (was: Test::Output 0.05)
Selon Michael G Schwern [EMAIL PROTECTED]: On Sun, Mar 06, 2005 at 09:54:44PM +0100, S?bastien Aperghis-Tramoni wrote: Instead of running the code on one server, where it's a problem, why not running on machines where all prereq modules are already installed, i.e. on machines where one *wants* to install the module ? Let's add an option to CPANPLUS so that it run Devel::Cover on any module that it has to install and include the coverage information in the test report. Not a bad idea. Issues I can think of... * Devel::Cover is very slow, I don't know if you'd want it on all the time like test reporting. Right, this is slow, but for someone that want to know if the module is well tested, this information may help to gauge the quality (or the kwalitee) of this module. And for cpansmokers, I'd say speed has no importance. If the speed really is an issue, it can be solved by running the test suite with Devel::Cover in another CPANPLUS process. * As mentioned, Devel::Cover is not perfect and often screws up test results, threading particularly is a problem, so that it will give false negatives. This is a common problem, one example is Test::More. An interesting question would be: from all the CPAN Testers reports, how many perl are built with thread support enabled? I know mine is because it's the default perl included with the Mandrake distribution, but RGS annouced that the next one won't have thread support, because of the troubles it creates. The next interesting question is: how many modules use/need threads? If I believe CPANTS, not much. sqlite SELECT dist.id, dist.dist, dist.author, prereq.requires FROM dist, prereq WHERE prereq.requires like '%hread%' AND prereq.requires not like '%ail%' AND dist.id=prereq.distid; returns 17 results, 16 of which are in the Thread::* namespace (and are released by Elizabeth Mattijsen). The only one left is SNMP::Server. I never dealed with thread problems, but from reading the Perl documentation, I always had the feeling that Perl thread support has never been considered very stable. This is to say: ok, maybe Devel::Cover don't deal very well with threads, but if there's so few modules on the CPAN that use threads, maybe it can be considered as a low priority issue. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: CPAN modules coverage (was: Test::Output 0.05)
Michael G Schwern wrote: I think it would be a powerful addition to CPAN. If you go to the distribution page for any module - say, for example, Class::DBI (http://search.cpan.org/~tmtm/Class-DBI/) Trouble right there. Now search.cpan.org has to run untrusted code so a jail would have to be constructed. Additionally it has to have all the optional modules necessary for testing the module available else the coverage run will appear low due to skipped tests. CDBI is a perfect example of this. Finally, any external dependencies or platform specific code causing tests to be skipped (libwin32, DBD::Pg, etc...) will produce inaccurately low coverage reports. Instead of running the code on one server, where it's a problem, why not running on machines where all prereq modules are already installed, i.e. on machines where one *wants* to install the module ? Let's add an option to CPANPLUS so that it run Devel::Cover on any module that it has to install and include the coverage information in the test report. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Foreign modules in test scripts?
Selon Michael G Schwern [EMAIL PROTECTED]: Second, I know there is a build_requires option in Build.PL, but does the CPAN(PLUS).pm know about that option and really only download and use those build_requires temporarily during module build/test or does it fully install them? Something better answered by [EMAIL PROTECTED] Note that I believe CPANPLUS currently defaults to favoring a Makefile.PL over a Build.PL if both are present so often it'll just be treated like a normal prereq anyway. Current version of CPANPLUS (0.053) suggests by default to use Build.PL over Makefile.PL. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Phalanx update please!
Selon Sébastien Aperghis-Tramoni [EMAIL PROTECTED]: Hello, Here are the final lists of the modules dependencies. This time I grouped the modules by their respective distribution name. I forgot to say that these lists were made by reading the META.yml when available, or by parsing Makefile.PL or Build.PL otherwise (borrowed the code from Thomas Klausner's Module::CPANTS::Generator::Prereq). Therefore they represent the dependencies of a large part of the CPAN. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
