Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
I'll try this out on Darwin and (Debian) Linux this weekend and see what happens. Thanks.
Re: [perl #52130] [BUG] postconfigure tests hanging on feather.
From: [EMAIL PROTECTED] via RT [EMAIL PROTECTED] Date: 2008/03/26 Wed PM 05:13:17 CDT To: [EMAIL PROTECTED] Subject: Re: [perl #52130] [BUG] postconfigure tests hanging on feather. I'll try to look into this. What's puzzling is that we get tested on *many* Linux boxes but the overwhelming majority report no problem here. something to do with svk being on the box but never having been run by that user? istr something like this before. iirc hitting enter will make the problem go away, never to return, because svk is waiting for input. Yeah, but svk is waiting for a 'y' or 'n', to set up the default cache dir. Seems to be as much an svk issue, as svk info shouldn't have to create that user's svk environment by default. Or, at least, a switch to allow svk --dont_init info a Thanks, Andy. Subsequent to the last post we had a discussion on #parrot. Coke will be posting an RT which will give us some new direction, and we'll no doubt be contacting you to see test whatever solutions we cobble together. kid51
Re: Re: pdd17pmc branch review
From: Will Coleda [EMAIL PROTECTED] I am confused why this wasn't failing for allison chromatic. I added in the missing headers in r26227. I'll try to update and give it another spin later today.
Re: Re: pdd17pmc branch review
From: Will Coleda [EMAIL PROTECTED] I am confused why this wasn't failing for allison chromatic. I added in the missing headers in r26227. Note that I was reporting on an earlier revision. In 20080304.26216.pdd17pmc.txt, the second bunch of digits is the revision number at which I was building and testing.
Re: Re: pdd17pmc branch review
From: Will Coleda [EMAIL PROTECTED] I am confused why this wasn't failing for allison chromatic. I added in the missing headers in r26227. All tests passed at r26228 (except the macro.t test that's been failing in trunk). kid51
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config st
From: Andy Dougherty via RT Date: 2007/12/11 Tue AM 08:38:17 CST Subject: Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps I don't think this will work. Specifically, to conduct a basic test of that compiler's functioning you need to compile *and link* a program, but you haven't picked a linker yet. Andy, that's what I thought at first, and you may well be correct. However, as I read the code in the current HEAD of config/inter/progs.pm, the *only* variable passed to the internal test_compiler subroutine is $cc (line 130). $cc is assigned to much farther up inside the runstep() method (lines 61-62), and immediately thereafter assigned to the 'cc' argument in the Parrot::Configure object (line 63). All the other values you mention are assigned between lines 64 and 130, but, AFAICT, none of those assignments depend on either $cc or the value assigned to 'cc' inside the configuration object. The test_compiler() method, *as written*, does not appear to depend at all on any of the other values located on the system or selected at the prompt, and it does not appear to depend on the Parrot::Configure object. If so, then the refactoring I suggested is plausible. Of course, it may very well be that test_compiler() was misconceived all along and that it *should* have been passed the current state of the Parrot::Configure object ($conf). What do you think? kid51
Re: [perl #47902] [PATCH] Confine calls to Perl 5 %Config to init::defaults
Todd Olson via RT [EMAIL PROTECTED] on 2007/11/28 Wed AM 08:39:24 CST wrote: One feature I have been exploiting extensively in my Perl 5 installs is cpan.pm's MyConfig.pm which permits me to overlay Perl's %Config and to swap sets of config changes in and out with out messing with the base Perl 5 install. I find this to be a useful way of organizing experiments and changes. Does Parrot's Config architecture provide this capability? No, it does not. The 16 instances in which modules underneath config/ call 'use Config;' all refer to the Config.pm associated with the instance of Perl used in 'perl Configure.pl'. The problem arises in the fact that users can and may need to provide information to the configuration system via command-line options to Configure.pl or by interactivity at the prompt. This information can be different from the information supplied in %Config. This means that if I as the tester/maintainer write tests which rely too heavily on %Config, those tests will fail on systems where there is a discordance between %Config and user-supplied information. Another problem arises in the fact that %Config is consulted early in the configuration process for a value for a particular element in the Parrot::Configure object's data structure. That element's value may then be overwritten in subsequenct configuration steps by, for instance, C programs which probe the system. But still later in the configuration process, a step may call for once again consulting the *original* value supplied by %Config -- not the corresponding updated value inside the object. (Whether that's absolutely necessary I can't say. I'm proceeding on the assumption that the colleagues who wrote the config step classes in the first place knew what they were doing, so my job is to preserve the existing functionality and do no harm to it during refactoring.) While I can see the value of the approach you take for development and debugging purposes, I think it would probably be very difficult to implement in a test suite intended to be executed on many different platforms. But it may prove fruitful in the future. Thank you very much.
Hackathon in Chicago less than 3 weeks away
A wiki has been created for the Perl Hackathon in Chicago coming up Fri-Sun Dec 14-16 -- just a little over two weeks away. http://perlcast.com/hackchicago2007/index.cgi Are any Parrot developers besides my planning to attend? If so, please register and sign up on the wiki. Thank you very much. kid51
Getting Feedback from Smoke Testers
One of the test files I wrote for configuration step class auto::alignptrs, t/configure/124-auto_alignptrs-05.t, has been getting failure reports on one particular test -- but not on all platforms, and not on a platform I have access to. I would like to follow up with the folks running these smoke services, but the smoke report pages do not provide email addresses for the testers. Can anyone tell me how I would follow up with these two smokers -- or with our smokers more generally? 1. TAP Matrix - Fri Nov 9 13:09:31 2007 GMT duration: 1361 branch: unknown harness_args: -D40 --gc-debug DEVEL: -devel VERSION: 0.4.17 archname: x86_64-linux-gnu-thread-multi build_dir: /home/rick/build/parrot cc: cc cpuarch: amd64 optimize: osname: linux revision: 22778 2. TAP Matrix - Fri Nov 9 12:03:20 2007 GMT duration: 836 branch: unknown harness_args: -D40 --gc-debug DEVEL: -devel VERSION: 0.4.17 archname: i386-linux-thread-multi build_dir: /home/jurosz/PaP6-testing/parrot-temp cc: gcc cpuarch: i386 optimize: osname: linux revision: 22778 Thank you very much. kid51
Re: [perl #43463] [BUG] Parrot Bug Summary Requestors with most open tickets d
From: Will Coleda via RT [EMAIL PROTECTED] Date: 2007/07/02 Mon AM 08:28:11 CDT To: [EMAIL PROTECTED] Subject: [perl #43463] [BUG] Parrot Bug Summary Requestors with most open tickets doesn't DWIM Need to strip out the HTML comment !-- x -- on the link; the url for you is actually: http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Requestor[EMAIL PROTECTED] That works. Thanks!
Re: Re: [perl #41897] [BUG]: Parrot::Pmc2c::STMRef gets 'subroutine prederef re
From: Paul Johnson via RT [EMAIL PROTECTED] Date: 2007/05/01 Tue AM 06:15:38 CDT To: [EMAIL PROTECTED] Subject: Re: [perl #41897] [BUG]: Parrot::Pmc2c::STMRef gets 'subroutine prederef redefined' warning 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? No. So it's still on my TODO list. Thanks for looking into it. Jim Keenan
Testing What Was Printed
Using the standard Test::More framework, is it
possible to test whether what was printed to a
filehandle matches a predetermined string or list of
strings?
Consider the following:
use Test::More tests = 1;
is(get_data_count([1..39]), 39,
should be 39 items);
sub get_data_count {return @{+shift};}
This will print out:
1..1
ok 1 - should be 39 items
Now add one subroutine and one test to the foregoing:
use Test::More tests = 2;
is(get_data_count([1..39]), 39,
should be 39 items);
ok(print_data_count([1..39]),
print_data_count() printed successfully);
sub get_data_count {return @{+shift};}
sub print_data_count {
print 'Current data count: ' .
@{+shift} . \n;
}
This will print out:
1..2
ok 1 - should be 39 items
Current data count: 39
ok 2 - print_data_count() printed successfully
The comment on the second test is, however, somewhat
misleading. The test reports that *something* was
printed -- because the return value of 'print' was
true -- but it doesn't test *what* was printed. The
only *completely* meaningful test would be one that
captures the list of items printed by
print_data_count().
Another way of putting this: Could a Test::More
function 'didprint' be invented which would have an
interface like this?
didprint( (print_data_count([1..39]),
'Current data count: 39')
print_data_count() printed ideally);
I've Googled comp.lang.perl.misc and this list's
archive and have looked thru Perlmonks as well, but
haven't come up with a *simple* solution ('simple'
being defined as one that uses just Perl built-in
functions or modules distributed with 5.8 core).
Any suggestions? TIA.
Jim Keenan
=
Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: introduction
Comrade Burnout wrote: I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So hi and stuff. Re: Phalanx: If you're interested in working on this in an F2F manner (other hoplites in the same room!), sign up on the HereToHelp page of the Phalanx kwiki (http://phalanx.kwiki.org/index.cgi?HereToHelp) and indicate what city or metro area you live in. Or hook up with one of the local Perlmonger groups listed on the kwiki home page if you're in one of those areas. Jim Keenan
Re: Anomalous Difference in Output between HTML Files Created by
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. jimk
Anomalous Difference in Output between HTML Files Created by 'cover'
I have just noticed an anomalous difference in output between two of the
files created by the Devel::Cover 'cover' utility when run against a
popular Perl module -- and I am wondering whether this difference should
be considered a feature or a bug.
The module in question is Text::Template, which I am studying as part of
Perl Seminar NY's contribution to the Phalanx project. Start with a
copy of Text-Template-1.44 (the latest on CPAN) and examine the code.
In 'lib/Text/Template.pm', consider these two lines:
128$self-_acquire_data unless $self-{DATA_ACQUIRED};
450if (! defined $val) {
Proceed in the normal manner:
perl Makefile.PL
make
cover -delete
HARNESS_PERL_SWITCHES=-MDevel::Cover make test
cover
... 'cover' creates a number of HTML files, including these two:
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm.html
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm--branch.html
'blib-lib-Text-Template-pm.html' displays lines 128 and 450 exactly as
they appear in the module itself.
'blib-lib-Text-Template-pm--branch.html', however, displays the relevant
branch part of these lines of code as follows:
128 unless $$self{'DATA_ACQUIRED'}
450 if (not defined $val) { }
'$self-{DATA_ACQUIRED}' is changed to '$$self{'DATA_ACQUIRED'}' and '!
defined $val' is changed to 'not defined $val'. (I could site other
examples as well, but these suffice to illustrate the point.)
Now, I grant that these are merely displays, not live code.
Nonetheless, since the purpose of these HTML files is to guide a
programmer to lines of code whose test coverage needs improvement, I am
puzzled as to why the output in these two files differs.
Jim Keenan
Devel::Cover on Win32: Observations
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. 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. 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? 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. lib/AutoLoader.pm lib/B.pm lib/B/Debug.pm lib/B/Deparse.pm lib/Carp.pm lib/Carp/Heavy.pm lib/Config.pm lib/Cwd.pm lib/DynaLoader.pm lib/Exporter.pm lib/Exporter/Heavy.pm lib/Fcntl.pm lib/File/Basename.pm lib/File/Glob.pm lib/File/Path.pm lib/File/Spec/Unix.pm lib/File/Spec/Win32.pm lib/Storable.pm lib/Test/Builder.pm lib/Test/More.pm lib/XSLoader.pm lib/base.pm lib/blib.pm lib/overload.pm lib/re.pm lib/strict.pm lib/threads.pm lib/threads/shared.pm lib/vars.pm lib/warnings.pm lib/warnings/register.pm My hunch is that these are modules and pragmas called by Devel::Cover. Correct? But why do I get these in the printout from Devel::Cover on Windows but not on Darwin? Jim Keenan = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Differences between output of 'make test' and 'prove'
This is a report on differences between the output of
'make test' and 'prove' which are, well, different
from those reported by Stevan Little in a thread
beginning on Sept 4.
While teaching myself how to use 'prove' tonight, I
decided to try it out on a Perl core module which I
have also been using as a test case for my
understanding of Devel::Cover. The core module in
question is Time::Local, version 1.10. When I called
'make test' on this module, I got the following
results:
[Time-Local-1.10 562]$ make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl
-MExtUtils::Command::MM -e test_harness(0,
'blib/lib', 'blib/arch') t/*.t
t/Localok
All tests successful.
Running this with TEST_VERBOSE=1 indicated that the
number of tests run was 102.
However, when I called 'prove t', I got different
results:
[Time-Local-1.10 563]$ prove t
t/LocalCannot handle date (7, 14, 3, 19, 0,
2038) at t/Local.t line 105
t/Localdubious
Test returned status 255 (wstat 65280,
0xff00)
DIED. FAILED tests 101-102
Failed 2/102 tests, 98.04% okay
Failed Test Stat Wstat Total Fail Failed List of
Failed
---
t/Local.t255 65280 1024 3.92% 101-102
Failed 1/1 test scripts, 0.00% okay. 2/102 subtests
failed, 98.04% okay.
As best as I can tell, these are the tests in
t/Local.t which failed:
ok(sprintf('%x', timegm(gmtime(0x7fff))),
sprintf('%x', 0x7fff), # line 105
'0x7fff round trip through gmtime then
timegm');
ok(sprintf('%x', timelocal(localtime(0x7fff))),
sprintf('%x', 0x7fff),
'0x7fff round trip through localtime then
timelocal');
Any ideas?
Jim Keenan
=
Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers
__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
Re: Where is Devel::Cover installed?
[EMAIL PROTECTED] (Jeff Bisbee) wrote in message
news:[EMAIL PROTECTED]...
I have a handy script I keep in my ~/bin directory
called 'pmpath'
#!/usr/bin/perl
$module = shift;
($mod = $module) =~ s#::#/#g;
die (Need a module name\n) unless $mod;
$mod .= '.pm';
require $mod;
print $INC{$mod} . ( . ${$module .
::VERSION} . )\n;
[snip]
I also have another handy script called 'pmlocal'
#!/usr/bin/perl
use strict;
use warnings;
use File::Path qw(mkpath);
use File::Copy qw(copy);;
my $editor = $ENV{EDITOR} || 'vi';
my $module = shift;
die (Need a module name\n) unless $module;
$module =~ s#::#/#g;
$module .= '.pm';
require $module;
my ($path) = $module =~ /(.+)\//;
mkpath($path,1);
copy($INC{$module},$module);
exec($editor $module);
Jeff: Tried both out today. Simply substituting
Notepad for vi (am at work, on Win32), they worked
right out of the box! Thanks again.
Jim Keenan
=
Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers
__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
Phalanx Project and Core Modules
On this page at the Phalanx web site (http://qa.perl.org/phalanx/distros.html), it is stated, [the Phalanx 100] should NOT contain any modules that are part of core Perl. Those will be handled in a different phase of the project. Can you elaborate as to how the core modules will be handled? jimk = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
ninja
[EMAIL PROTECTED] (Thomas Klausner) wrote in message
news:[EMAIL PROTECTED]...
Hi!
On Fri, Jul 23, 2004 at 08:41:58AM +0200, James
Mastros wrote:
BTW, what's $report-{files}{ninja}?
see here:
http://use.perl.org/comments.pl?
Okay, I looked at that link, and the link to one of
acme's pages therein, and I still gotta wonder ...
How do I boost my (modules') ninja?
If I get my mojo working, will my ninja go up?
jimk
=
Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Fine-tuning output from Devel::Cover
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. 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. 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. So: Can Devel::Cover's 'cover' program be used to generate reports of uncovered statements/branches/conditions/only? Thank you very much. Jim Keenan = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: Fine-tuning output from Devel::Cover
--- Paul Johnson [EMAIL PROTECTED] wrote: 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. 'Enormous' is obviously a subjective judgment, so let me describe the coverage files I've got and how I worked with them. List::Compare currently consists of 4 .pm files. The 'File Coverage' HTML files for them total 328KB. If I printed them out in a normal size, I would get 57 pages. Depending on the zoom ratio in my browser, that would be equivalent to somewhere between 85 and 114 screens deep. When I utilize Devel::Cover's 'cover report=text' option, I get all the information contained in the 'File Coverage' HTML files plus the Branch, Condition and Subroutine Coverage files as well -- and that comes out to 312KB. Depending on whether I print that out in portrait or landscape mode from a text editor such as Apple TextEdit, that comes to 96 or 168 pages. When working on a project like this, I like to do two things: (1) print out my reference data so I can mark it up with the advanced technology known as ink, and (2) display it on my screen in a GUI text-editor while I revise the Perl code in a visually distinct program (in this case, vi). I don't to have to be constantly scrolling up and down in the GUI program to spot the uncovered code, nor do I want to have to leaf through 96 pages of hard copy. Hence, I want to get that text file edited down to display just what needs correction. Doing this manually or by a Perl script which parses the plain-text coverage report, I got it down to 7 pages of hard copy. That's much more workable. But it would obviously be much more efficient to extract this information from the cover_db database itself than from a report generated from that database. Should I find the time, I'll venture into Devel::Cover's internals and see what I can do. Thank you very much. jimk = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
