Re: Easy-bake perlbug email interface
When they work, you can CC special addresses in a reply, and things
happen.
For example, if you cc [EMAIL PROTECTED] the ticket will be closed.
I don't remember the exact syntax, but I think
[EMAIL PROTECTED] will close it as notabug.
Other keywords include 'patch' 'note', etc.
Join them with _.
BUGid will come from the subject, unless you specify it in the address.
See here for a little more...
http://bugs.perl.org/perlbug.cgi?req=mailhelp#ADMINISTRATOR
-R
On Thu, 2001-10-25 at 15:51, Michael G Schwern wrote:
> The idea being you see a bug report on p5p and can reply to it *and*
> send commands to perlbug with a single command. So instead of hitting
> 'g' (group reply in mutt) you might hit 'B' (perlbug) and select from
> a short list ('n'otabug, already 'f'ixed, 't'est, 'p'atch) of what
> you're doing. Up pops an editor and you do your thing.
Re: Phalanx article now live
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > There's a new Phalanx article on perl.com: > http://www.perl.com/pub/a/2005/01/13/phalanx.html > > Let's hope we get an influx of Hoplites! > > xoxo, > Andy > Hey Andy, I am new to Perl. If you went by the "Perl Medic" book I would be about a level 4. I am also on Windows (work) and OSX (home). How can I help? Robert
Re: Phalanx matchups
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'll put my hat in the ring, first: I don't want to run a module team, > but I'm glad to join one. > > xoxo, > Andy Ditto for me. I am a Perl neophyte but I think this would be a great way to learn so things about testing specifically and Perl as well. Robert
Re: Module popularity
cpanratings.perl.org? Ian Langworth wrote: Fair enough. On Tue, 15 Mar 2005 00:37:26 -0600, Andy Lester <[EMAIL PROTECTED]> wrote: I'd rather it didn't. What people think of as "popularity" is not what Phalanx measures. Let's not stir the mud.
Re: Talk: Why You Really Want To Write Tests
"Michael G Schwern" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Tue, Mar 22, 2005 at 06:28:21PM +, Adrian Howard wrote: >> PS "O'Reilly will have a small book soon" ? > > Oh yeah, that's the developer's testing notebook Ian Langworth and > chromatic > are working on. > On slide 13: "Tests let you know, right away, when they're screwed up your code" Should be: Tests let you know, right away, when they've screwed up your code or Should be: Tests let you know, right away, when they're are screwing up your code
Building a module with tests
Is there an article on the current best practices about creating a module with tests? I know there is h2xs but I somewhere in the back of my foggy brain I am thinking I read somewhere of a different. more preffered method. If this is the wrong group to ask, sorry. Just let me know which is the best place to ask and I will re-direct my question. Robert
Re: Building a module with tests
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Thu, May 05, 2005 at 10:12:14AM -0400, Robert ([EMAIL PROTECTED]) > wrote: >> Is there an article on the current best practices about creating a module >> with tests? I know there is h2xs but I somewhere in the back of my foggy >> brain I am thinking I read somewhere of a different. more preffered >> method. > > Go look at Module::Starter. Also, buy a copy of Perl Testing > Developer's Notebook as soon as it comes out. > > xoxo, > Andy > : ) Seems it is not available as a PPM for ActiveStates Perl distro. Robert
Re: Building a module with tests
On 5/6/05 1:50 PM, in article [EMAIL PROTECTED], "Steve Peters" <[EMAIL PROTECTED]> wrote: > On Fri, May 06, 2005 at 11:43:53AM -0400, Robert wrote: >> "Andy Lester" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> On Thu, May 05, 2005 at 10:12:14AM -0400, Robert ([EMAIL PROTECTED]) >>> wrote: >>>> Is there an article on the current best practices about creating a module >>>> with tests? I know there is h2xs but I somewhere in the back of my foggy >>>> brain I am thinking I read somewhere of a different. more preffered >>>> method. >>> >>> Go look at Module::Starter. Also, buy a copy of Perl Testing >>> Developer's Notebook as soon as it comes out. >>> >>> xoxo, >>> Andy >>> >> >> : ) >> >> Seems it is not available as a PPM for ActiveStates Perl distro. >> > > Looking at http://ppm.activestate.com/BuildStatus/5.8-M.html, the > Module-Starter distribution is available for the ActiveState 5.8.x Perls. > > Steve Peters > [EMAIL PROTECTED] It doesn't show up though. I will look again on Monday and if it isn't there I will do a manual install. Robert
Re: Building a module with tests
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Fri, May 06, 2005 at 11:43:53AM -0400, Robert ([EMAIL PROTECTED]) > wrote: >> > Go look at Module::Starter. >> >> Seems it is not available as a PPM for ActiveStates Perl distro. > > Please don't let that be an impediment. Install it manually. It is > EXACTLY what you are looking for. > > xoxo, > Andy > > -- > Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance I installed it manually... : ) Robert
Modules::Starter question
I am creating my first module (finally) and I was told a while ago to use Module::Starter. Which I did. I am fine there. When I look at the code generated I see that all the POD stuff is inline while I prefer to see POD stuff at the end. Is the inline POD the current preferred way? If it is, I am fine with that and will continue to chug along. If not, I will move it to the end and I would make a request to the M::S author to have a command line switch added to indicate which POD style to use (defaulting to whatever the auther wishes of course). Thanks! Robert
Re: failure notice
I just saw that this morning. I have no idea where that email address came from as that is a real old address. I will have to check my settings when I get back to work. Robert On 8/6/05 6:03 AM, in article [EMAIL PROTECTED], "Tels" <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE----- > > Moin, > > robert, you need to work on your reply-to address :) > > - -- Forwarded Message -- > > Subject: failure notice > Date: Saturday 06 August 2005 11:38 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > > Hi. This is the qmail-send program at relay03.pair.com. > I'm afraid I wasn't able to deliver your message to the following > addresses. This is a permanent error; I've given up. Sorry it didn't > work out. > > <[EMAIL PROTECTED]>: > 64.62.181.91 does not like recipient. > Remote host said: 550 <[EMAIL PROTECTED]>: inactive user > Giving up on 64.62.181.91. > > - --- Below this line is a copy of the message. > > [snip] > > - -- > Signed on Sat Aug 6 12:02:45 2005 with key 0x93B84C15. > Visit my photo gallery at http://bloodgate.com/photos/ > PGP key on http://bloodgate.com/tels.asc or per email. > > "Sundials don't work, the one I've had in my basement hasn't changed > time since I installed it." grub (11606) on 2004-12-03 on /. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iQEVAwUBQvSK+3cLPEOTuEwVAQHbuAf+Lkf1oN0JqsqWrwGj0LVF9n0xP45yWpF4 > Lr1UMFlj6iXbj0Zqw2qM/dM0XE8MNgPPgjvd8emMyrdSVCVBld5Tp/XDP8ZkzjzX > W+771gDiAGB+rb/MOfoUi22OYWgVuc0x3lxcQ+eJKpJK+2gqAOjvU4MwCxNgI5R9 > YCwhkrP7Ute8Faxgjr/8+3qwzxP1/kxjPrLRUNQ/eubfDaTT6ZG6aCOCisJngarX > bfTe2XC9FMloSguoa7woYjcWpuTeOsvnRrwPqXmJ2mpX2BgKL6YF5usKoOsc6l65 > Mxt9E6oVYMw14cssHe/5VqprQA/tVKzMXdO2L5RRnwkdwRis2fa0SA== > =Ufij > -END PGP SIGNATURE-
Re: Modules::Starter question
Thanks for the answers. Robert
Re: Modules::Starter question
Dave Cross wrote: On Fri, Aug 05, 2005 at 11:32:45AM -0400, Robert wrote: I am creating my first module (finally) and I was told a while ago to use Module::Starter. Which I did. I am fine there. When I look at the code generated I see that all the POD stuff is inline while I prefer to see POD stuff at the end. Is the inline POD the current preferred way? If it is, I am fine with that and will continue to chug along. If not, I will move it to the end and I would make a request to the M::S author to have a command line switch added to indicate which POD style to use (defaulting to whatever the auther wishes of course). If you install Module::Starter::PBP then Module::Starter will create new modules using all of the recommendations from "Perl Best Practices", including putting all of the Pod at the end. Dave... I tried it (Module::Starter::PBP) on WinXP and it didn't seem to pickup the config I did with PBP. I will try it again to make sure. Robert
Re: Why are we adding more kwalitee tests?
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Tue, Sep 06, 2005 at 10:07:02AM -0400, Christopher H. Laco ([EMAIL PROTECTED]) wrote: > > Why would they stop uploading? How would they, the new uploaders, even > > know about CPANTS? It's not like uploaded files automatically return a > > scathing email and an html response page that says your "module sucks; > > failed CPANTS kwalatee. Go away". > > I don't know. That's why I ASKED THE QUESTION of what will be done with > the information about their results. > I just signed up as a module author. I didn't know about the kwalitee thing until I started reading the "Perl Testing" notebook that just came out. It would not stop me from uploading though. I would either ignore it or strive to get my "kwalitee" higher. I did not look at any kwalitee levels for the modules that I have installed. I need 'em, so I use 'em. Robert
Descriptive strings in Test::More ?
(ergh, let's try this again from the right address)
I'm not sure where's the best place to post this, but I imagine perl-qa
might be a good start. Please let me know if it's the wrong place.
I've been messing with various testing modules that I learnt about at
YAPC, and I'm unclear about something.
use Test::More no_plan;
ok( nonblank("abc") eq "OK" , "Strings aren't blank" );
The above is generated using Pod::Tests and pod2test (yay schwern!).
When I run these tests, I never see the descriptions of the tests (eg
"Strings aren't blank").
I thought those strings were meant to output during the testing, to show
you what it's testing for. Am I confused?
K.
--
Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/
Real programmers don't bring brown-bag lunches. If the vending machine
doesn't sell it, they don't eat it. Vending machines don't sell quiche.
Descriptive strings?
I'm not sure where's the best place to post this, but I imagine perl-qa
might be a good start. Please let me know if it's the wrong place.
I've been messing with various testing modules that I learnt about at
YAPC, and I'm unclear about something.
use Test::More no_plan;
ok( nonblank("abc") eq "OK" , "Strings aren't blank" );
The above is generated using Pod::Tests and pod2test (yay schwern!).
When I run these tests, I never see the descriptions of the tests (eg
"Strings aren't blank").
I thought those strings were meant to output during the testing, to show
you what it's testing for. Am I confused?
K.
--
Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/
"My secret weapon is PMS." -- Buffy the Vampire Slayer
Re: Docs on testing?
In lists.projects.perl.perl-qa, you wrote: >I am not a newcomer to this list, just a squatter and I have been >programming Perl for about a year now (and lovin' every minute of it). After >reading all the postings on this list about Test::Simple, etc... I was >wondering, are there any (or plans to create any) docs that explain how to >write tests? I believe I volunteered to do that the other day. More fool me :) K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ There's nothing wrong with me; therefore, there must be something wrong with the universe.
Re: Descriptive strings?
On Tue, Jun 19, 2001 at 08:42:29PM -0400, Michael G Schwern wrote: | | I assume you're talking about "make test"? Test::Harness in | non-verbose mode (ie. "make test") won't display any of that info. If | you set $verbose = 1 you'll see all the test output. For failed tests | it will just report their numbers. Where do I set $verbose? | Currently, Test::Harness is not aware of test names at all. It just | ignores the extra info. I'm not sure what I'm going to do about that. | As sort of a simple, half-ass solution I'm going to have Test::Harness | dump its verbose output to a file (test.out?) by default. Hrm. What I want is to achieve this: # This produces "ok 1 - Hell not yet frozen over" (or not ok) ok( get_temperature($hell) > 0, 'Hell not yet frozen over' ); (from the Test::Simple perldoc) when I run "make test". K.
Re: QA-esque summary of TPC
Schwern wrote: > >Dangermouse > >We watched Dangermouse, The Avenging Disco Godfather and probably too >much Monty Python for our own good. Put yo' WEIGHT on it! I can see how Danger Mouse might be considered quality, but Avenging Disco Godfather? No way. >Adam Turoff gave a talk about stealing ideas from LaTeX, XML and SGML >and incorporating them into POD. I missed it. Anyone go? No, but it's in the proceedings, and I'm kind of familiar with the topic, so I'll attempt a brief rundown in my own words: 1. These days it's fashionable for markup languages to describe the content, not the presentation. This helps computers parse them better. For instance, Je ne sais quois is less recognisable as a phrase in a foreign language than Je ne sais quoi 2. POD, as it currently stands, is almost entirely presentation-based. For instance, =head1 produces a level one heading but doesn't actually say much about the structure of the document; B<> says something's bold but doesn't say why. 3. Adam's proposal is that semantic tags would be useful in POD, primarily for converting between POD and other semantic markup languages such as Docbook. He has invented some new POD-like tags for this: =chapter =section =appendix =title =fpara (a formal paragraph, i.e. a para with a title) =list =code em<> function<> literal<> 4. This would then make it easy to convert to/from Docbook, another very common/popular documentation markup language. This means that you don't have to know all of Docbook to write Docbook -- you can write in this cut-down, intermediate level: DocPOD 5. There are some modules for doing the translation etc, see DocPod::*, presumably on CPAN. HTH, K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Be pedantic in what you accept, and arbitrarily brutal in what you send." -- Malcolm Ray in a.s.r
Re: Pod::Coverage random silliness
In perl.qa, you wrote: >On Tue, Aug 28, 2001 at 07:56:30PM -0400, Kirrily 'Skud' Robert wrote: >> This script... > >Nifty, mind if I assimilate it as an example script? Not at all. Credit as Kirrily "Skud" Robert <[EMAIL PROTECTED]> please. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ How do I set my LaserPrinter to "Stun"?!
ANNOUNCE: Test::Mail 0.03
Now winging its way towards CPAN mirrors worldwide. I've implemented it pretty much as described the other day. Comments etc welcome. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Sure, only 2 percent of the Internet population uses lynx, but they're the top 2 percent." -- petro, on a.s.r
Re: Wiki Wiki not Wiki Working
In perl.qa, you wrote: >Will do. No! Read on! It's been done already. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Any sufficiently fucked-up technology is indistinguishable from magic.
Re: [PATCH] More Test::More stuff
In perl.qa, you wrote:
>>
>> eval { ...code... };
>> is( $@, '' );
>
>Yeah, except that doesn't print out $@ in case of failure. If I'm
>checking that no exception occurs I want to know what the exception is
>when it happens.
But it does! It says something like:
not ok 23
# Failed test 1 (eval.t at line 69)
# got: 'blah blah blah'
# expected: ''
K.
--
Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/
"There are three degrees of being weird. There are: 1) Salvageably weird.
2) Weird. 3) Irrevocably weird." -- Carrie Fisher
Re: What tests are failing on VMS?
In perl.qa, you wrote: >So like I said, either tests are habitually failing on vmsperl, or >nobody's compiled Perl on OS/390 in a long time (I wouldn't be >surprised if that were true). I assume you mean "MVS"? K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ We have only two things to worry about: either that things will never get back to normal, or that they already have.
Re: Wiki Wiki Working
In perl.qa, you wrote: > >If someone would be so kind as to fill in TestTutorial from the latest >version of Test::Tutorial? Done. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Verbogeny is one of the pleasurettes of a creatific thinkerizer." -- Peter da Silva
Re: FAIL Module-InstalledVersion-0.02 cygwin-multi 1.3.2(0.3932)
In perl.qa, you wrote: >On Thu, 13 Sep 2001 19:41:39 -0400 >Kirrily 'Skud' Robert <[EMAIL PROTECTED]> wrote: > >> Anyone know what might cause this? The same reporter also had the same >> problem with CPAN-Test-Reporter. > >His Test::Harness needs upgrade? Yeah, I guess that'd be it. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Any sufficiently advanced political correctness is indistinguishable from irony. - Erik Naggum
Re: Test::Harness::Straps
In perl.qa, you wrote: >On Thu, Sep 20, 2001 at 10:35:49AM -0400, Shane Landrum wrote: >> So, I've just found Test::Harness::Straps--- thanks to Skud >> for pointing me in the right direction. Anyone else using it? >> I'm working on using it to write a web-based test summarizer >> for my users. >> >> Schwern, do you have plans for releasing T::H 2.00 to CPAN >> as anything other than an alpha? What do you need to see >> before you release it? > >Hmmm, more people trying it, really, especially on the weird >platforms. I rewrote all the test analysis logic and I still afraid I >broke something. We're probably going to start using it for e-smith's testing foo. I've dinked around with it briefly, enough to know that it does roughly what I want, but I'm not on any kind of unusual platform or anything, so I don't know if that's at all helpful. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Make a fist, Benno. No, that's too big." -- Renee (from the Netizen quotes file)
Re: Test::Harness in Test-SDK conflicts with Perl
In perl.qa, you wrote: >On Tue, Oct 09, 2001 at 10:10:33PM +0200, Johan Vromans wrote: >> Michael G Schwern <[EMAIL PROTECTED]> writes: >> > Debian has the beginnings of that. perl-base is the minimum necessary >> > to have a useful Perl, basically a binary, the perl man page, and a >> > handful of critical modules ... >> >> Wouldn't it be a good idea to try to define packages like these, so >> that packagers can all make consistent packages? > >Come again? I think he's trying to say that Perl (i.e. the "Perl community") should define these things so that different packagers (Debian, Red Hat, whoever) can have somewhat-consistent packages. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ If it's not broken, break it.
Re: Test::Builder: Multiple test libraries in one test.
In perl.qa, you wrote: >Candidates for this sort of thing would be CGI::Test, Test::Cmd, >Test::Unit, Test::Mail and ExtUtils::TBone. And, of course, Barrie's >Test::Differences. Actually, Test::Mail doesn't work like that. It's more or less a wrapper around Test::More that handles incoming email. Doesn't implement any of its own ok()-like routines at all, just makes it easy to use Test::More's routines on incoming email. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Usenet: open mouth, insert foot, propagate internationally
Re: is() with arbitrary comparisions
In perl.qa, you wrote: >I think I have a solution to the rigidity of is(). ie. something with >the diagnostic output of is(), but the flexibility of ok(). >It all makes sense, so what I really need is a better name. How about: compare($foo, "<=", $bar) K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Does anyone know my root password?" --Renee (from the Netizen quotes file)
Re: [perl #15479] perl 5.8.0 segfault
>> And where did the p5p FAQ get to? >MJD said he was taking it off his website... or do you mean the serious one? Do you mean this? http://simon-cozens.org/writings/p5p-faq If someone wants to become a new champion for it, we can keep it on http://dev.perl.org/perl5. (Another way to enable that would be to merge it into the perl5 sources, and then the website can check it out periodically.) -R
Re: Why not a smoke db ?
Alain Barbet writes: >> Have you seen http://tinderbox.perl.org ? I've personally found that >> useful for monitoring Parrot, though it's not obvious how well it would >> scale for large numbers of smoke-test configurations. > >No I didn't know this, but find some good idea in this system too. >I will see if it's possible to apply (partial part may be ?) to smoke >system. This alternate display is prettier, and scales to N trees (than the standard tinderbox display a lot better. IMHO: http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot -R
Re: WWW::Mechanize 0.37 released
> Help me out here. I'm trying to imagine why someone would want > WWW::Mechanize without a net connection. Or are you saying that people > will want to use it strictly behind a restrictive firewall where > google.com isn't accessible? Yes. -R
Re: WWW::Mechanize 0.37 released
> 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. -R
Re: perlbug HOWTO
At Fri, 18 Jul 2003 18:19:19 +0100, Tony Bowden wrote: > I've been chatting with Casey about how we should best be dealing with > the perlbug RT interface - e.g. what to do when you come across a bug > that's resolved, what the various statuses mean etc. The proper place for this particular discussion is probably the currently-defunct bugmongers list. > There doesn't seem to be any documentation anywhere on this, and we > thought the QA wiki might be a useful place to try putting it > together. I'd rather something that can actually live on bugs.perl.org. > Thoughts, suggestions, ideas? Here's my document for the old perlbug. It's horribly out of date. But would be a good place to start. adminfaq Description: Binary data
Re: perlbug HOWTO
> > I'd rather something that can actually live on bugs.perl.org. > How about a bugs.perl.org Kwiki? I have not yet drunk that particular Kool Aid. I'm happy to accept patches. I also want to retain some level of editorial control over it, to make sure we don't make right-turns. -R
Re: Scrutinizing CPAN distributions (Commenting Styles)
> I guess mostly the syntax highlighting is the biggest concern. I > use emacs and that does syntax highlighting for perl files. Is there any > IDE out there that highlights POD differently than code? If that was the > case then I probably wouldn't have a problem with in-module POD. I guess > when it comes down to it it's readability and the ability to distinguish > comments from code. Emacs does. iirc cperl-mode has proper (i.e. "different") highlighting for POD, and if you want to do it right, you can use mmm-mode to mix cperl mode and pod mode. -R
Re: Phalanx / CPANTS / Kwalitee
> Yes. We've been thinking about this. It either needs stealing buildd > from Debian, having a box we don't mind destroying every so often, or > having a VMware virtual machine we can undo easily. What we need is > more free time ;-) > User Mode Linux (limiting to Linux, of course) might be a lighter weight way to do this. -R
Looking for module dependency information
To whom it may concern, I am looking for information on CPAN module dependencies. Specifically, does somebody maintain and regularly update such a list? The reason is that I would like to integreate this with testing information from the CPAN Testers. So if I find that there are no testing results for platform 'x' for a specific module, I can check to see if one of the dependent modules fail on that platform. Thanks, Robert Rothenberg (FYI, I've just posted a question on PerlMonks regarding this, http://www.perlmonks.org/index.pl?node_id=373386)
Re: Looking for module dependency information
On 7/11/2004 12:46 AM Michael G Schwern wrote: Most modules now have a META.yml file which contains (amongst other things) module dependency information. Simplest thing to do would be to make a local miniCPAN mirror [1] and walk through the archive files [2] in modules/02packages.details.txt looking for META.yml. I've been doing something like that, but there's still plenty out there that don't have META.yml. So I may try something like Module::Depends, if I can get it working on Windoze. (It apparently requires File::chdir to work, BUT due to bad juju between Cwd and File::SpeC) Oddly, this is one of the cases that inspired me to work on this problem.
Script to find Module Dependency Test Results...
I have a prototype Perl script that will determine the dependencies of a given
CPAN distribution, and then check CPAN Testers for any failure reports of that
distro or dependent distros for a given platform.
I would like to work with other people to turn this into something of use to
the community, at the very least a module but ideally something that could be
integrated with one of the CPAN-related web sites. (I'm also starting
graduate school in the fall and looking for people to take this idea and run
with it, as I won't have as much time.)
For an example of what this does, if I ask it to search for dependencies for
the disto 'Pixie', it tells me the following:
Pixie-2.06:
DBIx-AnyDBD-2.01: {}
Data-UUID-0.11: {}
Test-Class-0.03:
Test-Differences-0.47:
Text-Diff-0.35:
Algorithm-Diff-1.15: {}
Test-Exception-0.15:
Sub-Uplevel-0.09: {}
Test-Tester-0.09: {}
Test-Tester-0.09: {}
for Windows machines, it also tells me this:
Algorithm-Diff-1.15: []
DBIx-AnyDBD-2.01:
- action: FAIL
distversion: DBIx-AnyDBD-2.01
id: 79987
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/79987
version: 2.01
Data-UUID-0.11:
- action: FAIL
distversion: Data-UUID-0.11
id: 145033
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/145033
version: 0.11
- action: FAIL
distversion: Data-UUID-0.11
id: 146960
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/146960
version: 0.11
Pixie-2.06: ~
Sub-Uplevel-0.09: []
Test-Class-0.03:
- action: FAIL
distversion: Test-Class-0.03
id: 144608
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/144608
version: 0.03
Test-Differences-0.47: []
Test-Exception-0.15: []
Test-Tester-0.09: []
Text-Diff-0.35: []
In other words, there are no test reports for Windows users of Pixie, but
that's likely because they can't get several distros that Pixie requires to
work on Windows (Test-Class, DBIx-AnyDBD-2.01, and Data-UUID-0.11).
This information would be of use to various quality-assurance types, as well
as the module author. It's probably of use to module users too.
Script to find Module Dependency Test Results...
I have a prototype Perl script that will determine the dependencies of a given
CPAN distribution, and then check CPAN Testers for any failure reports of that
distro or dependent distros for a given platform.
I would like to work with other people to turn this into something of use to
the community, at the very least a module but ideally something that could be
integrated with one of the CPAN-related web sites. (I'm also starting
graduate school in the fall and looking for people to take this idea and run
with it, as I won't have as much time.)
For an example of what this does, if I ask it to search for dependencies for
the disto 'Pixie', it tells me the following:
Pixie-2.06:
DBIx-AnyDBD-2.01: {}
Data-UUID-0.11: {}
Test-Class-0.03:
Test-Differences-0.47:
Text-Diff-0.35:
Algorithm-Diff-1.15: {}
Test-Exception-0.15:
Sub-Uplevel-0.09: {}
Test-Tester-0.09: {}
Test-Tester-0.09: {}
for Windows machines, it also tells me this:
Algorithm-Diff-1.15: []
DBIx-AnyDBD-2.01:
- action: FAIL
distversion: DBIx-AnyDBD-2.01
id: 79987
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/79987
version: 2.01
Data-UUID-0.11:
- action: FAIL
distversion: Data-UUID-0.11
id: 145033
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/145033
version: 0.11
- action: FAIL
distversion: Data-UUID-0.11
id: 146960
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/146960
version: 0.11
Pixie-2.06: ~
Sub-Uplevel-0.09: []
Test-Class-0.03:
- action: FAIL
distversion: Test-Class-0.03
id: 144608
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/144608
version: 0.03
Test-Differences-0.47: []
Test-Exception-0.15: []
Test-Tester-0.09: []
Text-Diff-0.35: []
In other words, there are no test reports for Windows users of Pixie, but
that's likely because they can't get several distros that Pixie requires to
work on Windows (Test-Class, DBIx-AnyDBD-2.01, and Data-UUID-0.11).
This information would be of use to various quality-assurance types, as well
as the module author. It's probably of use to module users too.
Re: Redoing the Phalanx 100
> Last year, I got different logs from Graham and Pair. Any other > suggestions since they're apparently the same now? Mirror-owners I > should talk to? You could ask Graham for the search.cpan.org logs. Those are potentially interesting. -R
Re: Redoing the Phalanx 100
> I'll be redoing the Phalanx 100 this week. I'm hoping to get FTP logs > from pair.com and from cpan.org. If anyone else has FTP logs they can > submit to me, I'd love to have 'em. $ host cpan.org cpan.org has address 66.39.76.93 $ host cpan.pair.com cpan.pair.com has address 66.39.76.93
Perl5 Bug Summary
[ We're down a handful this week... but not by much... thanks to Steve
Peters for going through some of the old ones and identifiying things
that can be closed. ]
Perl5 Bug Summary
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Generated at Mon Sep 6 13:00:02 2004 GMT
---
* Total Issues
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Total Issues
Open Tickets: 1905
---
New Issues
New issues that have not been responded to yet
7-14 days old
31300 PerlIO::via UTF8 method
14-21 days old
31227 perldoc -f, -q ignores extra arguments with no notice
Over 21 days old (trimmed)
30051 Minor copy-paste bug in File::Spec::Win32->splitpath()
30123 foreach ("", "a".."zz") confuses range optimizer
30296 localizing $? loses exit status from die()
30377 sort SUBNAME LIST
30406 File Find anomaly under windows
30424 BUG REPORT PERL / CGI ...: CGI / mod_perl / $query->defaults('defaults')
30507 FindBin::Bin 1.44 returns path with terminating slash
30563 [PATCH] Storable::dclone fails for tied elements
30576 Test::More thinks "" eq undef in hash value
30584 Test::More is_deeply bug
30622 -e tests not reliable under Win32
30633 Perl's "do" operator with a variety of absolute paths under Cygwin
30660 Repeated spaces on shebang line stops option parsing
30661 sort function @args will not autoload
30673 Missing getmagic in Digest::MD5
30715 IPC::Open3 child may return in the child process
30774 Encode::decode doesn't support CHECK=FB_CROAK
30807 Misleading error message from Storable
30811 build fail, perl 5.8.4, ia64-unknown-linux-gnu, gcc 3.3.4
30858 -wi but no file
30933 "free to wrong memory pool" using DBI, FetchHashKeyName and
selectall_hashref
30978 "make test" op/write failure
31028 perl -i fails on Win32 unless a backup string is provided for -i option
31080 make failure report & plea for assistance
31089
---
Overview of Open Issues
Operating System Severity Type Perl Version
aix 28 abandoned 1 5005threads 0 1.00
All6 fatal 2 bounce0 5.000 0
bsdos 6 High 146 Bug 1 5.002 0
cygwin20 low 755 compiler 0 5.003 0
cygwin_nt 0 medium413 configure 1 5.004 0
darwin10 none 13 core581 5.004_00 0
dec_osf 16 Normal 2 dailybuild0 5.004_01 0
dgux 0 unknown 0 docs 15 5.004_02 0
dos2 Wishlist 14 duplicate 0 5.004_03 0
dynixptx 0 install 54 5.004_04 0
freebsd 48 library 252 5.004_05 1
generic 47 notabug 86 5.005 0
gnu0 notok 8 5.005_01 0
HPUX 29 ok0 5.005_02 1
irix 10 Patch 2 5.005_03 41
irix64 0 regex 6 5.005_04 1
Linux571 sendToCPAN1 5.6.0186
lynxos 0 Todo 1 5.6.1213
mac0 unknown 287 5.6.2 1
machten1 utilities30 5.7.0 24
macos 0 wontfix 0 5.7.1 7
MacOS X1 5.7.2 28
mswin32 88 5.8.0257
netbsd
Re: Fwd: Out of Office Contact
Mr. Cowgill's computer did not send such a message to the list. (It's not in the archive.) He sent it to you directly. -R At Wed, 22 Dec 2004 12:27:51 -0800 (PST), Ovid wrote: > > OK, everyone send Mr. Cowgilll a polite message letting him know that, > in the future, he needs to not send these messages to mailing lists. > He'll feel really bad about his poor etiquette and we can say "only > Cowgills get the blues." > > Ooh, that was awful, awful, awful. Never let me near a pun again, > please. > > Cheers, > Ovid > --- [EMAIL PROTECTED] wrote: > > Subject: Out of Office Contact > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Date: Wed, 22 Dec 2004 19:55:11 + > > > > I will be out of the office starting 21/12/2004 and will not return > > until > > 31/12/2004. > > > > I am away today. Talk to Simon Fairey if you have any urgent issues. > > = > Silence is Evil > http://users.easystreet.com/ovid/philosophy/decency.html > Ovid http://www.perlmonks.org/index.pl?node_id=17000 > Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Module::Phalanx100
This isn't a bundle. It just provides a list of modules, though I guess something could parse the Bundle::Phalanx, thanks. On 20/03/2005 23:43 Andy Lester wrote: On Mar 20, 2005, at 4:18 PM, Robert Rothenberg wrote: FYI, I've uploaded Module::Phalanx100 to CPAN in to $CPAN/authors/id/R/RR/RRWO/Module-Phalanx100-0.01.tar.gz There's already a Bundle::Phalanx.
Module::Phalanx100
FYI, I've uploaded Module::Phalanx100 to CPAN in to $CPAN/authors/id/R/RR/RRWO/Module-Phalanx100-0.01.tar.gz It simply contains a list of the Phalanx distributions from the project web site at http://qa.perl.org/phalanx/. It's provided so that anyone who needs a consistent list can use it rather than importing a new list. (Of course the module will beed to be updated when a new Phalanx 100 list is updated.) Regards, Rob
How to force tests to issue "NA" reports?
Is there a way tests to determine that a module cannot be installed on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not Applicable) report? CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but that is not always appropriate in cases where a module runs on many platforms except some that do not have the capability. There's also a separate issue of whether "NA" reports should be issued if a library is missing. (Usually these come out as failures.) Regards, Rob (Co-author of CPAN::YACSmoke)
Some ideas (was Re: How to force tests to issue "NA" reports?)
I'm all for something like this, though I prefer "requires_libraries"
instead. (Listing libraries distinct from applications is a grey area,
so best to put them under one term.)
Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set of library and application names.
Implementing platform-independent logic to find these libraries is
another matter.
Here's an idea. A module namespace called Config::Libraries, such as
Config::Libraries->info('libgd')
which returns a hash of relevant information about the library. Some of
the hash keys would be standardized, such as one to return a path to
where the library or application is installed, another to return the
version. (It would return undef if the library was not installed.)
This information would be read from an adequate text configuration file
format (YAML or IniFile).
There should be another interface to update the config file easily,
along with a command-line script to do this.
Library installation utilities can use this script, or users can use it
to manually update the config as needed.
The module would have some messy installation procedure that sets up an
initial script. Ideally it should have Platform-specific parts inside
generic wrapper methods. There might be a separate installation file
for each application that uses these methods to configure itself: this
way adding a new library to the utility is a matter of adding script.
Pseudo-library names could be given to special capabilities that some
systems do not have.
The downside is controlling the library namespace. Whoever controls the
Config::Libraries module would have the de facto control, which is
probably good enough for the time being.
That said, who has time to work on such a project? I've got my hands
full already.
Regards,
Rob
On 08/04/2005 15:52 David Cantrell wrote:
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.
Re: How to force tests to issue "NA" reports?
Same here. On 08/04/2005 20:02 Ken Williams wrote: On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote: die "NA: $reason"; Since, at the moment, we're having trouble putting together a system to cover the possible reasons for an NA report let the module author figure it out. Its simple and minimal. I like it.
SKIP blocks and the debugger
Does anyone else find that SKIP: { } blocks bugger up the debugger?
I'll be happily bouncing on the "n" key to get to round about the
vicinity of the failing test, and then blam, it sees a skipped test
and just fast-forwards to the end.
K.
--
Kirrily Robert
[EMAIL PROTECTED]
http://infotrope.net
Re: Trends in Code Quality
I'm with Aristotle. I think it's an urge that's come out of the
development community -- specifically, *certain* development
communities -- rather than from an end-user desire for quality. Many
of the best -tested pieces of software are the infrastructure type
things that only developers ever really know about, and functional
testing ("does this software do what I want it to?") is far less
common than unit testing at the API level.
In my experience developers latch on to test-driven development like
a crack habit because once they get into the swing of it, it really
is a very effective, stress-reducing way to work.
K.
Info from Devel::Cover
I've got a guy at work who wants to take coverage reports and bung them in a database so he can track historical coverage data. As I see it, he needs to somehow parse the stuff in cover_db/ but neither he nor I understand what's in there. Do any modules already exist for this? I believe the thing that generates the coverage reports currently is C code or something? So isn't there anything CPANish to do this? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://infotrope.net/
RE: Anyone experiencing problems with rt.cpan.org?
There were some people talking about problems with it the other day (Thursday?) on magnet #perl. I think Adam Kennedy mentioned slowness, and Jesse was around at the time and sounded like he was going to look into it. Yeah, I know, vague. K.
Re: Time for a Revolution
chromatic wrote: On Friday 14 July 2006 12:27, Jonathan Rockway wrote: I should be more clear; I'm looking for 10-15,000 word short books on very specific areas -- XML Processing with Perl, Writing Ajax Applications with Perl, Refactoring Perl, et cetera. I'm not ruling out a book or discouraging people from submitting book ideas, just pointing out that it's much easier and faster to write and produce a short, focused manuscript than a large project. -- c That would be cool. Haven't "short" focused hot topical books on various subjects. It would be really good for new users of Perl. :Robert
Fixtures
Does anyone here understand "fixtures" as a testing concept, and could they please explain it to me in a Perlish way? At least half of what I've heard described is what I usually achieve with a t/data/ directory, and another half is what I'd do by writing a specialized Test::Builder-based module. K.
RE: Fixtures
Thanks all, especially Ovid who came closest to answering the actual question, i.e. can someone explain it to me *in a perlish way*. Ovid's example used Test::Class's setup/teardown; would anyone else be able to provide confirm that I'm making sense in the following Test::Harness/Test::More style example: 1. Assume a test file t/foo.t 2. Assume a directory t/data (or t/fixtures if you will -- I just call it data in my own tests). 3. Create a file t/data/foo.yml (or whatever data format) containing the data needed by the tests in foo.t 4. At the beginning of foo.t, load data/foo.yml into whatever data structure (memory, SQLite, real database, etc) 5. Run tests against foo.t 6. When foo.t exits, tear down the data created in step 4. Yes? In other words "fixtures" is just a jargony name for t/data/, right? And, is the above setup/teardown stuff right, or would you do it before each individual test? That would seem to be nearly nonsensical, but then, I've seen stupider ideas. My earlier comment about Test::Builder-based test modules was that some of the fixtures stuff I've seen used repeated code chunks to go over the contents of foo.yml, for instance doing validation runs against each record, and it looked to me as if the Perlish way to do that is to write a test module that provides record_is_valid() and related stuff. As I understand it now, this isn't actually part of "fixtures" conceptually, it's just something that one might tend to see near fixtures. K.
Tests fail under load
We've got a situation where we have a suite of tests for a web app. It starts of testing the lib/ and whatnot, but eventually gets to the point where it uses Test::WWW::Mechanize to go fetch stuff from the developer's sandbox website and do a sanity check on the web application itself. The problem is that all the developer sandbox websites run on one server that's groaning under the strain. It's in the process of being replaced but we're not there yet. The upshot of this is that on a good day, the web tests take ages to run, and on a bad day they time out. It's got to the point where the developers just kind of mentally tune out failures in the web tests, and I'm worried about the "broken window" effect. Any suggestions for how to work around this? All I've got so far is the idea of splitting out the web tests into another directory, and treating them as "functional tests" that developers would typically run less often than the unit tests. K.
What was I thinking?
In September 2001, apparently all aglow in the excitement of all the talk that was going on about testing and whatnot, I wrote a module called CPAN::Test::Reporter. (http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at it, I have no idea what I was thinking or why I thought it was necessary at the time. The only hint is in the credits where I say that it's based on the cpantest script by Kurt Starsinic. Presumably I thought it would be useful to have a modular version of it. I'm pretty sure nobody uses it (CPANTS reports that it's not a dependency for any other module). It looks like Test::Reporter is a newer module that does what I was trying to do, and is more up to date. What I want to know is, should I just bin it? Or might it, in fact, be useful to someone somehow? Or is it just bad form to completely delete CPAN modules? I guess I could update it with a new version that says "Don't use me." K. -- Kirrily Robert [EMAIL PROTECTED] [EMAIL PROTECTED] http://infotrope.nethttp://search.cpan.org/author/SKUD
what was I thinking?
In September 2001, apparently all aglow in the excitement of all the talk that was going on about testing and whatnot, I wrote a module called CPAN::Test::Reporter. (http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at it, I have no idea what I was thinking or why I thought it was necessary at the time. The only hint is in the credits where I say that it's based on the cpantest script by Kurt Starsinic. Presumably I thought it would be useful to have a modular version of it. I'm pretty sure nobody uses it (CPANTS reports that it's not a dependency for any other module). It looks like Test::Reporter is a newer module that does what I was trying to do, and is more up to date. What I want to know is, should I just bin it? Or might it, in fact, be useful to someone somehow? Or is it just bad form to completely delete CPAN modules? I guess I could update it with a new version that says "Don't use me." K. -- Kirrily Robert [EMAIL PROTECTED] [EMAIL PROTECTED] http://infotrope.nethttp://search.cpan.org/author/SKUD
confused by Devel::Cover
This one's for Paul or anyone else who happens to know :) After hearing about Devel::Cover at YAPC::E's CPANTS session, I thought I'd pull it down and take a look at it. Well, I don't understand it. This is probably because I've never used such a thing before. So here are some questions and, I guess, a request for more (or rather, clearer) documentation of the usage and features of the module. Firstly, let me say that I've read the perldoc and also did a Google search and found http://www.bullseye.com/coverage.html. The general concepts are clear enough to me now. Where I have the problem is in relation to usage. I'm totally confused wrt finding out how much of a module Foo::Bar is covered by the tests in t/foobar.t I tried a simple "perl -MDevel::Cover foobar.t" and it told me I had 100% statement and condition coverage. It looked to me as if it was just looking through foobar.t and not actually getting down into Foo::Bar. Can anyone please clarify this a bit? K.
Re: confused by Devel::Cover
| > Can anyone please clarify this a bit? | | With respect to exercising modules, this should all work. Did the | module pass its own tests? Actually, there's only one test at the | moment, but it does include a module. What you did should have worked. | You should have got a report about t/foobar.t and Foo::Bar.pm. I've run | some Gedcom.pm tests, and they seemed to give reasonable results (from | the point of view of being believable, rather than having good coverage.) Here's what I got... tanqueray:~/code/reefknot/Net-ICal/t> perl -MDevel::Cover embedded-Net-ICal-Component.t ... lots of output, blah blah blah... 1..13 # Looks like you failed 6 tests of 13. # Looks like your test died just after 13. -- -- -- -- -- -- File stmt branch path cond total -- -- -- -- -- -- embedded-Net-ICal-Component.t 79.17n/an/a 100.00 79.17 Total 79.17n/an/a 100.00 79.17 -- -- -- -- -- -- As far as I can see, it never got down into the module. The module's called like this, from embedded-Net-ICal-Component.t ... use lib "./lib"; use Net::ICal; A! *There's* my problem... I was calling it from the wrong place. When I move back up a directory and run "perl -MDevel::Cover t/embedded-Net-ICal-Component.t" I get this: -- -- -- -- -- -- File stmt branch path cond total -- -- -- -- -- -- lib/Net/ICal/Alarm.pm 100.00n/an/a 9.09 60.00 lib/Net/ICal/Attendee.pm 0.00n/an/a 0.00 0.00 lib/Net/ICal/Calendar.pm 0.00n/an/a 0.00 0.00 lib/Net/ICal/Component.pm 47.44n/an/a 7.32 39.09 lib/Net/ICal/Duration.pm 0.87n/an/a 0.00 0.61 lib/Net/ICal/ETJ.pm 6.45n/an/a 0.00 4.35 lib/Net/ICal/Event.pm0.00n/an/a 0.00 0.00 lib/Net/ICal/Freebusy.pm 7.69n/an/a 0.00 5.88 lib/Net/ICal/Journal.pm 0.00n/an/a 0.00 0.00 lib/Net/ICal/Period.pm 0.00n/an/a 0.00 0.00 lib/Net/ICal/Property.pm45.45n/an/a 0.00 39.22 lib/Net/ICal/Recurrence.pm 0.00n/an/a 0.00 0.00 lib/Net/ICal/Time.pm 3.70n/an/a 0.00 3.45 lib/Net/ICal/Todo.pm21.05n/an/a 0.00 14.29 lib/Net/ICal/Trigger.pm 83.33n/an/a 0.00 58.82 lib/Net/ICal/Util.pm 0.00n/an/a 0.00 0.00 t/embedded-Net-ICal-Component.t100.00n/an/a 100.00 100.00 Total 16.20n/an/a 1.33 12.58 -- -- -- -- -- -- That's *much* more like what I expected :) Next time I'll just talk to the teddy bear. K.
Pod::Coverage random silliness
This script...
#!/usr/bin/perl -w
use strict;
use Pod::Coverage;
use ExtUtils::Installed;
my $m = ExtUtils::Installed->new;
my @modules = $m->modules();
print "Checking POD coverage...\n";
my %coverage;
foreach my $mod (@modules) {
my $pc = new Pod::Coverage package => $mod;
$coverage{$mod} = $pc->coverage() || 0;
}
foreach my $out (sort by_coverage keys %coverage) {
my $bar = "*" x ($coverage{$out} * 40), "\n";
printf("%30s %3d%% %s\n", $out, $coverage{$out}*100, $bar);
}
sub by_coverage {
$coverage{$b} <=> $coverage{$a};
}
... gives us ...
Checking POD coverage...
Pod::Coverage 100%
Digest::MD5 90%
Pod::Tests 87% ***
Text::Template 54% *
Net::Telnet 38% ***
Test::Simple 33% *
Test::Harness 33% *
Perl0%
Term::ReadLine0%
Data::ShowTable0%
File::Spec0%
Pod::Parser0%
Msql-Mysql-modules0%
Devel::Symdump0%
CPAN0%
Image::Magick0%
YAML0%
Term::ReadKey0%
Fwd: FAIL Module-InstalledVersion-0.02 cygwin-multi 1.3.2(0.3932)
Anyone know what might cause this? The same reporter also had the same problem with CPAN-Test-Reporter. K. This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to [EMAIL PROTECTED] to keep other test volunteers informed and to prevent any duplicate effort. -- some tests failed: == $ make test PERL_DL_NONLAZY=1 /bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.1/cygwin-multi -I/usr/lib/perl5/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/embedded-Module-InstalledVersion.FAILED tests 1-7 Failed 7/7 tests, 0.00% okay Failed Test Status Wstat Total Fail Failed List of Failed -- t/embedded-Module-InstalledVersion.t 77 100.00% 1-7 Failed 1/1 test scripts, 0.00% okay. 7/7 subtests failed, 0.00% okay. make: *** [test_dynamic] Error 255 BUT: $ perl -Mblib t/*.t Using /perl/cpantest/Module-InstalledVersion-0.02/blib ok 1 - use Module::InstalledVersion; ok 2 - create new object for CPAN ok 3 - Picked up version of CPAN ok 4 - create new object for Fcntl ok 5 - Picked up version of Fcntl ok 6 - create new object for Text::Wrap ok 7 - Picked up version of Text::Wrap 1..7 Gerrit -- Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=cygwin, osvers=1.3.2(0.3932), archname=cygwin-multi uname='cygwin_nt-4.0 loreley 1.3.2(0.3932) 2001-05-20 23:28 i686 unknown ' config_args='-de -Dusemultiplicity' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include', optimize='-O2', cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3-5 (cygwin special)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='ld2', ldflags =' -s -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -lcrypt perllibs=-lcrypt libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl5_6_1.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s' cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Test::Mail request for comments
At work at e-smith, I'm working on an app that sends a lot of email here
and there and everywhere. It would be *really* handy for me to have a
way to test that the email it's sending is right. So this morning in
the shower (where I do all my best thinking) I was considering writing
Test::Mail.
Below is some rough pre-documentation for it. None of it's written yet,
so don't ask me about the details. However, I wanted to throw it out to
this list to say "I'm working on it" and also "Do you think I'm heading
in the right direction?"
Comments welcome.
K.
NAME
Test::Mail - Test framework for email applications
SYNOPSIS
use Test::Mail log => $logfile;
sub first_test { }
sub second_test { }
...
DESCRIPTION
Test::Mail provides a framework for testing applications which send and
receive email.
A typical example of an email application might send a notification to a
certain email address, setting certain headers in certain ways and
having certain content in the body of the email. It would be nice to be
able to test these things automatically, however most email applications
are currently tested by visual inspection of the email received.
Test::Mail allows you to automate the testing of email applications by
piping any relevant email through a Test::Mail script.
"Relevant" email is identified by the presence of an X-Test-Mail:
header. You should set this email in your application or whatever you
use to generate the mail.
X-Test-Mail: birthday_notification
The value of that header is the name of a subroutine which exists in
your Test::Mail script. The subroutine contains Test::More tests to run
on the email:
sub birthday_notification {
is($header->get("From:"), '[EMAIL PROTECTED]', "From address check");
like($body, qr/Today's Birthdays/, "Email body check");
}
This allows you to have tests for multiple different kinds of email in
one script.
Note that $header and $body are set by Test::Mail for your convenience.
$header is a Mail::Header object. $body is the body of the email as a
single string. MIME attachments etc are not supported (yet).
The results of the tests run are output to the logfile you specify, and
look something like this:
# test results for birthday_notification for <[EMAIL PROTECTED]>
ok 1 - From address check
ok 2 - Email body check
# test results for support_request for <[EMAIL PROTECTED]>
ok 1 - To address check
not ok 2 - Subject line
not ok 3 - Included ticket number
ok 4 - Body contains plain text
Note that while these are roughly similar to normal CPAN test output
conventions, counting only occurs on a per-email basis
Sending incoming mail to Test::Mail
To call Test::Mail, simply put a suitable filter in your .procmailrc,
Mail::Audit script, or whatever you use to filter your email. Here's how
I'd do it with Mail::Audit:
if ($mail->{obj}->head->get("X-Test-Mail")) {
$mail->pipe("testmail.pl");
}
If for some reason you want to test mail that doesn't already have an
X-Test-Mail: header, you could do something like:
if ($mail->{subject} =~ /test/i) {
$mail->{obj}->head->add("X-Test-Mail", "subject_auto");
$mail->pipe("testmail.pl");
}
Unaddressed issues
The above is a rough outline of version 1. There are several issues I
don't yet know how to deal with, which I'm listing here just in case
anyone has any good ideas:
* Sending output somewhere more useful than a logfile
* Integrating into a real "test suite" that's friendly to
Test::Harness
* Handling MIME in a suitable way
SEE ALSO
the Test::More manpage, the Mail::Header manpage, the Mail::Audit
manpage
AUTHOR
Kirrily "Skud" Robert <[EMAIL PROTECTED]>
testing web foo with Test::More
OK, I've been putting off figuring this out for ages, but here it is:
#!/usr/bin/perl -w
use strict;
use Inline 'WebChat';
use Test::More 'no_plan';
ok(google(), "Can get google");
__END__
__WebChat__
sub google {
GET http://google.com/
EXPECT OK && /google/i
}
That's it. Easy.
I'm updating the Test::FAQ on the Wiki to show this.
K.
Re: testing web foo with Test::More
On Tue, Oct 09, 2001 at 09:17:06AM -0400, Shane Landrum wrote: | On Sun, Oct 07, 2001 at 03:30:58PM -0400, Kirrily 'Skud' Robert ([EMAIL PROTECTED]) |wrote: | > OK, I've been putting off figuring this out for ages, but here it is: | | | | Another way to accomplish the same thing, that I hacked up to | test an internal password-protected web gadget: Well, WWW::Chat just gets pre-processed into LWP code. But I like it because it's at least an order of magnitude less LOC for anything more than: ok(LWP::Simple::get($url), "Get $url"); For instance, if you want to get a page, fill in a form, look at the results, WWW::Chat is *definitely* your friend. I'm about to start using it with FormMagick. K.
Test::More and WWW::Chat fighting over fail()
Both Test::More and WWW::Chat export a routine called fail(). This
makes it rather hard to write tests for web stuff using both these
modules.
Since WWW::Chat's fail() is only used internally, could I possibly
request that it be changed to not export, and/or rename it _fail, or
whatever. Anything.
Also, there's some weirdness with webchatpp's generated code if your
WWW::Chat script was inside subroutines (or presumably other blocks).
Here's a real life example:
#!/usr/bin/perl -w
use strict;
use Inline 'WebChat';
use Test::More 'no_plan';
ok(manager(), "Manager is running and requires login");
ok(manager_admin_login(), "Can login to manager as admin");
__END__
__WebChat__
sub manager {
GET http://192.168.1.1:980/
EXPECT 401
}
sub manager_admin_login {
$ua->credentials(
"192.168.1.1:980",
"March Networks SME Server manager",
"admin",
$password
);
GET http://192.168.1.1:980/
EXPECT OK && /March Networks Server manager/
}
If you run that through webchatpp you'll see that there are evals that
cross over between subs, like this:
sub foo {
eval {
blah blah
}
sub bar {
blah blah
more blah
} # end eval here, WRONG
}
It would be nice if we could get this to work ;) But as a workaround, I
can live with one sub per script for now, I guess :-/
K.
Test::Harness in Test-SDK conflicts with Perl
I've built an RPM of Test-SDK using cpan2rpm, and when I try to install it on a Red Hat system it says: [root@e-smith skud]# rpm -Uvh perl-Test-SDK-0.04-1.i386.rpm Preparing...### [100%] file /usr/lib/perl5/5.6.0/Test/Harness.pm from install of perl-Test-SDK-0.04-1 conflicts with file from package perl-5.6.0-12 file /usr/share/man/man3/Test::Harness.3pm.gz from install of perl-Test-SDK-0.04-1 conflicts with file from package perl-5.6.0-12 Not sure what to do about this. Suggestions welcome. I'm going to forward this to our internal e-smith RPM weenies, who might have some ideas, but I thought I'd raise it on perl-qa too, in case anyone else had thoughts. K.
Re: is() with arbitrary comparisions
On Wed, Dec 19, 2001 at 03:50:12PM -0500, Michael G Schwern wrote: > On Tue, Dec 11, 2001 at 01:52:12PM -0500, Kirrily Robert wrote: > > Are we doing the time warp again, or are the Huskies just tired of > pulling the packets across the border? > > > > How about: > > > > compare($foo, "<=", $bar) > > cmp_ok(). Close. My mail server got all confused and constipated for a few days. Sorry for the old email suddenly appearing today :) K.
Interactive tests?
Using Test::More, how can I intersperse stuff for user interaction? For
instance:
print "Please enter the hostname/ip for the server [localhost]: ";
my $host = ;
print "Please enter the admin password [default]: ";
my $password = ;
$agent = esmith::FormMagick::Tester->new(host => $host, password => $password);
isa_ok($agent, 'esmith::FormMagick::Tester');
is($agent->{password}, $password || 'default', "Set password correctly");
Test::More takes control of so much stuff that my user prompts are never
printed.
K.
Updates to modules-related pod
In looking through perlnewmod, perlmodlib, perlmodstyle, and other related POD today, I found that most of them are out of date and not in keeping with recent trends in module writing, testing/QA, etc. So, with a due sense of foreboding, I have dived in once again. Errr, hi, long time no p5p. Here's an initial patch to perlnewmod, the main points of which are: * recommend module-starter over h2xs * modernise recommended h2xs invocation * modernise list of recommended modules to learn from * refer to Test::Simple and Test::More instead of Test * modernise PAUSE-related instructions I know module-starter (part of the Module::Starter package) isn't part of the core, but I figure that there are two answers to that: 1) propose M::S for inclusion in the core, or 2) since this doc is aimed at CPAN authors anyway, let's assume that it won't kill them to get the module from there. Thinking of attacking perlmodlib next, and removing a lot of those long lists. I'm pretty sure we're better off pointing to web resources for most of the gunk that's in there. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Fist it. It's my solution to everything." -- Penny (from the Netizen quotes file) diff -ruN bleadperl/.patch myperl/.patch --- bleadperl/.patch2004-08-16 14:19:59.0 -0400 +++ myperl/.patch 1969-12-31 19:00:00.0 -0500 @@ -1 +0,0 @@ -23219 diff -ruN bleadperl/pod/perlnewmod.pod myperl/pod/perlnewmod.pod --- bleadperl/pod/perlnewmod.pod2003-08-27 10:27:41.0 -0400 +++ myperl/pod/perlnewmod.pod 2004-08-16 15:59:16.0 -0400 @@ -73,9 +73,10 @@ Dig into a bunch of modules to see how they're written. I'd suggest starting with L, since it's in the standard -library and is nice and simple, and then looking at something like -L, L and then some of the -C modules if you're planning on writing object oriented code. +library and is nice and simple, and then looking at something a little +more complex like L. For object oriented +code, C or the C modules provide some good +examples. These should give you an overall feel for how modules are laid out and written. @@ -84,8 +85,8 @@ There are a lot of modules on CPAN, and it's easy to miss one that's similar to what you're planning on contributing. Have a good plough -through the modules list and the F directories, and make sure -you're not the one reinventing the wheel! +through the L<http://search.cpan.org> and make sure you're not the one +reinventing the wheel! =item Discuss the need @@ -119,18 +120,29 @@ =over 3 -=item Start with F +=item Start with F or F -Originally a utility to convert C header files into XS modules, -L has become a useful utility for churning out skeletons for -Perl-only modules as well. If you don't want to use the -L which splits up big modules into smaller -subroutine-sized chunks, you'll say something like this: +The F utility is distributed as part of the +L CPAN package. It creates a directory +with stubs of all the necessary files to start a new module, according +to recent "best practice" for module development, and is invoked from +the command line, thus: -h2xs -AX -n Net::Acme +module-starter --module=Foo::Bar \ + --author="Your Name" [EMAIL PROTECTED] -The C<-A> omits the Autoloader code, C<-X> omits XS elements, and C<-n> -specifies the name of the module. +If you do not wish to install the L +package from CPAN, F is an older tool, originally intended for the +development of XS modules, which comes packaged with the Perl +distribution. + +A typical invocation of L for a pure Perl module is: + +h2xs -AX --skip-exporter --use-new-tests -n Foo::Bar + +The C<-A> omits the Autoloader code, C<-X> omits XS elements, +C<--skip-exporter> omits the Exporter code, C<--use-new-tests> sets up a +modern testing environment, and C<-n> specifies the name of the module. =item Use L and L @@ -164,10 +176,9 @@ =item Use L - wisely! -C provides stubs for L, which gives you a -standard way of exporting symbols and subroutines from your module into -the caller's namespace. For instance, saying C -would import the C subroutine. +L gives you a standard way of exporting symbols and +subroutines from your module into the caller's namespace. For instance, +saying C would import the C subroutine. The package variable C<@EXPORT> will determine which symbols will get exported when the caller simply says C - you will hardly @@ -180,21 +191,23 @@ The work isn't over until the paperwork is done, and you're going to need to put in some time writing some documentation for your module. -C will provide a stub for you to fill in; if you're not sure about -the format, look at L for an introduction. Provide a g
Re: Updates to modules-related pod
On Tue, Aug 17, 2004 at 07:16:52PM +0200, Tels wrote: > > +it connected to the rest of the CPAN, you'll need to go to "Register > +Namespace" on PAUSE. Once registered, your module will appear in the > +by-module and by-category listings on CPAN. > > Only a very few of my modules are registered in that namespace. For > instance, Math::BigInt::Pari is, while Math::BigInt::GMP is not. The reason > is simple: It never worked. I think I sent at least GMP at least two times > to the register namespace black hole, and it never happened. > > AFAIR there was only one guy (Hi Andreas :) working on the registrations, > and only every two weeks on Sunday or something like that. There are multiple people who have the ability to administer CPAN in that fashion - I'm one of them, for what it's worth, though I'll admit I haven't touched it in years while I've been on hiatus. I forget who else. > So, two (honest) questions: > > * does it work better now, e.g. should I resub mit my module(s)? > * What exactly is the registration good for? I mean, all my dozend or so > modules work, and are "connected to the rest of CPAN" or whatever this > means. Having your module registered means it will show up in the category listing as seen on the front page of search.cpan.org and in the by-module and by-category listings (which, yeah, nobody uses anymore AFAIK). However, the "by recentness" list at http://cpan.org/modules/01modules.mtime.html indicates that something at least is being updated very frequently, at least daily, and I suspect automatically. So the question is, which bits are updated automatically by the mere fact of a module author doing the "register namespace" thing, and which bits require manual intervention? > So, if the "register namespace" isn't too usefull and/or doesn't work fine, > why burden new authors with it? I raised this on [EMAIL PROTECTED] the other day in fact. "Register namespace" is useful in some ways and not in others, it seems. The most useless part of it is the "published modules list", and IMO we should get rid of the thing. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "I've decided to rename [Connect's Melbourne border router] 'Madi's Pants' because it keeps dropping." -- Madi (from the Netizen quotes file)
Re: Test::DoubleQuotedEntities
On Tue, Aug 24, 2004 at 01:51:12PM -0400, David H. Adler wrote: > > > (oh, and as an aside I released a new Acme::Test::Buffy, with slightly > > improved documentation and spelling too - but no one cares about that) > > Says who? *I* care. And you have no idea how stupid I felt submitting an RT on that module, either. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ There's too much blood in my caffeine system.
