Re: getting round Test::More test formatting trickiness
On Tue, 14 Mar 2006, Smylers wrote:
> Dr Bean writes:
> > I've gotten comfortable with Test::More conventions, but it's
> > difficult in my editor to really quickly create lots of tests.
> > is($o->index('You'), 1, 'objects index 1');
> > isnt($o->index(1), 1, 'objects index 2');
> > isnt($o->index(2), 2, 'objects index 2');
> > is($o->index($t), 3, 'objects index 3');
> > Incrementing numbers and substituting words and letters takes
> > time
> If your editor happens to be Vim then be aware that Ctrl+A adds 1 to the
> number currently under the cursor, or the next number on the current
> line if the cursor isn't on a number.
Actually, I am using vim, and probably I used Ctrl+A to increment
the numbers here.
> And if there's a second number you wish to increment on the same line
> then simply press l to move to the right of the first number (which the
> cursor will have moved to on pressing Ctrl+A the first time) and then
> press Ctrl+A again.
That's what I actually do do to increment more than one number in
the same line. It's handy that you don't have to have the cursor
above the number you want to increment.
Vim actually has a nrformats option to allow you to increment
letters, like perl allows you to. The reason that I don't have
nrformats=alpha as my default is that it means I then have to
align the cursor with the number I want to increment.
But even using Ctrl+A my fingers can't keep up with where my
thoughts are and creating tests degenerates into mechanical
keypressing busywork.
You can see in my example above that 2 of the test labels are the
same. I probably yanked and put one of the lines, but didn't
finish fixing the test label.
Judging from the lack of meaningful labels on perl tests, it
appears most people probably have the same problem.
> If you're doing this a lot then you can use q to record a keyboard macro
> for processing one line and moving on to the next, then it's just a case
> of holding down the @ key to do as many lines as you want.
I guess if I knew what tests I was going to create beforehand and
there was a pattern I might do this, but so far I haven't seen
the pattern.
[I guess a macro to do something with the 3 parts of a subtest:
input, expected output, and label along the lines of the
vim bracketing macros might be worth thinking about.]
I'm probably going to try David Golden's foreach loop accessing
the input, expected output and label in a hash or array, at the
same time as I play with Test::Base and switch between them,
depending on how they go.
--
Dr Bean Vent the Pent.
--Samuel Beckett
parrotcode.org needs update (0.4.1 to 0.4.2)
Cheers Alberto
Upgrading core modules on Windows
Philippe M. Chiasson wrote: The main reason this is hapenning is that it's not currently possible to update CORE packages in ActivePerl, so any module that depends on a CORE package can be suffering from this. This problem will persist until it becomes possible to update core packages in ActivePerl. It's certainly not an ideal situation, but unless somebody can point out an easier solution, this is where we are at. I had one of those shower epiphanies this morning. While it's only a concept at this point, I thought I would put it to the group for more experienced minds to consider. As I understand from comments in http://use.perl.org/comments.pl?sid=30312 the big problem with upgrading core modules for Windows (ActiveState, VanillaPerl, etc.) is that Windows won't delete open files. Thus any core files (particularly *.dll files) in use by PPM/cpan.pm can't be replaced. So why not bundle a snapshot of all the module dependencies for PPM/cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm? That way, other than the core perl executable, the upgrade tools wouldn't be using any core modules directly -- only the ones bundled snapshot. If I understand correctly, that should allow core modules to be upgraded. There's still a bit of a bootstrap problem for upgrading PPM/cpan.pm themselves or any of their dependencies. However, even that might be avoided if the snapshot (including updates to PPM/cpan.pm) were updated/created on the fly by a batch file prior to executing PPM/cpan.pm. I'm sure moving to this approach would mean changes at various points in the toolchain -- particularly in how the PPM and cpan batch files operate -- but it would avoid more complicated approaches requiring changes in the Windows registry in order to finish upgrades during a reboot. Thoughts and feedback welcome. Regards, David Golden
Re: Upgrading core modules on Windows
On Mar 16, 2006, at 8:51 AM, David Golden wrote: ... So why not bundle a snapshot of all the module dependencies for PPM/ cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm? ... Makes sense to me. PAR would be a very valuable tool to implement this, although that would be a huge addition to the dependency list. With PAR, you could employ a whole separate .exe and probably even do the core updates. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Upgrading core modules on Windows
On Thu, Mar 16, 2006 at 09:53:28AM -0600, Chris Dolan wrote: > On Mar 16, 2006, at 8:51 AM, David Golden wrote: > > >... > >So why not bundle a snapshot of all the module dependencies for PPM/ > >cpan.pm into a separate directory and put that at the start of @INC > >when running PPM/cpan.pm? > >... > > Makes sense to me. PAR would be a very valuable tool to implement > this, although that would be a huge addition to the dependency list. > With PAR, you could employ a whole separate .exe and probably even do > the core updates. The ActiveState guys could use perlapp to create an .exe of ppm as well. perlapp is part of the Perl Dev Kit. Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
Re: Best Practice for testing compilation of scripts
Moin, On Thursday 16 March 2006 03:49, chromatic wrote: > On Wednesday 15 March 2006 18:43, Geoffrey Young wrote: > > I was suggesting the functionality be added to Test::More as > > compile_ok(), rather than runperl() in some separate CPAN module, as > > it seems to closely parallel use_ok() for modules and would be rather > > useful on a larger scale. > > That would require prying Schwern out from having fun to do actual > work! I feel a shaming coming on. > > SHAME > SHAME *Tels is using Shame on Michael Schwern* *Tels is using Guilt on Michael Schwern* Best wishes, Te"Oops, now you know I play GuildWars instead of getting work done"ls -- Signed on Thu Mar 16 18:00:18 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. STOP! We have run out of virgins! pgpE6IuU3VCme.pgp Description: PGP signature
[svn ci] (r11911) .None PMC now returns empty string instead of "None" for get_string
previously, the get_string method of the .None PMC returned "None". it's been modified to return the somewhat more sane "", or empty string. this may affect code using .Hash PMCs, as the get_string method of the .None PMC is called when the value of a non-existant hash key is requested in string context. for example: P0 = new .Hash S0 = P0['abc'] eq S0, '', OK print 'not ' OK: print 'ok' end ## prints 'ok' all affected tests and library files have been modified. ~jerry
Patches to hide old test reports if update exists
Leon,
Attached are patches against CPAN::WWW::Testers::Generator and
CPAN::WWW::Testers for hiding test reports for which the tester submits
an updated report.
The missing element to implement this feature was the email address of
the tester. Since that does not currently exist in testers.db, the
hiding feature will not affect existing reports. In the future, if a
report is added to the DB and then later followed by another with all
the same matching criteria (i.e., distribution + version, Perl version,
OS name + version, architecture name, and tester's email address), the
older report(s) will not show up on the 'show' pages generated by
CPAN::WWW::Testers (i.e., http://cpantesters.perl.org/).
Here is an explanation of the changes:
* CPAN::WWW::Testers::Generator::Article.pm
- Adds a new accessor called 'tester' to the article object.
- Extracts the 'From' field from a test report and adds it to the
'tester' field.
* CPAN::WWW::Testers::Generator.pm
- Adds a new column 'tester' to the 'CREATE TABLE reports' command.
- For existing databases, alters the 'reports' table to add the 'tester'
column. The DB is then 'VACUUM'ed which only takes a couple of minutes.
As with CREATE TABLE, this is a one-time only operation.
- The 'tester' field from the 'article' object is stored in the new
'tester' field.
* CPAN::WWW::Testers
- The new 'tester' column is also retrieved for each report.
- Reports are extracted in descending ID order so that updates are
encountered first.
- If all fields for uniqueness are present ($version, $perl, $osname,
$osvers, $archname, $tester), then the report is skipped if
exists($unique{$version}{$perl}{$osname}{$osvers}{$archname}{$tester}).
Otherwise,
$unique{$version}{$perl}{$osname}{$osvers}{$archname}{$tester} is set
to the report ID (arbitrary).
- The report order is reversed (i.e., lowest ID to highest) by changing
"push @reports, $report" to "unshift @reports, $report".
Entries have been added to the CHANGES files for both modules, and
version numbers have been incremented.
Thank you,
Jerry D. Hedden
diff -ur CPAN-WWW-Testers-0.29/CHANGES CPAN-WWW-Testers-0.30/CHANGES
--- CPAN-WWW-Testers-0.29/CHANGES 2006-01-31 05:11:04.0 -0500
+++ CPAN-WWW-Testers-0.30/CHANGES 2006-03-16 12:44:58.0 -0500
@@ -1,5 +1,8 @@
Revision history for Perl module CPAN::WWW::Testers.
+0.30 Thu Mar 16 12:45:00 EST 2006
+ - Suppress older reports when an updated exists
+
0.29 Tue Jan 31 10:03:37 GMT 2006
- update the URL we download the database from
diff -ur CPAN-WWW-Testers-0.29/lib/CPAN/WWW/Testers.pm
CPAN-WWW-Testers-0.30/lib/CPAN/WWW/Testers.pm
--- CPAN-WWW-Testers-0.29/lib/CPAN/WWW/Testers.pm 2006-01-31
05:11:04.0 -0500
+++ CPAN-WWW-Testers-0.30/lib/CPAN/WWW/Testers.pm 2006-03-16
12:45:40.0 -0500
@@ -16,7 +16,7 @@
use version;
use base qw(Class::Accessor::Chained::Fast);
__PACKAGE__->mk_accessors(qw(directory database dbh tt last_id backpan));
-$VERSION = "0.29";
+$VERSION = '0.30';
sub generate {
my $self = shift;
@@ -287,16 +287,21 @@
next unless $distribution =~ /^[A-Za-z0-9][A-Za-z0-9-_]+$/;
my $action_sth = $dbh->prepare("
-SELECT id, status, version, perl, osname, osvers, archname FROM reports
-WHERE distribution = ? order by id
+SELECT id, status, version, perl, osname, osvers, archname, tester FROM
reports
+WHERE distribution = ? order by id desc
");
$action_sth->execute($distribution);
-my ($id, $status, $version, $perl, $osname, $osvers, $archname);
+my ($id, $status, $version, $perl, $osname, $osvers, $archname, $tester);
$action_sth->bind_columns(\$id, \$status, \$version, \$perl, \$osname,
- \$osvers, \$archname);
-my @reports;
+ \$osvers, \$archname, \$tester);
+my (@reports, %unique);
while ($action_sth->fetch) {
next unless $version;
+ # Suppress older reports if an update exists
+ if ($perl && $osname && $osvers && $archname && $tester) {
+ next if
exists($unique{$version}{$perl}{$osname}{$osvers}{$archname}{$tester});
+ $unique{$version}{$perl}{$osname}{$osvers}{$archname}{$tester} = $id;
+ }
my $report = {
id => $id,
distribution => $distribution,
@@ -308,7 +313,7 @@
archname => $archname,
url => "http://nntp.x.perl.org/group/perl.cpan.testers/$id";,
};
- push @reports, $report;
+ unshift @reports, $report;
}
my ($summary, $byversion);
diff -ur CPAN-WWW-Testers-Generator-0.22/CHANGES
CPAN-WWW-Testers-Generator-0.23/CHANGES
--- CPAN-WWW-Testers-Generator-0.22/CHANGES 2006-03-16 12:48:02.0
-0500
+++ CPAN-WWW-Testers-Generator-0.23/CHANGES 2006-03-16 12:47:58.0
-0500
@@ -1,5 +1,8 @@
Revision history for Perl module CPAN::WWW::Testers::Generator.
+0.23 Thu Mar 16 12:45:00 EST 2006
+ - Added 'tester' column to 'reports' table
+
0.22 Thu Feb 3 15:27:41 GMT 2005
- now
Re: What is the Value of t/0-signature.t?
On Friday 10 March 2006 02:38, Audrey Tang wrote: > I think it should be like the standard Test::Pod's pod.t and only run > when an env var is set to true. > > Patches... welcome to Module::Signature. :-) Do you mean that it's valuable only for the author to run (perhaps during disttest) and rarely useful for the user to run during installation? -- c
Apache::Test <-> cpan.testers weirdness
I just got some cpan testers reports on a new module, CGI::JSONRPC. 1 pass, 2 failures. One of the failures seems to be my fault, but the other one seems really odd: http://www.nntp.perl.org/group/perl.cpan.testers/298838 The odd part is here: [ERROR] [Wed Mar 15 10:06:14 2006] MAKE TEST failed: No such file or directory PERL_DL_NONLAZY=1 /usr/local/perl-5.8.5/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/Apache2-JSONRPC[ error] STDIN is not attached to tty, skip interactive config [ error] Skipping the test suite execution, while returning success status # No tests run! dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-6 Failed 6/6 tests, 0.00% okay In the same breath it looks like the Apache::Test suite both says that it's going to return success, and returns a failure code. The really odd thing is that this only happens in Apache2-JSONRPC.t: http://search.cpan.org/src/CRAKRJACK/CGI-JSONRPC-0.01/t/Apache2-JSONRPC.t While CGI-JSONRPC.t skips its tests as well, and returns a correct result code: http://search.cpan.org/src/CRAKRJACK/CGI-JSONRPC-0.01/t/CGI-JSONRPC.t Does anybody know what's happening here? Thanks, Tyler
Re: Upgrading core modules on Windows
On 3/16/06, David Golden <[EMAIL PROTECTED]> wrote: > Philippe M. Chiasson wrote: > > The main reason this is hapenning is that it's not currently possible to > > update > > CORE packages in ActivePerl, so any module that depends on a CORE package > > can > > be suffering from this. This problem will persist until it becomes possible > > to > > update core packages in ActivePerl. > > > > It's certainly not an ideal situation, but unless somebody can point out an > > easier solution, this is where we are at. > > I had one of those shower epiphanies this morning. While it's only a > concept at this point, I thought I would put it to the group for more > experienced minds to consider. > > As I understand from comments in > http://use.perl.org/comments.pl?sid=30312 the big problem with upgrading > core modules for Windows (ActiveState, VanillaPerl, etc.) is that > Windows won't delete open files. Thus any core files (particularly *.dll > files) in use by PPM/cpan.pm can't be replaced. > > So why not bundle a snapshot of all the module dependencies for > PPM/cpan.pm into a separate directory and put that at the start of @INC > when running PPM/cpan.pm? > > That way, other than the core perl executable, the upgrade tools > wouldn't be using any core modules directly -- only the ones bundled > snapshot. If I understand correctly, that should allow core modules to > be upgraded. > > There's still a bit of a bootstrap problem for upgrading PPM/cpan.pm > themselves or any of their dependencies. However, even that might be > avoided if the snapshot (including updates to PPM/cpan.pm) were > updated/created on the fly by a batch file prior to executing PPM/cpan.pm. > > I'm sure moving to this approach would mean changes at various points in > the toolchain -- particularly in how the PPM and cpan batch files > operate -- but it would avoid more complicated approaches requiring > changes in the Windows registry in order to finish upgrades during a reboot. > > Thoughts and feedback welcome. Im not sure if you realized, but you can install YVES/ex-ExtUtils-Install-1.3701.tar.gz and assuming you have Win32API::File installed this stuff will be handled properly. This package is a proposed split off of the installation code in the ExtUtils::MakeMaker bundle. We are waiting on Schwern to respond And while your suggestion probably would work I don't it would resolve all the issues. For instance perhaps you want to upgrade files that are locked because of other reasons beside the installer having them open. For instance you might want to upgrade the .dlls used by a long running perl. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Combining :slurpy and :optional
This is a message primarily for Chip -- Question: As a possibly useful optimization, can we declare that :slurpy parameters can also be :optional, as in...? .param pmc argv :slurpy :optional .param int has_argv :opt_flag .param pmc modifiers :slurpy :named :optional .param int has_modifiers :opt_flag Rationale: Normally one would just use :slurpy, and if there aren't any "extra" arguments then the slurpy array or hash would simply be constructed as an empty container or hash. That's great. But many times the call profile is likely to be such that extra arguments to the sub are a rarity instead of the norm, and in these cases it may be worth avoiding the overhead of creating an empty array or hash that isn't likely to get used. This is the case with PGE, where subrules need to be able to receive modifiers and pass modifiers to other subrules. (The :keepall modifier is probably the most obvious example, but there are others.) Since we don't know in advance all of the modifiers that might possibly be sent to a given rule subroutine, the sub needs to be able to accept whatever it gets -- i.e., :slurpy. But, since the majority of actual subrule calls won't involve any extra parameters, creating the empty :slurpy array for each call seems like a lot of unneeded overhead. Thus, perhaps we could use the :optional flag on :slurpy params to say "don't create the container pmc if no parameters arrive here". I recognize this may be a premature optimization, and there's certainly no problem with PGE being able to work without :slurpy :optional. (We'll just create the empty arrays and hashes for now.) But I did want to bring up the possibility so you could fold it into any other plans or designs you might have. Thanks, Pm
Re: Upgrading core modules on Windows
The only problem with this is that it only deals with CPAN.pm itself. The problem with locked files is wider than this. Imagine for example that you have Windows mod_perl or some other long-running program holding a lock on the modules. I had a similar idea last week, where maybe we could have CPAN.pm's module loader copy the files into a temp directory and load those ones. But unfortunately I think that isn't a good long term solution. Assuming we can reach the point where Win32 Perl (with CPAN.pm) is much much more common, we will end up with services and other things, and dealing just with CPAN.pm's own file locks aren't quite enough. The new ExtUtils::Install does really do the right thing though, and Win32 Perl is much more upgradable that any others, most 5.005 installations are in places like Irix these days. So I'd like to see where we get to once the new ExtUtils::Install is out and we can install properly, and then if there are still problems after that, we take the next step. Adam K David Golden wrote: Philippe M. Chiasson wrote: The main reason this is hapenning is that it's not currently possible to update CORE packages in ActivePerl, so any module that depends on a CORE package can be suffering from this. This problem will persist until it becomes possible to update core packages in ActivePerl. It's certainly not an ideal situation, but unless somebody can point out an easier solution, this is where we are at. I had one of those shower epiphanies this morning. While it's only a concept at this point, I thought I would put it to the group for more experienced minds to consider. As I understand from comments in http://use.perl.org/comments.pl?sid=30312 the big problem with upgrading core modules for Windows (ActiveState, VanillaPerl, etc.) is that Windows won't delete open files. Thus any core files (particularly *.dll files) in use by PPM/cpan.pm can't be replaced. So why not bundle a snapshot of all the module dependencies for PPM/cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm? That way, other than the core perl executable, the upgrade tools wouldn't be using any core modules directly -- only the ones bundled snapshot. If I understand correctly, that should allow core modules to be upgraded. There's still a bit of a bootstrap problem for upgrading PPM/cpan.pm themselves or any of their dependencies. However, even that might be avoided if the snapshot (including updates to PPM/cpan.pm) were updated/created on the fly by a batch file prior to executing PPM/cpan.pm. I'm sure moving to this approach would mean changes at various points in the toolchain -- particularly in how the PPM and cpan batch files operate -- but it would avoid more complicated approaches requiring changes in the Windows registry in order to finish upgrades during a reboot. Thoughts and feedback welcome. Regards, David Golden
[svn:parrot-pdd] r11913 - trunk/docs/pdds
Author: pmichaud
Date: Thu Mar 16 12:07:03 2006
New Revision: 11913
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
Changed ".slurpy" to ":slurpy".
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod Thu Mar 16 12:07:03 2006
@@ -337,7 +337,7 @@
=head2 Paramters
.param int i# positional parameter
- .param pmc argv .slurpy # slurpy array
+ .param pmc argv :slurpy # slurpy array
.param pmc qu :named('q') # named parameter
.param int x :optional # optional parameter
.param int has_x :opt_flag # flag 0/1 x was passed
Re: Upgrading core modules on Windows
Im not sure if you realized, but you can install YVES/ex-ExtUtils-Install-1.3701.tar.gz and assuming you have Win32API::File installed this stuff will be handled properly. This package is a proposed split off of the installation code in the ExtUtils::MakeMaker bundle. We are waiting on Schwern to respond I managed to get through to him finally yesterday, and he's said he'll be working on it shortly, he hasn't been paying much attention to P5P lately. Adam K
Re: Upgrading core modules on Windows
Adam Kennedy wrote: The only problem with this is that it only deals with CPAN.pm itself. The problem with locked files is wider than this. Imagine for example that you have Windows mod_perl or some other long-running program holding a lock on the modules. I realized that complication, but plenty of Windows installers already warn you to close all open programs before upgrading. That's not an unrealistic expectation for users on Windows. So I'd like to see where we get to once the new ExtUtils::Install is out and we can install properly, and then if there are still problems after that, we take the next step. That's good news. I hope the Schwern bottleneck clearly up soon. Regards, David Golden
Re: Best Practice for testing compilation of scripts
I just found http://search.cpan.org/dist/Test-Strict, which was written by one of my co-workers. Among other cool things, it has a C function which does the same thing. It still uses backticks and redirection which may not be too portable, but it will suit my needs. Still, a C function seems like a sensible addition to the Test::More package. Thanks for the feedback everyone. -Jeff --- Geoffrey Young <[EMAIL PROTECTED]> wrote: > > >>> I've long intended to take t/test.pl from the > Perl core distribution > >>> and wrap > >>> up at least its runperl() in a Test:: module. > Perhaps that would > >>> work for > >>> you? > >> > >> > >> compile_ok() ? > >> > >> --Geoff > >> > > > > It is unclear from Geoff's message above whether > he is asserting that > > function exists, or if he is merely proposing it > > yeah, sorry, it's been a long couple of days... > > I was suggesting the functionality be added to > Test::More as compile_ok(), > rather than runperl() in some separate CPAN module, > as it seems to closely > parallel use_ok() for modules and would be rather > useful on a larger scale. > > fwiw > > --Geoff > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
