Re: Google Summer of Code and Google Code In
On Fri, Feb 19, 2016 at 07:19:05AM +0100, Kaare Rasmussen wrote: > > I have not seen the schedule for signup for this year. I expect > that we will participate again. > > Apparantly, deadline is very close for organizations now: > https://summerofcode.withgoogle.com/ There won't be a TPF application this year. We felt that we had left it too late to put together a credible application. I feel a bit bad that I didn't remember in sufficient time to start the process, but it seems that no one else did, either. Our plan is to start work on GSoC this autumn so that we have plenty of time to get everything organised and make a good application for next year. If we are accepted we want to ensure that the programme runs well for students and mentors. GCI is a lot of fun, but also a lot of work. When we participated a few years ago we had fifty mentors and over 300 tasks. It was almost a full-time job looking after the process. (The students really need a quick turnaround on their work.) If we want to run that again then we probably need to start thinking about it in the summer and put together a group of people who will have time in December and January to devote to it. > I hope the People In Power knows and has it under control. There aren't really People In Power. I mean, there are, nominally, but in reality it is whoever volunteers or is volunteered. And we are always in need of volunteers. So if anyone wants to ensure that there is a TPF presence in GSoC and/or GCI next year, please raise your hand, jump around, shout and, above all, start doing whatever is necessary to make that happen. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Perl 6 advocacy needs a mailing list
On Fri, Feb 05, 2016 at 07:18:01AM -0600, Tom Browder wrote: > I would like to see such a list. It would help separate some of us > bloviators, dreamers, and hand wavers from the others on the users list. Any reason not to use advoc...@perl.org ? It is currently low-volume (one message in the last 18 months) and has the advantage of already existing. I'm not convinced that Perl6 needs a list separate to Perl5. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: [perl #65942] Missing %*ENV values are defined, but don't exist
On Sun, May 24, 2009 at 02:18:26PM -0700, Larry Wall wrote: On Sun, May 24, 2009 at 12:08:58PM -0700, yary wrote: : I don't recall if defined autovivifies, but assuming it does that would make : sense. : : Agreed that if defined autovivifies, it explains observed behavior in : current rakudo. But should defined autovivify? That goes against my : intuition. Mine too. This surprising autovivification in what does not at first--or even second--glance appear to be an lvalue context may be fixed in a future release. OK - strictly speaking that's talking about intervening nested aggregates. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Anyone has perl 1 docs?
On Sun, Jan 13, 2008 at 05:35:57PM -0500, jesse wrote: If only Perl1 source would compile, then it'd be easier, but it doesn't compile on windows (xp) and can't get it working on cygwin either. That sounds like the sort of situation where VMWare Player and, say, an ubuntu or redhat virtual machine might come in really handy. I don't believe Perl 1 was ever ported to Windows. The first MS-DOS port was for Perl3 by Didi Spinellis. See http://www.spinellis.gr/sw/ports/dosperl/ That Didi was doing this sort of thing months before our finals whilst I was probably refitting a clutch, chasing a football around a field, or who-knows-what, probably helps explain why he got a first and I got a 2.1. (Well, that and that he's much cleverer than I am.) Oh, and I had just met my wife-to-be a few months earlier. That probably explains a lot too. In any case, the patch looks fairly minimal - you might be able to retrofit it to Perl1 without too much trouble. But I'd go the virtual machine route too, all else being equal. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Consting args for vmethods
On Mon, Dec 17, 2007 at 09:50:32PM +, Nicholas Clark wrote: On Mon, Dec 17, 2007 at 10:06:42AM -0600, Andy Lester wrote: Andy: My consting has run into its greatest challenge yet. Andy: Making self args to PMCs consts where appropriate. Andy: jarring chord Andy: INTVAL such_and_such_elements( PMC *self ); Andy: Tell me that *self shouldn't be const. Andy: Go on, tell me. Andy: You can't. particle: of course i can't particle: in accessors, self should be constant The equivalent would break in Perl 5, where the objects can change internal private state as a side effect of being read. For example, conversions are cached. Which is where, in C++, you would be using the mutable keyword. I don't think this has yet made it into any C standard, but my knowledge in these areas is a little out of date. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #47886] [TODO] 'make quicktest' target
On Tue, Nov 27, 2007 at 02:01:25PM -0800, Patrick R.Michaud wrote: After much discussion, we decided we'd like to have a make quicktest target that runs a subset of core Parrot tests that verify that the functionality is intact. FWIW, this target is known as coretest in Perl 5. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #43338] [TODO] config/auto/va_ptr.pm: Write unit tests
On Mon, Oct 29, 2007 at 04:39:42PM -0700, James Keenan via RT wrote: Although the percent of statements in this class's source code covered by the test suite and by Configure.pl itself is lower than I normally would settle for (http://thenceforward.net/parrot/coverage/configure-build/config-auto-va_ptr-pm.html), the uncovered statements are highly platform-specific. So there's no point in writing further tests for these statements, as covering them could only meaningfully be done on a different platform -- at which point other statements would become uncovered! Note that you can merge coverage databases, or generate reports from more than one database, for this very reason. But that does have the obvious downside of making the coverage process much more complicated. Still no free lunches, I'm afraid, but at least there's food available if you are hungry enough. Hence, I'm resolving the ticket. Sorry if this opens it up again. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #41897] [BUG]: Parrot::Pmc2c::STMRef gets 'subroutine prederef redefined' warning
On Sun, Mar 18, 2007 at 11:08:24AM -0700, James Keenan wrote: [ I've just noticed this via a summary that I rescued from spamassassin's rather overenthusiastic clutches. Thanks Ann. ] I've found through experience that running Devel::Cover to perform coverage analysis on my code sometimes turns up problems that don't appear when running 'prove' or 'make test' without Devel::Cover. [ snip details ] Ideas? Not really, I'm afraid. I don't think I've seen a similar problem with Devel::Cover and any other code. Devel::Cover has sometimes uncovered questionable constructs that have otherwise gone unnoticed, but my first thoughts would be that it was a bug in Devel::Cover. Has anyone managed to shine any additional light on this in the last six weeks? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #41886] [CAGE] Use lcov to show code coverage
On Sat, Mar 17, 2007 at 02:19:51PM -0700, Paul Cochrane wrote: The lcov tool from the Linux Test Project (http://ltp.sourceforge.net/coverage/lcov.readme.php) can be used to produce html output of code coverage information (I believe this looks similar to Devel::Cover's output). A 'make cover' target should be added to the Makefile and lcov should be run regularly over the parrot source to help guide the testing. Or feel free to let Devel::Cover generate the reports. Devel::Cover comes with a program to translate gcov output into the format that Devel::Cover understands. This is used to generate full Perl 5 coverage reports. See http://www.test-smoke.org/perlcover.shtml If coverage data are available for any other languages involved in Parrot then similar conversions should be fairly simple. And, although I personally prefer a make cover target, the Perl world seems to have settled on make testcover. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Why consting is good
On Sat, Aug 12, 2006 at 08:16:10PM -0500, Andy Lester wrote: I've written up some stuff about why consting is good. It's in the Parrot repository as cage/consting.pod. To my old p5p homies: I send this to you so you don't forget about consting while I'm working over here in Parrotland! Er, right, um, wotcha Andy! =head2 Cconst pointers If a pointer is qualified as const, then its contents cannot be modified. I know you know this, and you even demonstrate it later, but what you are talking about here is a pointer to a constant rather than a constant pointer. =head2 Mixing Cconsts Combining Cconsts on a pointer and its constants can get confusing. Very much so. s/constants/contents/ I suspect? Or maybe s/its constants/what it points to/ ? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Any Clue about Devel::Cover Error Message Corrupted storable file (binary v2.7) at ../../lib/Storable.pm
On Sat, Jul 08, 2006 at 03:44:55PM -0700, Scott Wang wrote: Thanks Paul! (1) Yes, we do send SIGKILL (9) to kill the parent process even the child processes are still running and our purpose is to have a clean kill from root, so, do you think send SIGKILL (2) will be better? or, we could consider to send SIGKILL (2) to kill all the child processes before send SIGKILL (2) to kill parent process, do you think this may help? (2) Maybe you could send it something a little nicer which might allow to process to clean up., any more detail suggestion and example will be appreciated! I'm not quite sure what your environment looks like, so I can only give some general suggestions at best. If you can avoid signals completely, I would try to do that. Maybe you have some other method of IPC going on that you could use to use to send a kill yourself command. Singals in perl used not to be safe, that is they could lead to corruption or crashes. Since 5.8 they have been safe (providing you haven't explicitly made them unsafe). (Hopefully you are not using 5.6.) So if you can send a signal which can be caught, and then set up a signal handler which cleans up (if necessary) and then exists the program, that should allow things to work better. You might like to consider USR1 or USR2 for this, if you are not already using them. Or you might prefer TERM. In any case, you should ensure that it is a signal which can be caught, which is not the case with KILL. (3) We might also consider to give some sleep time before destroy the test object, which causes process killing and cleaning up, but, is there a way we can know Devel::Cover has doen its work to write data? (4) Devel::Cover does its work in the very last END block., does this mean that Devel::Cover will not write data until the main test process run to its end? Sleeping, then killing won't work. Although Devel::Cover collects data the entire time a program is running (unless you turn it off at some point), the data will not be saved until its END block is run. This will normally be the very last END block. This means that unless you let the program run to completion the coverage data will not be fully saved. You might hinder this process by calling _exit, calling exec, sending SIGKILL or doing anything else that stops normal completion of the program. For example, a perl test script loads the perl module that is under testing and excise the functions in that module, sometime the test script needs use system to call some other perl scripts (that also is under testing), Devel::Cover will not write data until the main test script reach its end point or exit? Correct. But the scripts you are calling with system will not have any coverage data collected unless you have arranged for that in some way. And if you do that, the coverage data for those scripts will be written as soon as the scripts exit. (5) Is there a way we can tell which data files (under structure folder?) have been corrupted? Just try reading them with the retrieve method from Storable. Better yet, send me patches for Devel::Cover::DB::validate_db and Devel::Cover::DB::is_valid to do something more than just check that one file exists there ;-) (Those methods should probably be merged too.) (And sorry they are not already written. I suspect something a little more robust there might have saved you a bit of pain.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: TAP diagnostic syntax proposal
On Mon, Jul 10, 2006 at 11:59:27AM -0700, chromatic wrote: On Monday 10 July 2006 11:41, David Wheeler wrote: It's not a gift package delivered by FedEx. What sucks about got? It's the grammatical equivalent of tucking your shirt tail into your underwear before trying to get a date at your family reunion. Wonderful imagery! Whilst I would also like to see something nicer that got, I'm actually more concerned about the ordering. I always expect to see expected first, followed by got or received or whatever, and I end up having to look at the output a lot closer than I think I should in order to get things the right way around. But perhaps it's just my brain that's wired backwards. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Any Clue about Devel::Cover Error Message Corrupted storable file (binary v2.7) at ../../lib/Storable.pm
On Fri, Jul 07, 2006 at 10:26:13AM -0700, Scott Wang wrote: Hi Paul, Even, currently, there is no any zero size data file in structure folder in my regression code coverage run (lots of suites), I still got lots of messages like below: --- Corrupted storable file (binary v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 331, at //Devel/Cover/DB/Structure.pm line 269 END failed--call queue aborted. - Seems some data files got corrupted somehow. The process killing (kill parent process before killing child process and make chid process be terminated abnormally) is one possibility, I also noticed that useing system or other folk method to execute command could also cause this problem. Any clue about above issue Corrupted storable file (binary v2.7) at ... and does anybody also experience this issue and know how to deal with it? Also, does anybody have similar experience on killing process and folking process cause Magic number ... issue and orrupted storable file ... issue? In lieu of discussing either licences or alligators, let me try to answer this. Killing the process sounds like the most likely cause of this problem. If you manage to kill the process while it is writing out a storable file the file will very probably be corrupted. How are you killing the process? Are you sending it SIGKILL (9) for example? Maybe you could send it something a little nicer which might allow to process to clean up. Devel::Cover does its work in the very last END block. You really need to let it run to completion. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Question - (1) Devel:;Cover and B::Deparse issue (2) cover and its momory consuming issue
On Sat, Jun 10, 2006 at 07:54:28PM -0700, Scott Wang wrote: Hi Paul, Thanks a lot for your reply! After I turned off warning in all my product scripts and test scripts which I was running Devel::Cover on, 90% warning messages related B::Deparse deep recursion have gone, and only a few were left in logs. So, from your email, seems like, in order to completely remove those B::Deparse deep recursion warnings from my test log, I should also add no warnings in Devel::Cover code to customize this model and disable warning in it, please advice if my understanding and approach is right or not. If this works then that's fine. You can probably be a bit more specific with 'no warnings recursion', but as I say, it is only a warning. I should sort it out in the Devel::Cover code itself at some point. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Couldn't understand the following message from Devel::Cover ...
On Fri, Jun 16, 2006 at 12:43:11PM +0530, Rajanikanth Dandamudi wrote:
Hi All,
Can some one help me understand why I am getting the following message
on the following perl program :
perl program
#!/usr/local/bin/perl
%hsh = (
ABC = -abc,
DEF = -def,
);
for $key (keys %hsh){
print Key = $key Value = $hsh{$key}\n;
}
=
command used : perl -MDevel::Cover aboveProgram
output:
===
Devel::Cover 0.55: Collecting coverage data for branch, condition,
statement, subroutine and time.
Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
Selecting packages matching:
Ignoring packages matching:
/Devel/Cover[./]
Ignoring packages in:
.
/proj/dite/WorkArea/Raja/perl/lib
/proj/dite/WorkArea/Raja/perl/lib/5.8.8
/proj/dite/WorkArea/Raja/perl/lib/5.8.8/i686-linux
/proj/dite/WorkArea/Raja/perl/lib/site_perl
/proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8
/proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8/i686-linux
Key = ABC Value = -abc
Key = DEF Value = -def
Devel::Cover: Can't find file ../../lib/Storable.pm: ignored.
Devel::Cover: Writing coverage database to
/sp/dftm/Activities/MemoryBIST/pbist/flow/data/cover_db/runs/1150441786.22790.00593
--- -- -- -- -- --
--
File stmt bran condsub time
total
--- -- -- -- -- --
--
...6905/LearnPerl/Hash_Example_2.pl 100.0n/an/an/a 100.0
100.0
Total100.0n/an/an/a 100.0
100.0
--- -- -- -- -- --
--
=
I couldn't understand what the following message means :
Devel::Cover: Can't find file ../../lib/Storable.pm: ignored.
Even though this is being ignored here, this is causing problems down
the line. Can you help me on what this means and how to overcome this ?
What it means is that when Devel::Cover went to examine all the data it
had collected and map it back to reality, it went looking for the source
code to Storable. When perl first loaded Storable it was found in the
relative directory ../../lib/Storable.pm. What that was relative to,
we don't really know. Perl doesn't store that information.
Devel::Cover tries very hard to find that information (I won't go into
the details, but it is messy), but doesn't always succeed. In
particular, this warning is fairly common, and I haven't been able to
track it down, though I suspect it has something to do with Storable
being used by Devel::Cover itself and so it is loaded before
Devel::Cover's hacks get a chance to kick in.
What this means in practice is that you won't get a coverage report for
Storable. But it's pretty unlikely you wanted one anyway, so this
shouldn't be a great problem. So I am interested in what problems this
causes down the line. To stop the warning I suggest the following
options:
1. Fix Devel::Cover. Go on, please. You know you want to ;-)
2. Hack the source to disable the warning.
3. Filter the output.
4. Pretend you didn't see it.
Most people take the fourth option since it really shouldn't cause any
further problems.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Error Message Magic number checking on storable file... when running cover to merge data
On Sat, Jun 10, 2006 at 08:14:09PM -0700, Scott Wang wrote: Hi Paul, You are right, I found a 0 size file under the cover_db/structure folder. After I removed that 0 size file, my cover worked fine to merge all the data and generated HTML file. The 0 size file, I think, is because some test was killed for timeout because of the slow-down of the test process since we instrumented all test and product scripts with Devel::Cover. When the test process was killed and terminated abnormal, I think, Devel::Cover was still trying to grab the test process to generate data, so there was no any data actually got generated because the test processes had been killed. Is this a reasonable explaination to the 0 size data file? It sounds plausible, but there could be any number of reasons. Perhaps the file system filled up, or you have some rogue process running around truncating Devel::Cover databases. But the test process being killed probably has something to do with it. The files in the structure directory contain information about the structure of files. That is, the statements, branches and conditions in the file, and other similar data. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover and HTML::Mason
On Sat, Jun 03, 2006 at 10:18:46PM -0500, jason gessner wrote:
Hi All.
Has anyone successfully used Devel::Cover under mod_perl to do
coverage for a mason application?
My preliminary experiments were mixed. I used D::C from my .pl
handler file and ran apache with -X, but saw inconsistent results
when i did a couple tests.
During the first test, it showed some of the files i had accessed,
but showed no code executed for them. On the second test (second
test being the same thing, but after restarting apache again and
deleting the coverage db), i only saw code referenced by my handler.
Google searches have turned up nada so far.
Has anyone done this before i figure out how to do it?
Devel::Cover should work under mod_perl. I have used it successfully
with the Template Toolkit, but I am not a Mason user and I don't recall
any previous reports of success or otherwise with Mason.
I suggest using Devel::Cover from your mod_perl startup script (see the
docs). You might like to check that $ENV{MOD_PERL} is being set. IIRC
it should be set to 1 under mp1 and 2 under mp2.
When Mason works with Perl code, does it manage __LINE__ and __FILE__
correctly? If so, then Devel::Cover should report coverage at the
correct place. You can probably assume this is OK if error messages
from your template point you to the code correctly.
If you still have problems you might need to come back with a bit more
information.
Good luck.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Error Message Magic number checking on storable file... when running cover to merge data
On Mon, Jun 05, 2006 at 08:13:38PM -0700, Scott Wang wrote: Hi All, I got below error message from running cover to merge my coverage data, any clue? The Magic number checking on storable file ... message also shows up in my test log, I am wondering if this means that my coverage database has corrupted somehow. = Reading database from ... Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 331, at Devel/Cover/DB/Structure.pm line 269 = I think so. Perhaps nothing was written to the database at all? $ perl -MStorable -e 'retrieve /dev/null' Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 331, at -e line 1 -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Question - (1) Devel:;Cover and B::Deparse issue (2) cover and its momory consuming issue
On Sat, Jun 03, 2006 at 08:29:09PM -0700, Scott Wang wrote: Thanks!...Scott Does this mean everything is working OK for you? Deep recursion on subroutine is just a warning, though Devel::Cover seems to tickle it through B::Deparse fairly regularly. I'll try to do something about that one way or another. B::Deparse is used to display the code used in branches and conditions, and also as a handy tool for walking through a complete optree doing stuff at each op. With respect to cover using a lot of memory, yes, I'm afraid that could happen with large databases. The reason is that the database is read into a perl data structure. (The database is really little more than a Storable dump of a Devel::Cover::DB object.) I'm afraid that the pragmatic approach its probably to throw RAM at the hardware. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: question about using cover -ignore and cover -ignore_re
On Mon, May 29, 2006 at 12:44:38PM -0700, Scott Wang wrote: Hi, I was running Devel::Cover to gather code coverage information for my .pm module files and I try to cover -ignore or cover -ignore_re to screen out coverage data for my test script .pt files and only display coverage data for my .pm modules. But, cover -ignore .pt command does not prevent the data for .pt files from being displayed on HTML page. Ang thoughts and suggestion on how I should run cover -ignore or cover -ignore_re to sreen out data for my .pt tests. Yeah, um, er, cover -ignore doesn't really work all that well. I mean it sort of works and sort of doesn't depending on the report. It should really be fixed. Or, maybe, they should really be fixed. But in this case, I wouldn't expect it to work as you are expecting. cover -ignore .pt says ignore any files called .pt. I suspect you don't have any. cover -ignore_re .pt says ignore any files matching /.pt/, which might be closer to what you want, and I would expect that to have some effect at least. But in general it is much better to ignore modules whilst gathering coverage. This has the added bonuses of making the whole thing quicker, using less space, and mostly working. So something like perl -MDevel::Cover=+ignore,\\.pt$ ... might be what you are really looking for. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Info from Devel::Cover
On Thu, May 11, 2006 at 11:57:44AM +1000, Kirrily Robert wrote:
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?
We discussed this question on IRC, but it was 4am for me and I was not long
back from a reasonably long day at work so, although I think the advice I gave
was sound, it may be worth expanding on it here. This message was almost
finished when my router crashed, and when I got home I forgot to finish it, so
apologies for the delay.
First, there's no need to delve into C to access the coverage data. The
required API is in Devel::Cover::DB. The documentation in there is
somewhat sparse, but covers the basics.
The easiest thing to do is probably to look at one of the existing
reports and copy it. I would suggest the textual report as being the
simplest to follow. That is found in Devel::Cover::Report::Text.
With respect to the infrastructure required, I would suggest making your
code a report and using the cover program to call it. If you make
your code Devel::Cover::Report::Filldb for example, and put it somewhere
where perl can find it, then calling cover -report filldb will call
your report.
For example, here is the report subroutine fro the text report.
sub report
{
my ($pkg, $db, $options) = @_;
print_runs($db, $options);
for my $file (@{$options-{file}})
{
print_file ($db, $file, $options);
print_branches ($db, $file, $options) if $options-{show}{branch};
print_conditions ($db, $file, $options) if $options-{show}{condition};
print_subroutines($db, $file, $options) if $options-{show}{subroutine};
}
}
From here you should be able to access any information you need.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: More - Re: question about using cover -ignore and cover -ignore_re
On Mon, May 29, 2006 at 03:31:19PM -0700, Scott Wang wrote: -MDevel::Cover=+ignore,\\.pt$ ... really helps! If I want to use Devel::Cover module in my code and not from commandline, say I would like to use use Devel::Cover; in code, what I should add after use Devel::Cover to make it works as -MDevel::Cover=+ignore,\\.pt$ I think that use Devel::Cover qw( +ignore .pt$ ); should do that. See -M in perldoc perlrun. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #39217] [TODO] legal - eliminate All Rights Reserved.
On Fri, May 26, 2006 at 01:57:40PM -0700, Allison Randal wrote: Copyright notices should have the form: Copyright years, The Perl Foundation. Whoops, typo, that's: Copyright (C) years, The Perl Foundation. Are you sure? As I understand things, the symbol (C), that is the letter C in parentheses, has no legal bearing whatsoever. In general the word Copyright is sufficient for international copyright concerns, but if you want to add something else it should be the symbol ©, that is the letter C in a circle. Of course, I'm not a lawyer, but this is what they learned me at college. Though this was at about the same time as countries such as Mauritius, Liberia and the USA were becoming party to the Berne Convention, so maybe that changed things for the USA. I don't think this is the case though. Indeed, http://www.copyright.gov/circs/circ03.html only talks about: The symbol © (the letter C in a circle), or the word “Copyright,” or the abbreviation “Copr.” I wouldn't have said anything, but your correction seems to indicate that the (C) is important. Is my information outdated? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: A shorter long dot
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Thinking about it a bit, I suppose the problem would be how to parse
something like
if $person eq %people {'john'} { ... }
which would be valid whichever way you parsed it, right?
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
I'm probably not seeing what the rest of the several useful
side-effects are, and I'm probably far too conservative, but given the
choice between the following I know which one I would choose.
if ($value eq $target) {
$monsters{cookie} = Monster-new;
$people {john } = Person -new;
$cats{fluffy} = Cat-new;
}
if $value eq $target {
%monsters.{'cookie'} = Monster.new;
%people\ .{'john' } = Person\.new;
%cats\ .{'fluffy'} = Cat\ .new;
}
if $value eq $target {
%monsters.cookie = Monster.new;
%people\ .john = Person\.new;
%cats\ .fluffy = Cat\ .new;
}
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Otherwise I'll hope that, as has happened a number of times before, someone
will decide that this is too ugly to live and will create something nicer.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: RFC: Community education page
On Thu, May 04, 2006 at 03:59:47PM +0100, [EMAIL PROTECTED] wrote:
but also people on the semi-inside, trying to remember things like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Well, I'd obviously quite like that ;-)
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Proposed kwalitee metric: consistent_newlines
On Wed, May 03, 2006 at 11:36:53AM +0200, A. Pagaltzis wrote: Am I missing something, or won’t all of these will cause problems with Module::Signature? The thing is that it doesn’t matter how perl sees the file; what matters is how Module::Signature sees the file, and to my knowledge, the latter does not attempt to parse the file in any fashion, so neither should the corresponding Kwalitee metric. I'm probably missing something too since I know litle to nothing about Module::Signature, but it seems to me that if Module::Signature has a problem with certain (valid) files then maybe it is Module::Signature that needs to be fixed rather than mandating (as much as kwalitee can) than everything else should conform to its understanding of the world. Now I know other people probably have different views on this, since I also dislike adding /* NOTREACHED */ to shut up lint, writing if ((a = b)) to shut up gcc, and even adding # uncoverable to keep Devel::Cover quiet ;-) [ No, that last one doesn't work yet. ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: A shorter long dot
On Mon, May 01, 2006 at 01:15:58PM +0100, Smylers wrote: Jonathan Lang writes: Larry Wall wrote: I don't see much downside to \. as a long dot. Folks want to be able to line stuff up, and to split statements over multiple lines. This is now possible. You know, I'm still wondering who these folks are. Seriously. Maybe you all write your code differently to me, but looking through a load of my OO code I had trouble finding three method calls in a row to any methods on any objects, let alone six calls to the same method name on different objects. If I saw code like $xyzzy.foo(); $fooz\.foo(); $foo\ .foo(); $fa\ .foo(); $and_a_long_one_I_still_want_to_align\ .foo(); $etc\ .foo(); I'd probably take that as a pretty strong clue that I should really have written $_.foo for @things_to_foo; or something. I like lining up my code as much as the next programmer, and probably a lot more, but I just don't see the need for this syntax which seems ugly, confusing and unnecessary. But then again, as I said, I really don't see the problem that is being solved. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [selenium-dev] Selenium RC driver
On Thu, Apr 06, 2006 at 11:06:00PM -0700, Dan Fabulich wrote: Good points there... Here's my two cents (and a bit). 0) Not explicitly highlighted, Selenium Core generates an XML file with a full description of its API; this is enough information to generate copious javadoc, ndoc, rdoc, pydoc, or POD perldoc. We should use it for something perl-ish, one way or another. Agreed. 1) It's worth noting that the other drivers (java, c#, python, ruby) *do* have build code. For python/ruby, there's just enough build code to run XSLT to generate code, run some tests, and generate doc, but the c# code requires running it through csc and the java code is compiled by Maven. A makefile would therefore not be out of place. 2) As clever as the AUTOLOAD code is, it can be very opaque to end users. Since the AUTOLOAD code has no explicit definition of click (for example), users can't grep through the code for its implementation, and they have to consult the Selenium website for reference documentation. While we could use the Core XML to merely generate POD documentation, at that point we're really 90% of the way towards generating all of the Perl code, which I would probably prefer. I'm not particularly concerned about this one way or another. Provided the documentation is there people can look at the source or not as they please. No doubt some poeple would prefer the minimal AUTOLOAD code and others the more explicit longhand. Since it is machine generated we are keeping DRY whichever way we go. 3) It's never been clear to me what to do with code that is partly Perl and partly something else. CPAN is full of pure Perl (or Perl + C) projects, but Selenium will always be a multi-lingual project (for the browser-side JavaScript alone, if not also the Java server). What do people normally do with that kind of project? I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. 4) I'm happy to volunteer to maintain a *thin* Perl driver that does not include its own back-end code. Such a driver should be no longer and no more complex than the Python, Ruby, Java or C# drivers, and can/should include automatically generated code/doc. If the project is bigger than that, though, someone else will need to do it. What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? As far as strategy is concerned, I think this is the right way to go. I don't see any point in rewriting the Java code if it is doing everything necessary (I discovered I needed a fairly recent (or possibly just not ancient) version of java to get it to work), and being consistent with the other languages seems to provide many benefits. I'm on freenode #selenium if anyone wants to discuss this there. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [selenium-dev] Perl Selenium RC driver
On Mon, Apr 10, 2006 at 10:26:14AM -0700, Dan Fabulich wrote: Paul Johnson wrote: Re: CPAN... I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. I'd think it'd be worth putting up on CPAN in some form, I think, if it could be done cleanly, for that reason alone. But the idea of CPAN is that you should be able to just go to CPAN and -install your module and then, after a short wait, you should be ready to begin using it. When the module has dependencies on other non-Perl non-C code, that presumably means you're going to have to install another interpreter as well. I could certainly imagine a CPAN module that would automatically install Java (Alien::Java?), but that seems Really Weird to me, perhaps especially because Java isn't Free-as-in-Speech software. I'd sooner imagine someone writing an Alien::Python CPAN module or an Alien::Ruby module! I don't think it is a big problem to say you need to have selenium installed to use this module - here's what to do. Or maybe would you like me to install it for you? What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) Well, if you need it Now (tm) then you *should* use the Ruby driver. :-) OK. How about Real Soon Now? ;) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? Not really. Writing an RC-compatible thin Perl driver is a matter of a day; I've done it, and it sounds like Luke's got one, and some other folks have also written one. I think the only thing to do now is decide what to do with all this code we've written. Is your code checked in? I had a discussion with Luke on IRC and we threw a few ideas around, but I wasn't aware that either you or anyone else had any code written, and I don't think Luke was either. It might be an idea for you, Luke and anyone else with any code to get together somehow and see how to push this forward, either in this thread or on IRC. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: How to best have statements execute only during dev/testing?
On Tue, Jan 10, 2006 at 08:11:43AM -0800, Matisse Enzer wrote:
I'd like to create a class that provides a bunch of assertion
methods, like Carp::Assert, etc. I want to have an object oriented
interface, so in some code I'm developing I would have:
use Devel::Assert;
my $tester = Devel::Assert-new( on_fail = carp ); # or on_fail
= cluck, etc.
my $data_structure = blah_blah();
$tester-save($data_structure); # Saves a clone of the data in a
unique slot
#
# do stuff with $data_structure
#
$tester-has_changed($data_structure);
The trick I want is that if my code is running in a production
environment (perhaps determined at compile-time) then I want my
Devel::Assert stuff to basically disappear. So the question is, what
is the lowest-impact way to do that?
One easy, but probably not best way is to like this:
sub has_changed {
return if is_production();
# do actual stuff
}
I'll note here that Carp::Assert handles this issue by having you
make all the test calls conditional:
ASSERT( $a == $b) if DEBUG;
This isn't an answer to your question, but in general production is the
environment in which your code will be exposed to the data and
conditions which have had the least testing, and to which you will have
the least access and freedom to change things. This is precisely the
environment in which I like to have checks to discover problems as early
as possible and to provide the most information about them.
Should you have considered this found that the checks are just too
expensive, for example, one possibility which is slightly better than
the one you proposed might be to to replace all the methods in
Devel::Assert with empty subs. This will mean that you will still have
the overhead of a method call, which is (un)reasonably expensive in
Perl, so to eliminate the call completely you are left with a solution
such as the one you noted, where the call is conditional on some
constant which can be set to false allowing the optimiser to remove the
whole thing from the op tree.
I suppose you could consider a source filter, but I couldn't recommend
that.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: handling undef better
On Mon, Dec 19, 2005 at 12:13:04PM +0100, Michele Dondi wrote:
my $x;
$x-{foo}[42][2005]{bar}='quux';
Would you like to have to explicitly and verbosely declare the shape of
the structure held in $x instead?
I would like the option to have to, or to be able to do that, and maybe
to declare which hash keys or array elements are valid.
Do we have that already?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Compiling Devel::Cover stats across scripts
On Wed, Nov 16, 2005 at 05:46:34PM -0500, David Golden wrote: Before I flounder around to figure this out, I hope that a quick message to the list can offer some guidance. I've got a bunch of test files for a distribution that run a script that comes with the distribution. I'd like to test my coverage against that script. I figure that I can just pass -MDevel::Cover to the execution of the script if that's also in the HARNESS_PERL_SWITCHES. If my test file calls the script 20 times testing 20 different execution paths, do all the runs get aggregated into cover_db? Or do I need to create separate cover_db_$$ dirs for each of the 20 runs, then use cover at the end to merge them together? I would hope things should work just as you are expecting, that is all twenty runs should be merged to give combined coverage for the script and any modules used. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: RFC: Test::JSON
On Mon, Nov 14, 2005 at 01:17:05PM -0800, chromatic wrote: On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote: Yes, I can see that. I could actually have dropped Test::Differences eq_or_diff and just used the is_deeply function from Test::More, but when working with large data structures, there's just no comparison between the two. I suppose I could make Test::Differences optional and fall back on is_deeply if they don't have T:D installed. At some point, people install modules for the convenience of not writing that code themselves. I think they'll survive if you require modules for the convenience of not having to write that code yourself, at least if you don't go crazy with it. Whilst I agree with this and I am quite happy installing testing modules I decided that with Devel::Cover I didn't want to create a dependency on Test::Differences so I took the approach of using it if it is availabile. In a reasonably complicated test module it took about 9 extra lines of code to optionally use Test::Differences. It is true that there is no comparison in the quality of the test output. The only downside is that it is another configuration on which I need to test before making a release. Oh, and Test::JSON works well for me. Thanks! -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: suspend and resume opcode
On Fri, Nov 04, 2005 at 11:02:42AM -0500, Will Coleda wrote: The mail list strips out .t attachments (Robert? is this necessary?) This was changed on perl5-porters a few weeks ago, and since then I don't recall seeming a marked increase in troff spam. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover: Can't find digest for blib/lib/A/B.pm
On Thu, Oct 27, 2005 at 06:21:53PM +0200, Gábor Szabó wrote: actually I think this happens to be with any module, eg.: [EMAIL PROTECTED]:~/Spreadsheet-ParseExcel-Simple-1.03$ cov Deleting database /home/gabor/Spreadsheet-ParseExcel-Simple-1.03/cover_db No root path(s) specified at /usr/local/lib/perl/5.8.7/Devel/Cover/DB.pm line 110 PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/01..ok 1/11Can't find digest for blib/lib/Spreadsheet/ParseExcel/Simple.pm at /usr/local/lib/perl/5.8.7/Devel/Cover/DB/Structure.pm line 253. t/01..ok where cov contains the following: cover -delete export DEVEL_COVER_OPTIONS= -coverage statement,branch,condition,path,subroutine,time This is the problem. You want a comma after -coverage instead of a space. The documentation could be more clear on this topic. The bug is due to a combination of dodgy option handling and incorrect (or at least unhelpful) behaviour with non-standard options. I may yet completely overhaul the option handling. That this is a possibility is the major reason I still call the code alpha. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: New kwalitee test, has_changes
On Fri, Sep 23, 2005 at 12:06:43PM +0200, Thomas Klausner wrote: Hi! On Fri, Sep 23, 2005 at 12:54:42PM +1000, Adam Kennedy wrote: Collecting any sort of coverage data is a complete bitch. Let me just say right now that doing it across _all_ of CPAN is flat out impossible. It's impossible. And remember folks, only perl can parse Perl. I completly agree. However, the problem is only slightly harder than testing all of CPAN. Now, if somebody sets up a system to collect coverage data thats generated at various decentralised machines and provides a nice interface to the results, CPANTS might be able to use coverage statistics as a metric. This has been on the Devel::Cover TODO list for a while now. I have some ideas but nothing implemented. If someone wants to take a look at this, I suggest basing your work on cpancover in the Devel::Cover distribution. (I think I have mentioned this before.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [Maybe Spam] Re: DBD-mysql coverage == 56% - am I on drugs ??
On Fri, May 13, 2005 at 05:18:40PM +0100, Tim Bunce wrote: On Fri, May 13, 2005 at 10:51:56AM +0200, Paul Johnson wrote: On Fri, May 13, 2005 at 03:00:39PM +1000, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Covering the XS portion of the code with gcov is possible, and Devel::Cover will create all kinds of nice webpages and statistics for you too. Paul Johnson may have this written up somewhere, but, if not, I should really write something up about this since I've used it to determine Perl's test coverage. I don't think I have written anything except the docs for gcov2perl, which are minimal and incomplete. I'd be happy to take doc patches for gcov2perl if you think that's the right place to document this. Generating coverage tests for XS code - why are my hands shaking ? It's not really that difficult. You just need to get the right options to gcc, either by compiling your perl with those options which means they will automatically be passed to your XS code, or by making sure your XS code is compiled with those options. Then, on running your tests, you will get one or more gcov files which you can run through gcov2perl to add the gcov data to your perl coverage database. Then, running one of Devel::Cover's reports will report on your XS code along with your Perl code. OK. In principle it's not really that difficult. Would be _great_ if that could all be automated as far as possible. I presume the gcov files could be automatically detected and processed, for example. I have recently released Devel::Cover 0.55 which has support for this. If you are in a standard ExtUtils::MakeMaker environment you should just be able to type $ perl Makefile.PL $ cover -test and get a report with all your coverage, including gcov information if available. In a slightly less standard environment, such as that provided by Module::Build, that might not work. In that case the (recently updated) docs for gcov2perl might give some clues on what to do, and I'd be pleased to receive patches to make cover -test more general (and robust). The slides for my presentation at YAPC in Braga also have a little information on this topic. http://www.pjcj.net/yapc/yapc-eu-2005-dc-advanced/slides/ -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: New kwalitee test, has_changes
On Wed, Sep 21, 2005 at 10:28:33PM -0400, James E Keenan wrote: David Landgren wrote: demerphq wrote: You miss my point. Whether the code be cross-platform or cross-version, you need to aggregate the coverage results from all the environments your code is designed to run on. How is this done? By specifying more than one database when you run the cover program. How you get the databases to be visible is currently your problem. cp, nfs, smbmount, scp, mail - your choice. The databases will be merged and a combined report produced. On Wed, Sep 21, 2005 at 04:26:27PM +0200, demerphq wrote: And, it doesnt help that something about DC breaks the defined operator when dealing with overloaded objects. (yeah, he did say the code was alpha quality :-) Bug reports, especially those containing small, self contained test cases, go a long way to helping such problems get solved ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover problem with Apache::Test
On Fri, Sep 16, 2005 at 11:54:00AM -0400, Geoffrey Young wrote: I'd really love to use Devel::Cover - I love the effect mastering the request/response Apache::Test framework has had on my code, and I really want to start using code coverage as part of my toolkit. yah, this is a bit more complex than it probably ought to be, but I guess that's by design. it could also be a bit better documented, but... ... IIRC paul had some info on this at his YAPC::EU advanced Devel::Cover talk (which I did not attend) so maybe he has his slides available for viewing as well. Thanks for answering, Geoff. I was hoping you would ;-) Since I only had 20 mins, I'm afraid the part about mod_perl ended up as one slide which basically said you can use Apache::Test - read the docs. For those who are interested anyway, the slides are at http://www.pjcj.net/yapc/yapc-eu-2005-dc-advanced/slides/ and the more basic stuff can be found off http://www.pjcj.net/yapc/ -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: rantTesting module madness
On Sat, Sep 10, 2005 at 05:40:54PM +0200, Tels 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. I have found that the easiest way to do this by far is to use CPAN::Mini and burn a local copy of CPAN to a CD. You might even get away with your USB stick if it is big enough - 512M might still be enough. See http://www.perladvent.org/2004/5th/ Do the same when you need to upgrade something. I managed to install svk and a bunch of other stuff in this fashion without problem. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Test::Harness Extension/Replacement with Color Hilighting
On Mon, Sep 05, 2005 at 10:58:17AM +0100, Dave Cross wrote: Shlomi Fish wrote: Hi all! Does anyone know of a Test::Harness extension or replacement that can color the final report line in green if all tests passed and in red otherwise? search.cpan.org is no help, and couldn't find anything relevant by a brief scanning of its POD page there (but not a thorough reading of it). I'd like to be able to use it without requiring the module's user to install it, just using it on my local configuration. The Test::Builder::Tester distribution includes Test::Builder::Tester::Color. That might be useful - or might serve as a good basis to build something on. See also Apache::Test. http://perl.apache.org/docs/general/testing/testing.html#Colored_Trace_Mode -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover Problem: testing || for a default value.
On Mon, Jul 11, 2005 at 01:17:48PM -0700, Michael G Schwern wrote: On Mon, Jul 11, 2005 at 07:38:57PM +0300, Yuval Kogman wrote: So what should I do to eliminate it? Maybe Just Nothing The issue is that you can't special case get_current_coords to be truish, as far as Devel::Cover is concerned - it might not be. Any fix that could be thought up is inherently problematic. Coverage reporting is not done for the pretty colors - a human reads it, and says OK, this is logical, get_current_coords always returns a true value. It's not a race for greens and percentages. While I agree coverage is not a race, I disagree that a human should have to disambiguate between real missing coverage and a false negative. At least not more than once. Quite. I'll make the same argument no broken windows argument here that I do about warnings and tests: elminate all warnings, even if they are dubious. Ensure all tests pass eliminating all false negatives. Do not leave any expected warnings or expected failures because this erodes the confidence in the test suite. Warnings and test failures fail to ring alarm bells. One expected warning leads to two. Then four. Then finally too many to remember which are expected and which are not and you ignore them all together. The Pragmatic Programmer does a good job with this argument. http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html I agree with this completely. The rest of the book is pretty good too. So goes the same with coverage. Red should be a BAD color, something you do not want to see. You want to eliminate the red. But sometimes its a false negative. In that case there should be some way to tell the tool that it is, in fact, a false negative. Just like skipping tests, you store the fact that there is a false negative to make the red go away. Red remains a bad color and seeing it means something is wrong. The team doesn't have to remember which bits are expected to be uncovered and which are not. What's missing is a way to let Devel::Cover know that a bit of coverage is not necessary. I've called this concept uncoverable code, and if you grep the current Devel::Cover source code for uncoverable you'll find a bit of code designed to solve this problem. But it's not complete, so I've neither documented it nor advertised it. Things have proceeded much further in my development code and I'm hoping to have something working properly before YAPC::EU. (No promises though.) The first way to do this which pops into my mind is a comment. my $foo = $bar || default(); # DC ignore X|0 Hey, Devel::Cover! Ignore the case where the right side of this logic is false. I wasn't particularly happy with the idea of needing to change the source code just to satisfy some tool. I feel the same way about doing things to shut up lint, for example, or to satisfy some arbitrary metric. That's why I've initially stored information in a .uncoverable file. But everyone I've spoken to about this has either not worried about or actively preferred to annotate the source. Many of those have also admitted to adding pod and even tests inline, which tells me that I really should be ignoring their opinions, but I try to please my users anyway, and so I'll see what I can do. Ignored conditions would be green, but perhaps a slightly different shade of green so they can be spotted if you're looking for them. Yes, it should be possible to easily find this uncoverable code amongst the coverage. It should also be possible to note why the code is uncoverable. I've also found it useful to have different classes of uncoverable code. Why is it that my TODO list only gets longer? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover Problem: testing || for a default value.
On Mon, Jul 11, 2005 at 02:54:19PM -0700, Michael G Schwern wrote: On Mon, Jul 11, 2005 at 11:22:51PM +0200, Paul Johnson wrote: my $foo = $bar || default(); # DC ignore X|0 Hey, Devel::Cover! Ignore the case where the right side of this logic is false. I wasn't particularly happy with the idea of needing to change the source code just to satisfy some tool. I feel the same way about doing things to shut up lint, for example, or to satisfy some arbitrary metric. That's why I've initially stored information in a .uncoverable file. Guh! .uncoverable would presumably be line number based. That means every time you edit your source file you have to change all the lines in .uncoverable. *shudder* Now, would I do that?! It's actually based on the MD5 hash of the line which means you only need to change it when you have changed the line, which you would presumably (there's that word again) be doing anyway. It seemed to work quite well for me in the last project I did, where I tried to do test first development, keeping the coverage at 100%. But never fear, I'm comitted to supporting comments too. Who knows, I might even end up using them myself. The only other scheme I can think of, pattern matching based on source code, is unreliable. Right. Finally, as with tests and docs, the closer you put the meta-data to the real data the more likely it will be kept up to date. So inline Devel::Cover hints seem the way to go. Hmmm ;-) Why is it that my TODO list only gets longer? It means your code is popular and people want to use it and everybody loves you!!! Don't call them TODO items, call them hug lines. ;) $ svk mv TODO HUGS Do I now get to port the thing to Haskell? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: 5.004_xx in the wild?
On Wed, Jul 06, 2005 at 01:36:10AM +0200, Abigail wrote: On Mon, Jul 04, 2005 at 05:21:01PM +0200, Paul Johnson wrote: Unfortunately, upgrading isn't always an option. Anyone can type $ ./Configure -des make make test install but putting the results of such a command into a base operating system installation, testing that said operating system functions correctly with hundreds of (often badly written) scripts installing databases and middleware and who-knows-what, and ensuring that thousands of apps running on tens of thousands of machines in dozens of different configurations function at least as well as they did before is a little harder. Well, if anyone can type the above, they can also type: $ ./Configure -des --prefix=/opt/perl58 make make test install and use the appropriate #! line. Yes. I wrote later that I knew how to manage the problem. My point was that it is not always possible to do so for a variety of reasons. In very broad terms, module authors can either take the hard line and say I will force you to upgrade or you won't use my module or they can say I feel your pain and I will share it. How far each author goes down the backwards compatibility route is obviously up to them, and as a volunteer effort no one has any right to get upset about their decision. But I known which set are endearing themselves to me right now ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: 5.004_xx in the wild?
On Mon, Jul 04, 2005 at 03:00:14AM -0700, Michael G Schwern wrote: On Mon, Jul 04, 2005 at 10:36:39AM +0100, Ben Evans wrote: I would say that this cascade effect is precisely why you *should* drop 5.004 compatability. There's no excuse other than if it ain't broke, don't fix it for running such an archaic Perl. People should be encouraged to move to a more modern environment whenever possible. While I'd love it if it worked this way, more often the admins refuse to upgrade in spite of losing module support and its the programmer who gets punished. The concern is more about not breaking existing code (whether warrented or not) than furthering development. I just had exactly this happen to a friend of mine contracting at a company still running 5.5.3. He couldn't even convince them to install a modern Perl in a separate location and leave the old code running 5.5.3. As someone whose production code is currently required to run under 5.5.3, I'm very grateful to module authors whose code still runs under that version at least. A number of modules which don't run under 5.5.3 do with simple changes, primarily changing our to use vars and getting rid of x.y.z version numbers. Unfortunately, upgrading isn't always an option. Anyone can type $ ./Configure -des make make test install but putting the results of such a command into a base operating system installation, testing that said operating system functions correctly with hundreds of (often badly written) scripts installing databases and middleware and who-knows-what, and ensuring that thousands of apps running on tens of thousands of machines in dozens of different configurations function at least as well as they did before is a little harder. And whilst I know how to manage all this, sometimes it's hard enough just stopping people from mandating the use of ksh, Java and XML. Having said all that, feel free to do what you want with 5.004 support. I don't care! I have 5.005! -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Optimisations (was Re: How much do we close over?)
On Mon, Jun 13, 2005 at 11:24:07AM +, Luke Palmer wrote:
I just have to say that it's really annoying running into
optimizations when I don't want them.
Isn't the whole point of optimisations that you shouldn't have to worry
about whether you hit one or not, otherwise the optimisation would seem
to be broken.
Back when I wrote an
back-chaining system in perl, I used tied variables in order to
determine when I needed to solve for something. A standard idiom was:
rule \$var, sub {
$a and $b and $c;
$var = 1;
};
And damnit, $c would never be solved for, because it was optimized
away by Perl.
I'm not sure that short circuiting operators can be called an
optimisation. Aren't they more part of the language definition? I
assume Perl 6 isn't doing away with short circuiting operators.
I ran into that problem rather quickly, and I knew a
no optimizations would do the trick, if it existed. But no such
luck, so I always had to add an and 1 on the end. Funny thing is,
that should have been optimized away too, but it wasn't, because Perl
wasn't that good at optimizations. So now I have to know about the
capabilities of the language I'm using in order to program.
I'm not sure about the premise, but I agree with the conclusion.
To sum up, optimizations are nice, and it's nice to have optimizations
on by default for PR reasons, but you have to be able to turn them
off.
One of the things that has been on the Perl 5 wishlist for a while is a
way to turn off the optimisations, but really that would only be for the
benefit of people and modules that mess with the op tree. Again, I
submit that an optimisation that changes normal behaviour is broken and
that, in general, programmers shouldn't need to worry about what
optimisations are going on under the covers.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Devel::cover bug?
On Wed, Jun 01, 2005 at 03:00:03PM -0700, Kevin Scaldeferri wrote: On Jun 1, 2005, at 2:35 PM, James E Keenan wrote: Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: stmt branch cond sub time code 221862 100 100 _1613639 next if ($line =~ /^\s*[#!]/ || $line =~ /^\s*$/); If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. ... nor have I seen an uncovered BEGIN block. But that may just be a side effect of the sort of things I've been doing coverage analysis on. Well, there is no BEGIN block there at all, so that suggests something funny is going on. Certainly. Of course, it's always possible and quite likely that there is a bug in my code somewhere. But there is also a chance that I am conflating two ops, since I have yet to come up with a way to uniquely identify an op (suggestions welcome). You're not running on 5.6.x are you? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::cover bug?
On Fri, Jun 03, 2005 at 06:56:50PM -0400, Christopher H. Laco wrote: As I recall [I may be wrong], some of your snippets were under /5.8.0/... isn't 5.8.2 considered squirrelly (technical term) under Devel::Cover? Yes, you're right, I do recommend a minimum version of 5.8.2. It would be interesting to see whether the problem remains in something more recent. I wonder too whether 64bits has anything to do with it. Perl 5.8.0 and 5.8.1 will give slightly different results to more recent versions due to changes in the op tree. Actually, the changes are between 5.8.0 and 5.8.1, but I notice the docs are wrong there. They wont be in the next release. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::cover bug?
On Tue, May 31, 2005 at 04:00:12PM -0700, Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: You might find it slightly easier with the textual report (cover -report text), or does the problem only show up under the html report? If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. That does sound a little strange. Are you able to produce an example showing this problem? Any insights? Not at the moment, I'm afraid. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Displaying the description in diagnostic output
On Thu, May 12, 2005 at 08:50:09PM -0500, Andy Lester wrote: Also, amidst all this, I'm looking at a way to do verbose but only on tests that are errors mode for Test::Harness and prove. I'm not sure quite how well it fits with this, but I'd be really pleased if you were able to add a stop after the very first test that fails because that's the one I'm going to fix now option while you're looking at this. Or even at some other time. Or somebody else. I'm not that fussy really. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: DBD-mysql coverage == 56% - am I on drugs ??
On Thu, May 12, 2005 at 07:31:49PM -0700, Michael G Schwern wrote: The total produced by Devel::Cover can be deceiving. Its a simple average and not taking into account things like the fact that Mysql::Statement is 171 lines while DBD::mysql is 1753. So For statement coverage the value for the total is calculated as the sum of the covered statements in all the modules over the sum of all the statements in all the modules. Totals for other criteria are calculated similarly. I think that should make the totals for each criterion fairly meaningful. Hovering over the percentages in a graphical browser should give the figures used to calculate that percentage. Mysql::Statement's poor coverage is having a much greater effect on the apparent coverage than it really should. I'm also not sure what voodoo Devel::Cover uses to create a total coverage out of four different types of coverage stats. That total is calulated as the sum of all the covered constructs over the sum of all constructs. That figure has more dubious value as it assumes that all coverage criteria are equal when we all know that some criteria are more equal than others. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [Maybe Spam] Re: DBD-mysql coverage == 56% - am I on drugs ??
On Fri, May 13, 2005 at 03:00:39PM +1000, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Covering the XS portion of the code with gcov is possible, and Devel::Cover will create all kinds of nice webpages and statistics for you too. Paul Johnson may have this written up somewhere, but, if not, I should really write something up about this since I've used it to determine Perl's test coverage. I don't think I have written anything except the docs for gcov2perl, which are minimal and incomplete. I'd be happy to take doc patches for gcov2perl if you think that's the right place to document this. Generating coverage tests for XS code - why are my hands shaking ? It's not really that difficult. You just need to get the right options to gcc, either by compiling your perl with those options which means they will automatically be passed to your XS code, or by making sure your XS code is compiled with those options. Then, on running your tests, you will get one or more gcov files which you can run through gcov2perl to add the gcov data to your perl coverage database. Then, running one of Devel::Cover's reports will report on your XS code along with your Perl code. OK. In principle it's not really that difficult. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
verbose diagnostics
Using Test::More, I would like to send some diagnostics to be seen only
when the harness is running in verbose mode.
There doesn't seem to be a way of doing this. The best I could come up
with is:
sub vdiag { pass(@_) }
but this has little to recommend it.
Thoughts?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: verbose diagnostics
On Thu, Apr 28, 2005 at 02:44:30PM +0100, Adrian Howard wrote:
On 28 Apr 2005, at 14:23, Paul Johnson wrote:
Using Test::More, I would like to send some diagnostics to be seen only
when the harness is running in verbose mode.
[snip]
diag some verbose diagnostics if $ENV{TEST_VERBOSE};
I didn't think that would work with prove, but it looks like Andy fixed
that before it was a problem.
Based on a suggestion from Geoff Young, I came up with:
sub vdiag
{
my $original_fh = Test::Builder-failure_output;
Test::Builder-failure_output(\*Test::Builder::TESTOUT);
diag(@_);
Test::Builder-failure_output($original_fh);
}
but your suggestion is simpler.
Thanks!
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Sun Fortress and Perl 6
On Wed, Apr 27, 2005 at 01:53:11AM -0600, Luke Palmer wrote: Juerd writes: Autrijus Tang skribis 2005-04-27 17:04 (+0800): I can certainly see a `is pure` trait on Perl 6 function that declares them to be safe from side effects. In a sense, `is const` also does that. `is pure` would be great to have! For possible auto-memoization of likely-to-be-slow subs it can be useful, but it also makes great documentation. It's going in there whether Larry likes it or not[1]. There are so incredibly many optimizations that you can do on pure functions, it's not even funny. Haha. Er... For those too young to have had net access at the time, I'll note that we have had a discussion along these lines before. At that time most people disliked the word pure, but since then it would seem that for some strange reason more people have been exposed to functional programming. http://www.mail-archive.com/perl6-language@perl.org/msg11967.html -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote: It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. When I see code such as this, I usually encourage people to program Perl as if it had sequence points and undefined behaviour. This often results in explaining what they are, but maybe that's not such a great problem. See http://www.eskimo.com/~scs/C-faq/faq.html, especially sections 3.8 and 11.33 for details. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Tests running Tests
On Tue, Apr 12, 2005 at 01:20:18PM -0400, Sam Tregar wrote: Hello all. I've got a test I want to write, but I don't know to write it (easily). I've got a test script, call it foo.t which uses Test::More and runs under Test::Harness. Now I want to make a new test script tweek-then-foo.t which tweeks the system and then ensures that foo.t still passes. How do I write tweek-then-foo.t? I would do it in the same way as if this had nothing to do with tests. That is, abstract away the common code into a module, which can also live under t/ -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Testing Net-SSLeay
On Fri, Apr 01, 2005 at 01:47:36PM -0600, Walter Goulet wrote: Finally, I wanted to confirm an assumption: I can split test.pl into a set of seperate t/*.t test scripts regardless of whether I'm using Test or Test::More. Yes. Or neither or both. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
pugs code coverage requirements
I've been following the progress of pugs in awe of the speed of the
progress, the breadth of the scope and the exemplary way in which
Autrijus has run the project. And I've been considering how best I
could contribute.
One of the many aspects of the project that is to be admired is the test
driven development. Knowing a little about code coverage I wondered
whether there were any Haskell code coverage tools that we could use to
aid in that process. The best option seemed to be something based on
hat (http://www.haskell.org/hat/) but unfortunately pugs uses some
libraries which hat does not support. The last release of hat came two
years ago, so I'm not expecting those libraries to be supported in the
near future. If anyone knows of a way to do code coverage in Haskell,
and specifically of pugs, please pipe up.
So next I thought about code coverage of Perl6 itself. Now that people
are starting to write Perl6 modules code coverage could be useful. It
seemed to me that walking the AST and hooking into the reduce function
could provide the required data. Autrijus confirmed this, but thought
there might be a better way to do it and asked me to send requirements
in time for the refactoring of Eval.hs next week. So here they are.
At the most basic level two sets of data are required: the constructs in
the program, and which of them were exercised. So for subroutine
coverage, for example, that would mean a list of all the subroutines in
the program and which of them were called. But a little more
information can be useful. For example, the exact location of the
construct in the source code, the number of times it was exercised, how
long it took to be exercised, and so on.
In Perl5, Devel::Cover gets information about the constructs in the
program from two sources: the optree and the source code. Information
from the optree is obtained by calling B::Deparse and overriding some of
its functions. Information about which constructs were exercised is
obtained by installing a custom runops function and squirrelling away
data as ops are run.
So, requirements:
1. Access to all the coverable constructs in the program: subroutines,
statements, branches, conditions, loops, rules, pod ...
2. Information about those constructs. Where to find them in the
source, textual representation, information about the parts of the
constructs.
3. Which constructs were exercised. How many times, the order, when
and how long it took.
Not all this information is required all the time. For example, timing
and count information may not be wanted for efficiency reasons.
Depending on how this information is available other requirements may
surface. For example, in Perl5 it is necessary to know that coverage is
to be collected before any code in the program is executed, and it is
necessary to process the data after the last code in the program has
been executed.
Aspects of Perl5 that make collecting coverage difficult:
- doesn't allow constructs to be exactly regenerated from optree data
- doesn't store enough information, eg can't determine location of
elsif condition
$ perl -we 'if ($a) {}
elsif ($a + 1) {}'
Use of uninitialized value in addition (+) at -e line 1.
- filenames stored as relative paths so they can be difficult to find
later
- not always easy to determine the source file of a construct
- deletes parts of the optree, eg code in modules which is not within a
sub
- doesn't provide a way to uniquely identify constructs
- difficult to determine the value of an arbitrary boolean expression
I can probably go into nauseating detail on any of these points if
required.
If you've got this far, thanks for listening!
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Fwd: [ANN: WWW::Agent 0.03 has entered CPAN: rho@bigpond.net.au]
On Mon, Mar 21, 2005 at 11:11:58AM -0800, Ofer Nave wrote: Interesting idea, but shouldn't POE-based modules stay in the POE namespace? This is probably not the right place for a prolonged naming discussion, but why should they? In an ideal world I won't care about the technology behind the module - I'll just install it and run it. This argument can also be applied to (most of) the modules in the Tie namespace, though I know that not everyone is of the same opinion in this regard. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: error using gcov2perl
On Wed, Mar 09, 2005 at 05:16:31PM +0530, Manish Sapariya wrote:
Hi,
I am getting following error when I try to convert my gcov output files
to Devel::Cover output format.
[EMAIL PROTECTED] src]$ cover
Reading database from /home/manishs/tcpflow-0.21/src/cover_db
Argument \x{2f}\x{30}... isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
Argument \x{2f}\x{30}... isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
A
That's very strange. I have line 393 in that file as a comment. Line
390 might produce that error however.
[EMAIL PROTECTED] src]$ gcov -v
gcov (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] src]$ cover -v
/usr/bin/cover version 0.52
Is there anything obvious that I am missing here.
Any help will be appreciated. I am a perl beginer and could not figure
out whats going wrong in DB.pm.
Your perl and gcov are both a little old but I wouldn't expect problems
there. You're not somehow running cover with a different release of
Devel::Cover to that which ran gcov2perl?
Other than that, I'm not sure what to suggest. If you can send me
enough to reproduce the problem I'd be glad to look into it.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 11:24:42AM -0700, Jim Cromie wrote:
Michael G Schwern wrote:
That's ok. The overall coverage report can show the union of all
reports for that version of the module.
That'd be cool, but how does this merge/combining magically happen ?
To do it properly it would need to be on a machine somewhere which would
accept uploaded coverage databases from anyone who wanted to submit one.
I discussed cover.perl.org or something with Andy and Robrt on irc a
while back, but I've not made progress on the sw side.
More specifically, Ive found it to *not* be happening when I spawn off
an `$^X -MDevel::Cover -e $testcode` job, as you've noted in another thread.
OTOH, it does seem to merge repeated runs of 'make testcover', as I see the
ran-this-line counts in the coverage report go up after each run.
Provided you can get each run using the same database things should
just work. If your pwd moves around you might need to specify a full
path to the db.
export PERL5OPT=-MDevel::Cover=-db,/path/to/cover_db
or something similar might help.
so, wrt merging coverage results, I looked inside cover_db/cover.12,
a storable file w multiple runs, one for each t/*.t file, each with a
unique key:
$ mst -d cover_db/cover.12 |egrep -e 'run|111'
'runs' = {
'1110216257.25137.60188' = {
'run' = 't/pp-dump.t',
'1110216248.25129.46205' = {
'run' = 't/labels.t',
'1110216234.25117.50538' = {
'run' = 't/basic.t',
'1110216267.25145.50509' = {
'run' = 't/warns.t',
'1110216241.25123.18273' = {
'run' = 't/honorLocals.t',
'1110216253.25133.53184' = {
'run' = 't/new.t',
'1110216255.25135.61883' = {
'run' = 't/pod.t',
'1110216260.25139.29174' = {
'run' = 't/speed.t',
'1110216229.25107.07159' = {
'run' = 't/alias.t',
'1110216250.25131.38534' = {
'run' = 't/multiarg.t',
'1110216243.25125.33249' = {
'run' = 't/indent-terse.t',
'1110216239.25121.64393' = {
'run' = 't/emulate.t',
'1110216226.25105.54436' = {
'run' = 't/01_use.t',
'1110216262.25141.01103' = {
'run' = 't/twoObjects.t',
'1110216265.25143.07361' = {
'run' = 't/useoptions.t',
'1110216231.25109.28610' = {
'run' = 't/autoprint.t',
'1110216246.25127.34447' = {
'run' = 't/initobj.t',
'1110216236.25119.49831' = {
4111,
'run' = 't/chains.t',
the file doubles in size when I rerun `make testcover`.
It would be easy enough to lump them together,
though by itself, this wouldnt help identify platforms
where a module is undertested.
The runs should be lumped together automatically when you run cover.
There are also options to cover to merge separate coverage databases.
anyway, we need site-space and cpu-time somewhere to merge
the data.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 10:33:11PM +, Nicholas Clark wrote: On Mon, Mar 07, 2005 at 07:59:40PM +0100, Paul Johnson wrote: To do it properly it would need to be on a machine somewhere which would accept uploaded coverage databases from anyone who wanted to submit one. I discussed cover.perl.org or something with Andy and Robrt on irc a while back, but I've not made progress on the sw side. Because your free time is already filled up with working on Devel::Cover itself? Yes. Free time has been pretty scarce recently and hacking time has to compete with a plethora of other stuff. This sounds like the sort of project that anyone who felt particularly keen about could try experimenting with at home, to see if they can get it to work. Having a demonstrable experiment is a very good first step to convincing others to help you with it, and having something that is mostly finished is a good way to get someone else to host a fully working version. Actions speak louder than words. Absolutely. Anyone who would like to is quite welcome to work on this. I don't even think it's too much work. The Devel::Cover side of things is all in place and available in the distribution. What is missing is some way of transfering the coverage datbase from one machine to another. Merging the databases and producing the consolidated web page should already work. I had wanted to store more information about the environments in which the coverage was obtained, and to display that in the report, but that it not essential for a first cut. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Test::Output 0.05
On Fri, Mar 04, 2005 at 04:44:42PM -0800, Ofer Nave wrote: Michael G Schwern wrote: On Fri, Mar 04, 2005 at 04:27:07PM -0800, Ofer Nave wrote: Random thought: Could Devel::Cover be automatically run against all modules in CPAN, with ratings posted on cpan.org right next to the usual test results? It still chokes on certain not uncommon constructs like threads. On that note, is forking also problematic? Forking should be fine, for certain definitions of fine. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Anomalous Difference in Output between HTML Files Created by
On Sun, Jan 30, 2005 at 08:09:58PM -0500, Jim Keenan wrote: Leif Eriksen wrote: I'd guess it is because you are seeing the output of the code after it has been compiled-then-decompiled - it is compiled so it can run and coverage statistics can be collected, then it is decompiled to relate coverage stats to code lines. Now there are many ways to write code that compiles to the same compiled form, but the decompiler (I imagine it is B::Deparse) only decompiles those symbols one way. Apparently so. I got similar results incorporating my other sample of the problem ( '!' printing out as 'not' in the branch.html file) into your 2 little scripts. Thank you very much. Yes, this is correct. The output in the main display comes from reading the text of the covered program and displaying the relevant line in its entirety. The output for the branch coverage display comes from the output of B::Deparse. The reason for this is that I wanted to display only the relevant part of the source to make the actual branch clearer. The same is true for the condition coverage report. Unfortunately, this also has the effect you have noticed. B::Deparse has options to control how the output is displayed, but I wasn't able to find anything that improved on the current output in the general case. I suppose that's the price you pay for TIMTOWTDI. [ Is that a Python programmer I hear giggling in the background? ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover failure?
On Thu, Jan 06, 2005 at 09:21:44PM -0500, Randy W. Sims wrote:
Randy W. Sims wrote:
The test file below is pared down from Module::Build. The warning from
Crequire comes up in several tests, not always causing test failures.
The same warning appears if you run MakeMaker as shown in the
Devel::Cover docs--it's not specific to Module::Build.
[EMAIL PROTECTED]:~/projects$ module-starter --eumm --mb --module Foo
Created starter directories and files
[EMAIL PROTECTED]:~/projects$ cd Foo
[EMAIL PROTECTED]:~/projects/Foo$ rm MANIFEST t/*
[EMAIL PROTECTED]:~/projects/Foo$ cat t/basic.t
use Test::More tests = 1;
use File::Spec;
require File::Spec-catfile('t', 'common.pl');
As a workaround, I've checked in changes from the last line above to:
my $common_pl = File::Spec-catfile('t', 'common.pl');
require $common_pl;
which seems to work fine.
And I have checked in the following fix which will be in the next
release:
=== Cover.xs
==
--- Cover.xs (revision 62)
+++ Cover.xs (revision 63)
@@ -846,7 +846,7 @@
case OP_REQUIRE:
{
dSP;
-sv_setsv(MY_CXT.module, TOPs);
+SvSetSV_nosteal(MY_CXT.module, TOPs);
NDEB(D(L, require %s\n, SvPV_nolen(MY_CXT.module)));
break;
}
Thanks for the report and sorry for the delay fixing it, and that you
needed to provide a workaround.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: SegFault under Devel::Cover for sort
On Tue, Jan 25, 2005 at 02:00:35PM +1100, [EMAIL PROTECTED] wrote:
I have isolated a case where perl is happy but D::C segfaults
The following patch should fix the problem:
=== Cover.xs
==
--- Cover.xs (revision 60)
+++ Cover.xs (revision 61)
@@ -783,8 +783,11 @@
* store more than one return op because a non collecting
* sub may call back to a collecting sub.
*/
-hv_fetch(Return_ops, get_key(PL_op-op_next), CH_SZ, 1);
-NDEB(D(L, adding return op %p\n, PL_op-op_next));
+if (PL_op-op_next)
+{
+hv_fetch(Return_ops, get_key(PL_op-op_next), CH_SZ, 1);
+NDEB(D(L, adding return op %p\n, PL_op-op_next));
+}
}
if (!collecting_here)
I've checked that in to my development copy along with a test case based
on your failing example (I removed the rand part). If things are OK for
you I'll release a new version with this fix soon.
Thanks for the minimal test case. Bug fixes are so much easier with a
concise way to reproduce the problem.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: [CVS ci] class refactoring 1 - Integer
On Fri, Dec 10, 2004 at 01:28:10PM -0500, Sam Ruby wrote: Mike Guy wrote: Perl5 Cxor always returns a standard boolean value, i.e. dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same thing. Try: perl -le print 'day' xor 'night' On the version of Perl I have installed, I get day as the result. Gordon mentioned the precedence problem here. I've not replied to his message because I couldn't be bothered to fix up the quoting and attributions. s/le/wle/ gives the hint too. Mike is quite right of course. And the code which handles this is one of the more simple parts of perl5. Provided you're not too worried about what's going on under the macros, I suppose. if (SvTRUE(left) != SvTRUE(right)) RETSETYES; else RETSETNO; -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover error from Storable
On Thu, Dec 09, 2004 at 11:07:21AM -0800, Kevin Scaldeferri wrote: Running some of the tests outside of the harness though, I see a couple more messages which were hidden before: Devel::Cover: Can't find file ../../lib/Storable.pm: ignored. I'm pretty confused about where that's coming from. I can find messages of the sort Can't open file ... in the source, but not Can't find file. That comes from Devel::Cover::use_file(). It's an annoying message and I haven't got around to tracking down exactly what's happening there, but I've always thought it to be benign. It's basically saying that something used Storable and perl located it at ../../lib/Storable.pm. Since then $CWD has changed and now it can't be found any more so you aren't going to get a coverage report about it. Which is normally fine, since you don't want one anyway, and even if you did you couldn't because Devel::Cover uses Storable internally. Whether this is related to your main problem I can't tell, though I have have seen that warning plenty of times before but never encountered your main problem. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover error from Storable
On Thu, Dec 09, 2004 at 02:06:39PM -0800, Kevin Scaldeferri wrote: My latest theory was that my forked processes were stomping on each other and corrupting the stored data structure. So I replaced the calls to nstore and retrieve with lock_nstore and lock_retrieve in DB.pm and Structure.pm. This doesn't seem to have helped. The run files are named time . .$$. . sprintf %05d, rand 2 ** 16 which should protect against forked processes. It may be that the structure files are not so well protected. I ran Storable::retrieve on all the files in my cover_db after the latest failure. I found that all the files in cover_db/runs were corrupted, while only one out of a couple hundred files in cover_db/structure was bad. I don't know if that's a useful bit of info or not. Are you absolutely certain that there's not another version of Storable around which could be being picked up? Maybe you could try printing out the version of Storable being used before nstore is called? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Pipe dream - Devel::Cover::Regex
On Tue, Dec 07, 2004 at 11:33:54AM -0800, Kevin Scaldeferri wrote: I'm wondering if I'm the only one who would love to see Devel::Cover::Regex? Many (most?) perl programs are pretty regex heavy, and if we are honest with ourselves, we have to admit that each regex is actually a program in itself. You can try to throw lots of inputs at it and hope that you were thorough enough, but most of us aren't that good at figuring out all the crazy ways a regex could execute. I think this would be a very useful extension to Devel::Cover, although I imagine that it's pretty tricky to do. Even figuring out how to display the results might be tough to do well. This is something I mentioned early in the development of Devel::Cover. I think the display should map fairly well into the statements, branches and conditions we have at the moment. Atoms map to statements. Quantifiers map to branches. Alternation maps to conditions. It won't be quite that simple of course, but I think that should be the basics. Occasionally I have fantasies of having enough free time to really dig into the internals of the regex engine and trying to do this, but to be honest I don't really see it happening for me. So, I figure the next best thing is to throw this idea out here and see if anyone else runs with it. Micheal suggested mjd's Rx might be useful. Jeff Pinyan's Regexp::Parser might also help as a base. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Test Failure Hooks
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid wrote: Is there is anything in the Test::* hierarchy that allows callbacks to be triggered on test failures? It would be nice to pass a sub that automatically dies on warnings, prints stack traces, cleans up temp files (or preserves them) or any of a number of things that I'd like to be able to handle. Someone's surely done this before, I just can't seem to find anything that's already implemented. Test.pm has onfail(), though it doesn't get called immediately for every test failure. I mentioned this fairly early into the design of Test::Simple/More, but I don't think anyone was particularly interested in it at the time, and I've never had the need to it myself. Stas was also mentioning something similar to this on IRC fairly recently IIRC. Seems to me it would be useful to be able to register a sub to be called and pass the current state in (ie has the test passed and any other useful information that might be hanging around such as the test filename, line, number, name^Wcomment^Wlabel) and to be able to modify the state, either directly, or by returning a status or dying or something. Or do it via OO. Or whatever. Doing something similar before the test is run seems useful too. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Python is not Java...but will Perl 6 be?
On Fri, Dec 03, 2004 at 02:05:16PM -0500, John Siracusa wrote: From http://dirtsimple.org/2004/12/python-is-not-java.html In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. I'd like to be able to s/Python/Perl 6/ above, but after many discussions on this topic, I'm still not sure if I can. http://www.nntp.perl.org/group/perl.perl6.language/9576 -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Harness runs the sub, D::C says I haven't
On Wed, Nov 17, 2004 at 08:33:54AM +1100, Leif Eriksen wrote: Next I tried to see why D::C 0.50 didn't work. To do this I started with a clean slate, ala 'echo y | cvs release -d monash.its cvs co monash.its' (blow away the source dir structure and recreate from CVS). I then did the 'perl Ma... make test' incantation, all OK. Then I did 'HARNESS_PERL_SWITCHES=-MDevel::Cover make test' and viola it worked File stmt branch condsub time total --- -- -- -- -- -- -- blib/lib/Monash/LDAP.pm 98.7 98.4 80.0 96.3 67.2 97.3 Good news! And good coverage too! (Dont worry about the 96.3% subroutine coverage - there is one sub not unit tested on explicit direction from the infrastructure team - so I have the required 100%) I'm slowly improving the uncoverable stuff so that in cases like this you can still get 100%. Not primarily to appease management types, but because it helps the errors to stand out when you can say this is not covered and this is the reason why. Morale - clean up and try from scratch before hitting the 'emergency email support' button. Thanx so much for your patience Paul - if your ever in Melbourne, I owe you a few shouts at the bar - I recommend a James Boags. It's a long way to come for a drink, but I appreciate the offer :-) Leif Eriksen aka Mr Testing SmartyPants (you can tell I'm please with myself cant you) I hope the effort proves worthwhile. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Harness runs the sub, D::C says I haven't
On Sat, Nov 13, 2004 at 12:33:01PM +1100, Leif Eriksen wrote: First, thanx so very much for responding so quickly... That was just to make up for the short delay here, and the much longer delay to your last mail to me ;-) Paul Johnson wrote: On Sat, Nov 13, 2004 at 12:46:16AM +1100, Leif Eriksen wrote: Even though Test::More is reporting (via make test) that every test Could you try putting the use_ok inside a BEGIN block, as Test::More recommends? OK, will do, though I upgraded to Devel::Config 0.50 first and now I hang... More details - This is perl, v5.8.3 built for i386-linux-thread-multi Linux mother 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 athlon i386 GNU/Linux Fedora Core release 2 (Tettnang) Hang is prompt HARNESS_PERL_SWITCHES=-MDevel::Cover make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') Monash/t/*.t Monash/t/Config..ok Monash/t/Config_fail.ok Monash/t/Config_fail2ok Monash/t/DB..ok 2/0make: *** [test_dynamic] Interrupt (I hit ^C) I'll revert to 0.49...hang on...nope - still stuck...revert to 0.45 - OK good, not sure what the issue is there Lets check the coverage. Nope, still says I haven't been there trtd class=ha id=L793793/a/tdtd class=c0div class=sldap_groups/div/td/tr So, if I've got this right, 0.45 shows the code as uncovered and 0.50 hangs during the tests. I suspect that what is happening is that your code is being called via some code for which coverage is not being collected, such as a core or already installed module. Up until recently this would lead to the code being marked as uncovered, as you are seeing. I suspect that if we could get 0.50 working on your tests then you would find the code being marked as covered. Can you give me a pointer where to go from here - is it my code at fault ? I don't think so. I already have a report of something like this, along with a test case. Unfortunately, I haven't had the chance to chase it down yet. If you are able to reduce the problem to a minimal test case I'd be very grateful. But with the test case I already have I'm hoping to make a fix soon anyway. In the meantime, if you go to the last version that works for you, you should be able to get a complete coverage report with a line such as HARNESS_PERL_SWITCHES=-MDevel::Cover=-select,. make test The downside is that that will also give you coverage for every module you use, which is distracting and slow. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover on Win32: Observations
On Sun, Nov 14, 2004 at 12:42:14PM -0800, Jim Keenan wrote: Installing and using Devel::Cover on Win32 for the first time today, I noticed several things and would like to know if my experience is anomalous. 1. Since I don't have a C-compiler, I first went to ActiveState's PPM Repository, but Devel::Cover's latest version (0.50) is listed as a FAIL on Windows. I understand that the reason for this is that ActiveState build the modules in a sort of sandbox where perl is installed in a location other than where it will be when the module is tested. During the installation process, Devel::Cover makes a note of where the core modules are (@INC) so that they are by default not selected for coverage analysis. But during the test process the standard perl, or at least a different one is used, and thus coverage data is collected for the core modules that are used. This causes the tests (correctly) to fail. kobesearch.cpan.org directed me to http://crazyinsomniac.perlmonk.org/perl/ppm/5.8/, from which I was able to download and install a tarball of Devel::Cover v0.47. Following crazy's instructions, I was able to install it successfully. You can also try 0.50 at http://cpan.alternation.net/ppm/Devel-Cover.ppd Contact [EMAIL PROTECTED] if you have any problems with that release. 2. The Devel::Cover docs describe this as the way to run coverage on an uninstalled module: HARNESS_PERL_SWITCHES=-MDevel::Cover make test cover I found that, on Windows, I had to switch the syntax around to get it to work with nmake nmake test HARNESS_PERL_SWITCHES=-MDevel::Cover cover Is that other people's experience? I've written the syntax for for a Bourne shell or similar, so I'm not surprised it's different for Windows. It'll be different for Cshell too. Basically, do whatever you need to to set an environment variable. 3. The module whose coverage I was examining was ExtUtils::ModuleMaker. I had used Devel::Cover on this module on Darwin, so I knew what to expect for results. But when I ran 'cover' on Windows, it ran coverage (and created coverage report .html files) not just on the '.pm' files contained within EU::MM, but also on *31* .pm files contained under my 'Perl/lib' directory. [ snip list of modules ] My hunch is that these are modules and pragmas called by Devel::Cover. Correct? Or by EU::MM, or by the tests. But why do I get these in the printout from Devel::Cover on Windows but not on Darwin? Normally they would not be covered by default, being core modules. Is it possible that your perl is in a different location from that with which the ppm was created? When Devel::Cover runs it will tell you which directories are being ignored by default. See the documentation to alter this if it is wrong for you. (Or manually hack Devel::Cover::Inc, but that's not a supported solution.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Harness runs the sub, D::C says I haven't
On Sat, Nov 13, 2004 at 12:46:16AM +1100, Leif Eriksen wrote:
Even though Test::More is reporting (via make test) that every test
ran and I had a 100% pass, some subs (such as ldap_groups that I expand
upon here) are marked by D::C as never being run - even though there is
a whole t-file dedicated to just that sub that did indeed run.
The module has a sub 'ldap_groups()', that is in the @EXPORT_OK for
the module.
The t file is basically
code
#!/usr/bin/perl -w
# tests specific to the ldap_groups function
use strict;
use Test::More qw(no_plan);
use Test::MockObject;
use_ok( 'Monash::LDAP', qw( ldap_groups ) );
Could you try putting the use_ok inside a BEGIN block, as Test::More
recommends?
Now, in order to get around the fact that use_ok('Monash::LDAP', ...)
seems to stop D::C instrumenting Monash::LDAP, I call the test harness as
HARNESS_PERL_SWITCHES=-MDevel::Cover=-select,Monash/LDAP make test
Then this shouldn't be necessary.
However, I still get a report from cover that ldap_groups() is untested,
even though Test::More says it passed 100%
If this is still a problem, could you confirm that you are using the
latest release, 0.50. You're on RH9, right?
Is there some interaction with Test::More::use_ok that is stopping D::C
instrumenting the module correctly ?
It's possible. I fixed a bug in this area which first appeared in
perl-5.8.3. Which version are you using? Still redhat's dodgy 5.8.0?
http://www.nntp.perl.org/group/perl.perl5.porters/85930?show_headers=0
(I meant use_ok in that message, not isa_ok.)
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: special blocks tests fail on 5.8.0
On Thu, Oct 28, 2004 at 01:31:40PM +1000, [EMAIL PROTECTED] wrote:
I dont know if the code under test is wrong or the expected output.
I run RH9, which uses Perl 5.8.0. I was getting a failure for
t/aspecial_blocks, indicating a difference in the expected output for a
CHECK {} block.
If I remember correctly, RH9 shipped with a 5.8.0 which was really 5.8.0
plus a bunch of patches. I suspect that one of those patches is causing
this behaviour, enabling Devel::Cover to check the coverage of your
CHECK blocks. You'll notice that your patch effectively brings
test_output/cover/special_blocks.5.008 up to
test_output/cover/special_blocks.5.008001.
IF the expected output is wrong, I have provided a patch of the
test_output/cover/special_blocks.5.008 golden file.
So, I won't apply this patch, since it would break every standard 5.8.0
installation, but thanks very much for taking the trouble to create it.
And the good news is that you can safely use Devel::Cover, with the
added bonus of getting your CHECK blocks covered.
I dont have a patch if the code under test is wrong, wouldnt even have a
clue where to start - I ran t/aspecial_blocks under Devel::ptkdb, and
realised I'd need to dig a lot deeper to find out where the code goes...
Can anyone give me a hint to track the code for a CHECK block? Do I have
to trace the dynamically generated command maually ?
If you are still interested, the code in question is in Cover::report(),
the section that starts if (exists B::check_av). In a standard 5.8.0
that would be false. In 5.8.1 and, it would seem, RH9 5.8.0 it is true.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Branch coverage issue in Devel::Cover
On Tue, Oct 12, 2004 at 02:20:19PM +0530, Padubidri Nagaraja Rao, Guruprasad (Guruprasad)** CTR ** wrote: Thanks for the solution. However, i get the following error when i execute 'perl cover -report text -ignore_re File/Copy'. error stat(-ignore_re): No such file or directory at /temp/din/Devel-Cover-0.47/cover line 101 Can't open database /error Any clue why this error occurs. Ah yes - that option was new in 0.48. I suggest you either upgrade to version 0.49, use -ignore with the full path to File::Copy, or live with getting the extra data or bogus branch report. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Branch coverage issue in Devel::Cover
On Mon, Oct 11, 2004 at 06:09:04PM +0530, Padubidri Nagaraja Rao, Guruprasad
(Guruprasad)** CTR ** wrote:
Hi,
I am not able to get branch coverage for the following piece of code.
code_snippet
#!/usr/bin/perl
use File::Copy;
if (move(junk, junk1))
{
print file moved\n;
}
else
{
print file not moved - $!\n;
}
/code_snippet
Environment :
Solaris 9
Perl 5.6.1
Devel-Cover-0.47
When i run 'cover', Statement coverage shows 100% but
branch coverage shows 0%. Why?
Because Devel::Cover is buggy?
The problem here is that by default coverage data is not being collected
in File::Copy, it being a core module. So as soon as we hit code from
File::Copy, a flag is set internally to say don't collect coverage. The
trouble is that that flag is not being reset until we hit a new
statement in the test file, since that is the first time we can tell
from which file the op was created. In this case, the next statement
comes after the branch data would be collected.
You can get around this by turning on coverage collection for
File::Copy.
$ perl -MDevel::Cover=-select,File/Copy myprog
You can tell cover to ignore data from File::Copy when you generate the
report.
$ cover -report text -ignore_re File/Copy
I was actually just looking at this last night but didn't have a small
example to work with, so thank you very much for that. Actually, a
small test case is probably the single biggest help to me in cases such
as this. The only thing better is if it is accompanied by a perfect
patch ;-) I will see if I can work out some sort of solution for the
next release.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Using Devel::Cover in different ways - Help Reqd.!!
On Fri, Oct 08, 2004 at 04:50:28PM +0530, Padubidri Nagaraja Rao, Guruprasad (Guruprasad)** CTR ** wrote: Hi, I've few perl scripts called from C++ programs. I wanted to do code coverage for those scripts and i am using Devel::Cover module. Since the existing C++ programs are huge and takes lot of time to compile, I don't want to change the existing C++ code to build those scripts with coverage. For example, i don't want the following changes to be done inside a C++ program. perl -MDevel::Cover script name with arguments Is it possible to change the perl script itself in such a way that it can give code coverage metrics along with normal execution. I tried to include Devel::Cover module inside the perl script (use Devel::Cover) and executed. It didn't give any metrics and just printed 'n/a' against all the coverages (statement, branch, sub, cond, time, total). How to handle this scenario? One more thing to add. if it is possible to do it inside the perl script then Is it possible to read some ENV variable and decide on whether to include coverage or not. I am just trying to add some flexibility so that i don't get the coverage everytime it is executed and i only want it when i am running the unit test cases of C++ programs. It is unclear to me whether you are embedding a perl interpreter in your program, or just calling perl from within the program. In either case, you should be able to control the collection of coverage data by setting PERL5OPT. $ PERL5OPT=-MDevel::Cover your_prog This will not work, however, if you have embedded perl and pass in a modified environment which changes that variable. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: running Devel::Cover in mod_perl (1.3)
On Tue, Oct 05, 2004 at 11:27:01AM -0400, Geoffrey Young wrote: as promised, here is a tarball that includes a 'test-cover' target. http://perl.apache.org/~geoff/Apache-Test-with-Devel-Cover.tar.gz it's made a little more complex than it needs to be because of version restrictions: 'test-cover' requires the (yet unreleased) Apache-Test 1.14 as well as the (yet unreleased) Devel::Cover 0.48. Ooh! That's a good idea! Maybe I can release some software which sounds wonderful but has unsatisfiable prerequisites ;-) I've just released Devel::Cover 0.48, so it'll be flying around CPAN mirrors as I write this. It's also available from my homepage if you can't wait. Apart from playing nicer with mod_perl, this release also: - plays nicer if you upgrade perl underneath it - adds an annotation API - sorts out ignoring extra subroutine and friends - fixes problems with references in INC (which can't be handled) - and much more Quite a bit of work went into this release, but I'm hoping only to have improved things. If you notice any problems please report them. I'm aware of a few conditions where some coverage is not reported correctly. If anyone hits that and can reduce it to a small script I'd be very grateful. I have a bit of a backlog of mail that's been waiting for me to get this release out. If you've sent me something I'll try to get to it within the next couple of weeks. Otherwise, please feel free to send me a reminder. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: running Devel::Cover in mod_perl (1.3)
On Tue, Oct 05, 2004 at 02:08:25PM -0400, Geoffrey Young wrote: David Wheeler wrote: Perhaps I should add support for Module::Build's covertest action to Apache::TestMB...just tell me what it needs to do. I think that all Apache::TestMB would need to do is add a make target that looks like this: test-cover :: @cover -delete @HARNESS_PERL_SWITCHES=-MDevel::Cover=+inc,$(HOME)/.apache-test APACHE_TEST_EXTRA_ARGS=-one-process $(MAKE) test @cover I wonder whether we shouldn't try to standardise the target name before it's too late to do so. Module::Build uses covertest, I've always used cover, and Geoff has just used test-cover. I'm not overly concerned, but I'll admit to preferring something starting with cover, because it completes more easily. (Yes, I'm that lazy. I even have make aliased to n.) So, standardise on covertest? Opinions? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: running Devel::Cover in mod_perl (1.3)
On Tue, Oct 05, 2004 at 11:32:23AM -0700, David Wheeler wrote: On Oct 5, 2004, at 11:25 AM, Paul Johnson wrote: I wonder whether we shouldn't try to standardise the target name before it's too late to do so. Module::Build uses covertest, I've always used cover, and Geoff has just used test-cover. Actually, Module::Build uses testcover. Ah. I was believing what you wrote before ;-) I'm not overly concerned, but I'll admit to preferring something starting with cover, because it completes more easily. (Yes, I'm that lazy. I even have make aliased to n.) I think that Dave called it testcover in Module::Build because it runs the tests first, and then runs cover. Fair enough. So, standardise on covertest? Opinions? You'll have to convince the Module::Build folks to change...Personally, don't care one way or the other. Yeah. I was thinking that since Module::Build is the biggest thing already out there we would just go with whatever they had. On Tue, Oct 05, 2004 at 02:36:09PM -0400, Geoffrey Young wrote: Devel::Cover is your realm, so I'm happy to follow whichever standard you choose. as david mentions, Module::Build already has a target, but it would be nice if they could bend to your will as well ;) Too late for that, I think ;-) I'm happy with what they have. OK then, testcover it is. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: running Devel::Cover in mod_perl (1.3)
On Sat, Oct 02, 2004 at 11:20:05AM -0700, Kevin Scaldeferri wrote:
On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote:
So, I don't expect anyone to try to figure out this stack trace stuff,
but I'm curious if other people have seen stability problems like
this? Alternatively, if someone can tell me the exact logistics of
how they get the coverage out in the end, I'd appreciate it. Is there
another way than 'kill'ing the apache process to get Devel::Cover to
write its data? It seems to do it at one point during startup, but
after that it looks like it just stays in memory, which I end up
losing when things go bad terminating the process.
Sorry, to resurrect this, but I was hoping to hear from some other
people who are using Devel::Cover in mod_perl about just how they run
the tests, and get the results out. Are people doing something other
than killing the server in order to get Devel::Cover to dump the data
out of memory to the disk?
You could try calling Devel::Cover::report() when you want to get to the
coverage data, but I've never tested that. If it worked you would, at
the minimum, need to set the coverage criteria again in order to get any
further coverage. It's probably better to stop and start the server.
Could anyone give a cookbook type procedure
that they use to do this sort of data collection?
I work within the Apache::Test framework and add a bit of gumph for the
coverage stuff. I'm very impressed with Apache::Test - it lets me do
what I want very easily. For more information on Apache::Test see
http://perl.apache.org/docs/general/testing/testing.html
I add the following to t/conf/extra.conf.in:
IfDefine COVER
Perl
use Devel::Cover qw(-select \.conf$);
/Perl
/IfDefine
And my Makefile.PL is as follows. I'll include the whole thing so you
can see how everything fits together, though you won't necessarily need
it all. And hopefully that means I won't break it trying to cut it
down. Geoff may well be able recommend something better, but this setup
allows me to run:
make test # run all tests in a new server
make restart# restart server
make stop # stop server
make cover # collect and report coverage data on all tests
run in a new server and restart server to
collect more coverage
make restart_cover # stop server, collect and report on coverage, and
restart server to collect more coverage
make clean # as expected
And I even get coverage on the Perl parts of the conf files, which was a
pleasant surprise ;-)
[ Just before sending this I notice Geoff has recommended something
better, but I'll send this too as another WTDI. ]
#!/usr/bin/perl
# Copyright 2004, Paul Johnson ([EMAIL PROTECTED])
require 5.6.1;
use strict;
use warnings;
use ExtUtils::MakeMaker;
use ExtUtils::Manifest maniread;
use Apache::TestMM qw(test clean);
Apache::TestMM::filter_args();
Apache::TestMM::generate_script('t/TEST');
$| = 1;
my $Version = 0.03;
my $Date = 29th September 2004;
my $Author = '[EMAIL PROTECTED]';
my @perlbug = (perlbug, -a, $Author,
-s, Installation of Retemps $Version);
my $Perlbug = join , map { / / ? '$_' : $_ } @perlbug;
my @files= sort keys %{maniread()};
my @versions = grep { $_ ne README $_ ne Makefile.PL } @files;
mkdir t/logs or die Can't mkdir t/logs: $! unless -d t/logs;
$ExtUtils::MakeMaker::Verbose = 0;
WriteMakefile
(
NAME = Retemps,
VERSION = $Version,
AUTHOR= 'Paul Johnson ([EMAIL PROTECTED])',
DIR = [],
EXE_FILES = [],
PREREQ_PM = {
Apache::Test = 0,
Template = 0,
},
dist = { COMPRESS = gzip --best --force },
clean = { FILES = join , t/TEST, cover_db,
map $_.version, @versions },
realclean = {},
depend= { distdir = @files },
);
sub MY::libscan
{
my ($self, $path) = @_;
(my $p = $path) =~ s/^\$\(INST_LIB\)/lib/; # 5.6.1
$p =~ s|\\|/|g if $^O eq MSWin32;
# print $path $p\n;
my $wanted = -d $p; # 5.9.0
for my $f (@files)
{
# print $p - $f\n;
last if $wanted ||= $p =~ /$f$/;
}
$wanted $path;
}
sub MY::postamble
{
qq[
SET_VERSION = \$(PERL) -pi.version \\
-e 's/(^\\s*(?:our\\s+)\\\$\$VERSION = )\\d+\\.\\d+(;)/\$\${1}$Version\$\$2/;' \\
-e 's/(Version )\\d+\\.\\d+( - ).*/\$\${1}$Version\$\${2}$Date/;' \\
-e 's/(Retemps Version )\\d+\\.\\d+/\$\${1}$Version/;' \\
-e 's/(\\buse Retemps(?:::\\w+)*\\s+)\\d+\\.\\d+/\$\${1}$Version/;'
tags : @files
\t ptags @files
@versions : Makefile.PL
\t \$(SET_VERSION) @versions
README : lib/Retemps.pm
\t TERMCAP= COLUMNS=80 pod2text lib/Retemps.pm | \\
\$(PERL) -n \\
-e 'print if (/NAME
Re: Fine-tuning output from Devel::Cover
On Tue, Aug 17, 2004 at 06:22:13AM -0700, Jim Keenan wrote: Two days ago I uploaded the most recent version of my module List::Compare to CPAN. This was the first version in whose development I used Paul Johnson's Devel::Cover to analyze the test suite's coverage of the module's code and, as a result, over 3300 tests were added, both to test new code and to test older code more thoroughly. Wow! The first thing I noticed after using Devel::Cover was how much output it generates. The HTML files depicting the line-by-line status of the coverage are enormous. You think they are large now ... :-) As an alternative, I generated a plain-text file like so: cover cover_db -report=text LC_coverage_20040814.txt Even that file was large. Since my coverage was fairly good to begin with, what I *really* wanted was a smaller file which reported on the uncovered elements. I took two approaches: (1) hacking up a Perl script which parsed the plain-text report; (2) manually cutting-and-pasting the uncovered elements into a new, much smaller plain-text file. For example, I edited the file so that only subroutines with uncovered branches were printed out. But I wondered: Wouldn't be easier to pass options to 'cover' so that a report focusing on uncovered items would be generated? Is this possible now? The documentation for cover's options is, to say the least, very terse, and I can't tell whether it can DWIW. At the moment, no, there is no option to do what you want. So: Can Devel::Cover's 'cover' program be used to generate reports of uncovered statements/branches/conditions/only? What you want to do (no really, you do) is to write a new report which only reports on the uncovered constructs. Or maybe an option to the existing report(s) is a better solution. Or maybe an interactive backend is the real solution, using Tk, or Gtk, or Wx, or CGI or whatever. I have deliberately made it as easy as possible to write new backends in the hope that people would do so when the need arose. The trouble is that Michael made the current default report so nice that most people don't even consider the need for something different. But writing a new backend is fairly simple. It's probably easiest to copy from one of the existing ones - Text is the shortest and clearest. There is an API to access the coverage data, you can pass in options from cover, and with the backend in the Report subdirectory it can be called from cover. If anyone wants to write a new backend, I'd be happy to include it in the distribution, or for you to release it separately. Just be aware that the main reason I still call the code alpha is because there may still need to be API changes. Hopefully only minor ones or backwards compatible ones now though. So I'm afraid that at the moment there is nothing to do what you want, and your options range from cover -report text | grep '\*\*\*' through to writing a full blown gui backend. By the way, how big is enormous? I had never expected the size of the HTML output to be a problem, but it obviously is to some people. The current output is much smaller than that from the report that I originally wrote. I don't think there's much scope for reducing its size without also reducing the content. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: CPANTS preview - coverage in CPAN testers reports
On Sat, Jul 24, 2004 at 08:05:06PM +0300, Gabor Szabo wrote: On Sat, 24 Jul 2004, Thomas Klausner wrote: What about adding (optional) coverage reports to the reports the CPAN testers send in ? That might be a good idea. But AFAIK, coverage reports can vary greatly on different platforms/Perls/installed modules IMHO this is exactly the reason it can be interesting to receive it from several sources. Then CPANTS could display some statistical number about the reports. Or better still, merge the reports. Any module which has platform specific code, or which can take different paths depending on factors not determined by the module itself, needs to merge reports from all those platforms in order to obtain a true coverage picture. I've had a plan for a while now of some central server where people will be able to upload coverage databases which will then get merged and reports produced. I'm slowly making the changes to Devel::Cover to allow that. When such a system is in place, it could be queried in order to provide some input towards the kwalitee. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: CPANTS preview
On Thu, Jul 22, 2004 at 05:25:38PM +0100, Nicholas Clark wrote: On Thu, Jul 22, 2004 at 04:28:08PM +0200, Thomas Klausner wrote: Hi! I ran CPANTS today, you can view results here: Oooh. Nice Agreed. I think it is a great start. Thanks very much for your work. Max Kwalitee is 10, which is reached by 99 dists. Will it go up to eleven soon? :-) At the moment the focus seems very much on packaging. That's fine, but it does mean that correctly packaged junk looks pretty good. In time, some more metrics would be good. Some suggestions: - How do the CPAN testers reports look? - What does cpanratings think? - Some analysis of the RT action. - Number of releases, perhaps in relation to the size of the code. More releases expected for larger code. - Static analysis. - Test coverage. Some of those will be a lot harder than others, and the metrics will obviously need to be weighted, but I just wanted to throw out a few thoughts from the safety of the peanut gallery. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover on Windows, ppm anyone ?
On Fri, Jul 16, 2004 at 02:57:56AM -0400, Randy W. Sims wrote: Gabor Szabo wrote: I can see from the testers page that Devel::Cover is supposed to work on Windows. Is there a ppd distribution of it somewhere so I can install it on ActivePerl without a compiler ? Currently if I type ppm install Devel::Cover I get version 0.2 of Devel::Coverage. Not what I wanted. It builds ok for me on one of my Windows machines, so I'm not sure why it's failing ActiveState's build system http://ppm.activestate.com/. The log message isn't that helpful. I know that their system basically goes through CPAN trying to build each module. Only those that build out of the box without intervention make it to the repository. I haven't really checked, but one common cause of failure, I would suspect, are dynamic dependencies, i.e. dependencies that are not specified to MakeMaker. That shouldn't be a problem for Devel::Cover. The two prerequisites are listed in the Makefile.PL, and are in the core in 5.8 anyway. As you mention, the log file from the Windows build is useless, but from the other builds, which all fail too, I can see that when the tests are run the core modules are being picked up from a tmp dir, which is not where they were found when Makefile.PL was run. This means that Devel::Cover does not know they are core and so collects coverage on them. This in turn causes the tests to fail. It seems likely that something similar is happening with Windows. I don't think there is anything I can reasonably do about that from my side. I suppose it's the price you pay for deviating from the four line mantra. But if anyone does find out what is actually happening and I can fix things up on my side I'll be happy to look into it. I suppose I could skip all the tests if I can somehow find out it's running on ActiveState's build system. As an aside, my Gedcom module always used to fail because the tests took too long to run, though I see it passes now. And my Shell::Source module has passed, even though it doesn't run on Windows ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Phalanx: What if full coverage isn't possible?
On Fri, Jul 09, 2004 at 12:10:52PM -0500, Pete Krawczyk wrote:
Consider the following code:
$impclass ||= implementor($scheme) ||
do {
require URI::_foreign;
$impclass = 'URI::_foreign';
};
That's in URI.pm, lines 54-58.
Devel::Cover treats that as a conditional. So short of deleting
URI::_foreign, that do BLOCK is never going to return false.
Devel::Cover will always see that as a partial test, and never a full
test:
http://www.petekrawczyk.com/perl/URI-orig/blib-lib-URI-pm--condition.html#L57
I don't like that code anyway, since it basically boils down to
$impclass = $impclass = 'URI::_foreign';
assuming $impclass and $scheme aren't set.
Is that a bug, then? Or is it something else? And how should I notate
that, keeping in mind the goals of Phalanx, so that it's clearly visible
that no test of that condition's failure can truly take place in a regular
make test run?
There is some initial code in place in Devel::Cover to handle this
situation, but it is not well tested, not documented at all, and has no
(usable) interface. But you are welcome to play with it anyway ;-)
Should you wish to do so, I would suggest grepping he source for
uncoverable, and looking at tests/uncoverable.t and
tests/.uncoverable. Also, google for perl-qa uncoverable to view
previous discussion of this topic.
.uncoverable is a file holding information about which parts of the
module are uncoverable and why. The format is lines of six columns:
1. md5sum of source file
2. type of coverage
3. line number
4. which criterion on that line (0 for first)
5. which part of the coverage (based on the internal representation)
6. reason
Michael Carman is looking at making this more usable. Columns one and
five are especially problematic at the moment. So for the time being
you might prefer to simply note which parts cannot be covered and why,
and later convert that to whatever system we ultimately use.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Infinite recursion
On Wed, Jun 30, 2004 at 11:42:34AM -0400, Vsevolod (Simon) Ilyushchenko wrote: I have tried to run Devel::Cover on my tests that use Test::Unit, and I am getting this after the code is run: Deep recursion on subroutine B::Deparse::find_scope at /usr/lib/perl5/5.8.1/i386-linux-thread-multi/B/Deparse.pm line 1317. Deep recursion on subroutine B::Deparse::dq at /usr/lib/perl5/5.8.1/i386-linux-thread-multi/B/Deparse.pm line 3550. Deep recursion on subroutine B::Deparse::dq at /usr/lib/perl5/5.8.1/i386-linux-thread-multi/B/Deparse.pm line 3551. Deep recursion on subroutine B::Deparse::find_scope at /usr/lib/perl5/5.8.1/i386-linux-thread-multi/B/Deparse.pm line 1317. However, nothing seems to be affected - the table is generated by 'cover'. I'd like to debug this, but not sure how to proceed. Actually, it's not infinite recursion, just deep recursion, where deep is defined as 100, or is it = 100, I can't remember offhand. As you've noted, everything should still work - it's just a warning, and as such it can be turned off with Cno warnings recursion. I was (and still am) of the opinion that 100 is a little low nowadays, and sent a patch to p5p a couple of weeks ago to raise the limit to 1000, which is what parrot uses, I think. Unfortunately, everyone else seemed satisfied with 100, or at least no-one else spoke up in favour of the patch, and so the limit will remain at 100. I didn't want to have to put Cno warnings recursion in Devel::Cover, as it seems to high a level to me. Maybe it should go in B::Deparse. But then I've also hit a similar problem using Parse::RecDescent to parse a language, which I why I wondered about upping the limit. But I suppose I'll turn off the warning from Devel::Cover. That seems the most pragmatic solution at the moment. In the meantime, please just ignore the noise. Or maybe add -X to your command line, if you're feeling brave. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover and nested subroutines
On Mon, Jun 28, 2004 at 01:55:09PM -0400, Geoffrey Young wrote: 2. Devel::Cover needs to be able to find Parser.yp. In the example the filename given is Parser.yp, but the file is actually at lib/My/Parser.yp and so Devel::Cover can't find it. Changing the example to give the full filename, you mean changing the #line directive? Yes, sorry, that's exactly what I mean. or putting in a link from the current directory fixes the problem. I'm not sure if this is actually a problem with Parse::Yapp or just a result of the way you packaged up the testcase. well, the packaging is pretty much the way the code I'm testing is layed out - Foo.yp in the same directory as Foo.pm, and all under some lib/ someplace. fairly standard I'd think. Hmm. If the name was My/Parser.yp you could argue that Devel::Cover should search @INC to find it, but as it stands I don't see a sensible and general way to locate the file with the information provided. but the symlink works - linking Foo.yp to the top-level directory, along side cover_db. 3. Parse::Yapp doesn't clean up after itself by setting the line number and filename back to what it actually is, which means that subsequent code coverage is reported on in the grammar file even though it didn't come from there, which can be somewhat surprising. hmph. So I'm afraid there's not much I can do about this one - it will need to be fed to the author of Parse::Yapp and he can decide if he wants to do anything about it. I suppose I could do that, but it seems kinda strange to ask him to change stuff around just so we can have good test metrics. but, per your suggestion, at least there is a simple workaround - thanks for that. Yes, though you could argue that any warnings or errors coming from that code will be confusing anyway. In any case, the first fix will be in the next release, excellent, thanks. Which is now out. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover bug
On Sat, Jun 26, 2004 at 08:41:08PM -0400, Vsevolod (Simon) Ilyushchenko wrote: The problem occurs because Devel::Cover overrides some of B::Deparse's subs, but when you go calling them in a program it gets upset. The solution is to only override the subs for as long as is necessary. The change is in my development copy and will be in the next release. Muchas gracias! I am looking formard to using Devel::Cover on my testing classes (the offending code occured in the Test::Unit framework). Sounds good. I've just released 0.47 with this fix in it, so let me know if there are any other problems. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover bug
On Thu, Jun 24, 2004 at 12:45:26PM -0400, Vsevolod (Simon) Ilyushchenko wrote:
Hi,
Hello,
I've run into Can't call method add_statement on an undefined value
running Devel::Cover. Apologies if this was reported before, but the
list archive is not searchable. I am using perl 5.8.4 and Devel::Cover 0.46.
I think the list is archived in a number of places. I suppose the
official archive is at http://www.nntp.perl.org/group/perl.qa/
And this is the first time that I've come across this bug, so thanks
for reporting it.
To reproduce the bug, run
/opt/perl/bin/perl -MDevel::Cover -MFooBar -e FooBar-new-test_foo
The files FooBar.pm and CodeRef.pm are attached.
The bug occurs while calling $sub in CodeRef::to_string. It is probably
related to using B::Deparse, but I was not able to minimize the code
further and still reproduce the error.
Absolutely correct. I was able to reduce the code to:
require B::Deparse;
B::Deparse-new-coderef2text(sub {})
The problem occurs because Devel::Cover overrides some of B::Deparse's
subs, but when you go calling them in a program it gets upset. The
solution is to only override the subs for as long as is necessary. The
change is in my development copy and will be in the next release.
Thanks again for reporting the problem and producing a small test case.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Devel::Cover and nested subroutines
On Fri, Jun 25, 2004 at 11:07:06AM -0400, Geoffrey Young wrote: hi paul :) I recently discovered an issue with nested subroutines while using Devel::Cover with Parse::Yapp. the basic issue is that some subroutines are not discovered by Devel::Cover and thus no metrics are generated. there are two files in the tarball. Foo.pm is a minimal test case showing that two subroutines are missing (one defined and one anonymous). Parser.pm is an autogenerated file based on Parser.yp that illustrates the same thing - note that the _missing() subroutine is missing from coverage results (as well as a handful of anonymous nested subroutines I think). the only interesting thing is that the behavior of my minimal test case and Parser.pm seem to be opposite - in the former the missing subroutine is the one that contains the anonymous sub, while in the latter is is the named subroutine that occurs after a nested anonymous sub. anyway, let me know if there is anything else I can do - I realize this is kind of obscure, so no pressure :) oh, and I tested using 0.46 and both 5.8.4 and 5.8.0. Thanks a lot for the test cases. I think there are two separate bugs here, but I'm only going to take responsibility for one ;-) First, mine. The problem with Foo.pm (the minimal test case) is that completely empty subroutines (that is subs which contain no statements at all) are ignored as far as subroutine coverage is concerned. That is the case for both named and anonymous subs. The op tree for an empty sub didn't contain the structure I was looking for, so it wasn't recognised as a sub. I have put in a fix for this, but it only works with Perl 5.8.2 and later versions. I've not gone trying to get it to work with earlier versions, since it is pretty obscure and I prefer to keep the code reasonably clean. Or maybe I'm just too lazy. In any case, let me know if this is going to cause anyone problems. I have documented it as a bug though, and upped the recommended version to use from 5.8.1 to 5.8.2. Then the second bug. The problem here is that if you lie to perl it will bite your bottom ;-) Parse::Yapp appears to take portions of the grammar in Parser.yp and insert them into Parser.pm. In doing so, it quite reasonably wants to reference the original grammar which means that perl will report errors in the grammar where they appear in the grammar. Parse::Yapp does this by using the #line directive. This is all well and good, and Devel::Cover will honour that by reporting the coverage in the original grammar. But ... This means that: 1. The coverage will not be reported in the Parser.pm module. 2. Devel::Cover needs to be able to find Parser.yp. In the example the filename given is Parser.yp, but the file is actually at lib/My/Parser.yp and so Devel::Cover can't find it. Changing the example to give the full filename, or putting in a link from the current directory fixes the problem. I'm not sure if this is actually a problem with Parse::Yapp or just a result of the way you packaged up the testcase. 3. Parse::Yapp doesn't clean up after itself by setting the line number and filename back to what it actually is, which means that subsequent code coverage is reported on in the grammar file even though it didn't come from there, which can be somewhat surprising. So I'm afraid there's not much I can do about this one - it will need to be fed to the author of Parse::Yapp and he can decide if he wants to do anything about it. In any case, the first fix will be in the next release, and thanks again for the great test cases. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: testing for unsuccessful require - mocking require ?
On Sat, Jun 19, 2004 at 09:11:43PM -0200, Gabor Szabo wrote:
I would like to test a module for unsuccessful require while the
required module is installed. That is I'd like ot test how my code would
work if Foo.pm was not present.
In the middle of a module I have code such as
eval {
require Foo;
};
if ($@) {
foo();
} else {
my_own_foo();
}
I already installed Foo so I can test the behaviour of the code
with Foo. How can I test now the behaviour without Foo ?
Removing Foo.pm is not an option.
I have some ideas outlined below, but I'd like to get your recommendation.
[snip]
In general I'd like to get your opinion on how to mock unsuccessful
require.
local *CORE::GLOBAL::require = sub { die require $_[0] failed };
Goes back to before 5.6. I think it came in in 5.004.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: New Devel::Cover Noise
On Thu, Jun 17, 2004 at 09:31:48AM -0700, David Wheeler wrote: I checked in a bunch of changes to my module last night, and then the nightly process that runs cover on it output these lines: Devel::Cover: ignoring extra subroutine Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra subroutine Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra statement Anyone know what they mean? What extra statements and subroutines? Good Question! It's a shame you checked in a bunch of changes rather than one small change, otherwise you could have told me ;-) But I can explain what is happening at a low level. For the first forty or so releases Devel::Cover would collect coverage data for each run by noting which ops were executed and then, at the end of the run, it would look through each subroutine and match the constructs in the subroutine with the coverage of the ops to produce the metrics for that run. These data would be stored for each run, and when the cover program was eventually run they would be merged to produce the final report. This worked well, but had a couple of drawbacks, so a little while ago I changed things rather fundamentally. Now, at the end of a run there are two sets of files created. One, which contains the structure of the program - where the subroutines, statements, branches and conditions are, and the other which contains data about how many times each construct was exercised. But the structure data only needs to be created if it does not already exist, so subsequent runs can benefit by not have to create and store these data. The main advantage, however, which is as yet unrealised, is that the data for different runs can be directly compared, which should yield some interesting information. But there is a downside to all this. It's called Perl. Perl is so dynamic that the structure of one run may differ from the structure of another. I suppose this will happen when a subroutine is created at run time in one run but not in another. This would ultimately be through an eval, but might be hidden behind an AutoLoaded function or something similar. What happens then is that on attempting to add collected data to the run information the (first) structure is searched, but the construct is not found, and this warning is emitted. In practise this means that those constructs will not be considered as far as coverage is concerned. This is a bug, and I've just added it to the TODO list. If anyone is able to reproduce this with a small example I'd be very grateful to receive it, otherwise I know of a number of larger modules which also exhibit this problem. Thanks for reading this far. I must stop now as half time is over, so it's back to the football ... -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Removing Tests from Devel::Cover results
On Thu, Jun 17, 2004 at 11:58:16AM -0400, Geoffrey Young wrote: Tony Bowden wrote: Is there any simple way to remove the test files themselves from the Devel::Cover results? i.e. just see the coverage analysis of the files being tested rather than all the t/* files as well? We want to monitor the total coverage over time on a project, and it would be nice to just grab that from the bottom line of the HTML report. But, from what I can see, we can make that number get larger purely by adding more and more lines to test files that don't actually test anything, as running those lines will increase the coverage of the project as a whole! If there were a flag that would -exclude (or -ignore, both seem to be documented?), the actual test files, this might be slightly nicer. ignore and +-inc do the trick for me. my current 'make cover' target starts like this: [EMAIL PROTECTED]::Cover=-ignore,\.t\$$, \ -ignore,apache_test_config.pm,+inc,$(TOPDIR)/lib, \ +inc,$(TOPDIR)/Apache-Test\\ This is generally the best way, as Devel::Cover will try to collect as little information as it can while the tests are running. If you have already collected the coverage the -file and -exclude options to cover will allow you to choose the files on which to report. I should probably change those to be -select and -ignore to match. Thank goodness I'm still on alpha versions ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover: completing $x{foo} ||= 1 conditions
On Fri, May 21, 2004 at 12:50:55PM -0400, Geoffrey Young wrote:
I might like to signal Devel::Cover that func() has a constant return (or
lack thereof).
I don't know if I would like this feature. To me it would allow you to
falsely skew the results of the Devel::Cover output. I look at
Devel::Cover as a harshly objective analysis of my test-code coverage,
anything destroying that objectivity IMO would lessen the value of the
tool.
however, in the process of development we are required to analyze any of the
inevitable gaps and decide whether the unhit condition is valid. if it is
we write a test for it. if it represents a condition we would explain away
(D::C limitation, or whatnot) then it would be nice to have some way to
track it within the tool itself. partially to appease management with heavy
greens, but more to save development cycles chasing down issues I (or other
developers) have analyzed before.
I enjoyed this discussion and the various opinions and suggestions.
It has always been my plan to include something along these lines. The
TODO list (which seems to keep growing) mentions Marking of unreachable
code - commandline tool and gui. I think this is useful for exactly
the reasons Geoff gave. Hacking the figures to appease management seems
to me to be quite a long way down a slippery slope, but (unfortunately)
I can understand the motivation.
For me, 100% coverage has never necessarily indicated an error, which
is why, internally, each item of coverage has associated with it the
number of times it was covered, the total number of times that it could
have been covered, the percentage that represents and, crucially,
whether or not that indicates an error.
I have just released Devel::Cover 0.45 and I've included some code which
is working towards a solution in this area. The code seems to work, but
there is no (reasonable) user interface for it, and it is not documented
at all. You'll need to grep the source for uncoverable if you want to
play with it. With this, the textual report can report no errors even
when the coverage is not 100%.
Of course, this was not obvious the Michael when he wrote the html
output backend, and so the colours there are dictated by the percentage,
but if you use my original (and ugly) html_basic backend you can see how
you can get green everywhere without 100% coverage. The halfway house
of html_subtle is, fittingly, halfway between in this regard too ;-)
Michael has some ideas for backends and interfaces to the uncoverable
code, which I'll let him talk about or work on as he sees fit.
Actually, I've just noticed that the test I shipped is broken, which
illustrates the fragility of the interface. Or the testing framework.
Or the code. Or something.
Other features of this release:
- Cope with spaces in build path on Windows (Max Maischein).
- Allow Devel::Cover to be used under mod_perl (Philippe M. Chiasson).
- Handle $x ||= 1 and friends nicely, including subs and *foo{THING}.
Enjoy,
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Style question
On Tue, May 25, 2004 at 07:58:21PM +0200, Francisco Olarte Sanz. wrote: 1st of all, thanks everyone for the prompt response regarding my previous question about return values. Now a style question. I'm doing a database oriented module, and I have rouhly the following tests: 1.- Test wether module can load ( just a require inside an eval ). 2.- Test a bunch of functions for string processing (escaping) etc.. which don't need server connections. 3.- Test connection to the database. 4.- Create a test database, connect to it 5.- Create test tables, populate them, testing insertion functions on the way. 6.- Lots of tests which need the test database. 7.- drop test database. I have 1 in a file, 2 split in several. 3 can be put in it's own file, but the problems arrive with steps 4-7. Steps 5 and 6 are lengthy, and I'd like to split them into several files, giving files 4, 5a, 5b, 5c, 6a, 6b, 6c..6z, 7 but in this case steps 4-7 should be run to completion. This goes against the recomendation of having tests which can be run separately ( and takes slightly longer as i need to reconnect on each test, but tests don't need to be so efficient). So I'm now putting 4- in a single file, but it's becoming huge ( hundreds of tests ). My question is.. ¿ Which aproach is better, have a single independent huge test file or several interdependent smaller ones ( w/ notes in the readme stating test dependence ) ? In general, I prefer the convenience of independent tests, but I have also written tests which have an ordering where that makes more sense. But remember that tests are just programs. If they are unwieldy, bring standard software development techniques to bear. There is no reason not to include modules in your distribution which are only required as part of the test suite. Then again, I like Joshua Pritikin's parenthetical question in Test.pm, Your test code should be simpler than the code it is testing, yes?. Hmmm. I'm not sure whether that will help you make a decision or not. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
