[RFC] New TL;DR Essay: What you should know about automated testing
Hi all! I started writing this essay and could use some commentary: https://github.com/shlomif/what-you-should-know-about-automated-testing It is CC0, and aims to be kept as short as possible and free of fluff, and to be useful for motivation. Please let me know what you think. Regards, Shlomi -- - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/Can-I-SCO-Now/ - “Can I SCO Now?” Chuck Norris’ E-mails are signed with “Sent using Chuck Norris’ brain (which he can also kill you using it).”. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Test2/Test::Builder release plan
Hi all, On Sat, 26 Mar 2016 02:57:38 + Randy Stauner <rwstau...@cpan.org> wrote: > As a maintainer of one of the problem modules (Test::Aggregate) i should > have something to say, but I haven't been able to spend more than an hour > with Perl in the last year so i don't know when I'll be able to work on > making it work with the changes. I see no reason to hold up progress on > this any longer, so "sounds good" to me. > I may be willing to do some work on Test-Aggregate for that. Otherwise, my use of Test::More and Test::Builder is probably contained only to the very high-level API , so I don't expect anything major to break, so "sounds good" to me as well. Regards, Shlomi Fish -- ----- Shlomi Fish http://www.shlomifish.org/ List of Portability Libraries - http://shlom.in/port-libs The C Preprocessor - There’s not supposed to be a way to do it. — http://www.shlomifish.org/humour/ways_to_do_it.html Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: hackathon web page displays strangely
Hi James, On Sat, 21 Mar 2015 08:51:42 -0400 James E Keenan jk...@verizon.net wrote: http://act.qa-hackathon.org/qa2015/main In Firefox, at least, all the pages on this site are displaying in a strange way. Each page has a left sidebar with internal links and a right sidebar with sponsors. But the main content for each page only starts to appear *below* the end of the longer of the two sidebars. Unless and until you scroll down past the sidebars, each page appears void of content. This appears to happen if and only if the browser's viewport window is too narrow. If I make it wide enough, the page displays fine. For what it's worth, I can reproduce a similar behaviour in the Google Chromium browser. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Humanity - Parody of Modern Life - http://shlom.in/humanity The more money Chuck Norris comes across, the less problems he sees. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
[ANN] Test-Data-Split - split data-driven tests into several test scripts.
Hi all,
I am proud to announce Test-Data-Split:
* https://metacpan.org/release/Test-Data-Split
* https://github.com/shlomif/perl-Test-Data-Split
This is a small Perl module that allows one to automatically generate test
files based on data, that can later be run individually or parallelised using
prove -j$N .
Here's an example. Given this generator file:
CODE
#!/usr/bin/perl
use strict;
use warnings;
use autodie;
use FindBin;
use lib $FindBin::Bin/../t/t/lib;
use Test::Data::Split;
use FC_Solve::Test::Valgrind;
Test::Data::Split-new(
{
target_dir = 't',
filename_cb = sub {
my ($self, $args) = @_;
return valgrind--$args-{id}.t;
},
contents_cb = sub {
my ($self, $args) = @_;
my $id_quoted = quotemeta($args-{id});
return EOF;
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests = 1;
use FC_Solve::Test::Valgrind;
# TEST
FC_Solve::Test::Valgrind-new-run_valgrind_id_test({ id = qq/$id_quoted/, });
EOF
},
data_obj = FC_Solve::Test::Valgrind-new,
}
)-run;
/ CODE
And a FC_Solve::Test::Valgrind module like this one:
CODE
package FC_Solve::Test::Valgrind;
use strict;
use warnings;
use parent 'Test::Data::Split::Backend::Hash';
use Test::More ();
use Carp ();
use File::Spec ();
use File::Temp qw( tempdir );
my %valgrind_tests =
(
'dbm_fc_solver_1' =
{
prog = dbm_fc_solver,
argv =
[
'--offload-dir-path', {type = 'tempdir', },
{ type = 'catfile',
args = [{ type = 'ENV', arg = 'FCS_SRC_PATH'},
't', 't', 'data',
'sample-boards', '2freecells-24-mid-with-colons.board'
],
}
],
blurb = qq{dbm_fc_solver from 24-mid-with-colons.},
},
[snipped]
);
sub get_hash
{
return \%valgrind_tests;
}
[snipped]
sub run_valgrind_id_test
{
local $Test::Builder::Level = $Test::Builder::Level + 1;
my ($self, $args) = @_;
my $id = $args-{id};
return _test_using_valgrind($id, $self-lookup_data($id))
}
/ CODE
Then I get individual test scripts like:
CODE
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests = 1;
use FC_Solve::Test::Valgrind;
# TEST
FC_Solve::Test::Valgrind-new-run_valgrind_id_test({ id =
qq/board_gen__aisleriot__t_only/, });
/CODE
CODE
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests = 1;
use FC_Solve::Test::Valgrind;
# TEST
FC_Solve::Test::Valgrind-new-run_valgrind_id_test({ id =
qq/dbm_fc_solver_1/, });
/CODE
Etc.
=
Some plans for the future are:
1. Code several different backends: DBI/SQL, BDB/Google LevelDB , etc.
2. Allow a way to aggregate several IDs into an individual script.
3. Perhaps create an ::Easy interface with more magic.
Comments are welcome. Enjoy and Shabbath Shalom.
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
Understand what Open Source is - http://shlom.in/oss-fs
Chuck Norris can only convince you that you're deceased. Summer Glau can
also convince you that you're alive, which is much harder.
— http://www.shlomifish.org/humour/bits/facts/Summer-Glau/
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Final TPF Devel::Cover grant report
On Tue, 7 Oct 2014 22:42:41 +0100 Paul Johnson p...@pjcj.net wrote: In accordance with the terms of my grant from TPF this is the final report for my work on improving Devel::Cover. Since the last report I have released versions 1.16 and 1.17. Thanks for all your work, Paul! Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Parody of The Fountainhead - http://shlom.in/towtf When Chuck Norris orders Pizza, it arrives before he presses the OK button. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: TPF Devel::Cover grant report April 2014
Hi Paul, thank you a lot for your work. Regards, Shlomi Fish On Tue, 20 May 2014 22:50:35 +0100 Paul Johnson p...@pjcj.net wrote: In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering April 2014. This month I released versions 1.10, 1.11, 1.12 and 1.13. -- - Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/ I invented the term Object‐Oriented, and I can tell you I did not have C++ in mind. — Alan Kay (Attributed) Please reply to list if it's a mailing list post - http://shlom.in/reply .
New version of libtap - libtap-1.2.1
Hi all! libtap version 1.2.1 is now available from its homepage: http://www.shlomifish.org/open-source/projects/libtap/ libtap is a C library to emit TAP (= the Test Anything Protocol) which allows writing test programs in C that can be tested using a TAP harness. libtap was originally created by Nik Clayton, but it was neglected for a long time, and eventually I decided to adopt it. Some changes were incorporated from the libtap version of CCAN (= the Comprehensive C Archive Network). In libtap-1.2.1, I made the conversion of its build system from GNU Autotools to CMake (see http://www.shlomifish.org/open-source/anti/autohell/ for the motivation), and am also now generating and installing a pkg-config file - https://en.wikipedia.org/wiki/Pkg-config . The announcement of libtap-1.2.1 should hit http://freecode.com/ soon. Enjoy! Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Star Trek: We, the Living Dead - http://shlom.in/st-wtld When Chuck Norris uses Gentoo, “emerge kde” finishes in under a minute. A computer cannot afford to keep Chuck waiting for too long. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
On Fri, 29 Nov 2013 01:11:23 -0800 (PST) Ovid curtis_ovid_...@yahoo.com wrote: Hi Shlomi, My definitive answer would be to say work with Leon on this :) He's taken over maintenance on TAP::Harness. I haven't looked at that section of the code in quite some time and honestly, I don't have the time/energy to do so right now. Best, Ovid OK, thanks for the reply and the clarification. I will work with Leon on it. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Funny Anti-Terrorism Story - http://shlom.in/enemy Su-Shee Absolutely. Also: a German dog barks “wau” and a cat meows “miau” rindolf Su-Shee: German animals are true German patriots. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
Hi all, On Fri, 20 Sep 2013 21:29:02 +0300 Shlomi Fish shlo...@shlomifish.org wrote: Hi Ovid, On Sat, 7 Sep 2013 14:16:08 -0700 (PDT) Ovid curtis_ovid_...@yahoo.com wrote: Here's a complete example of a TAP::Harness plugin to create a red/green progress bar. http://blogs.perl.org/users/ovid/2010/05/making-testharness-output-a-progress-bar.html I read that post and have one question: can I easily create several specialised plugins and have them all apply their modified behaviours to the relevant part of TAP::Harness? Seems like I can only set up a single subclass of the relevant parts in each plugin (like for the formatter or whatever). Or am I missing something? I'm asking because with Test::Run, I can set up more than one plugin for each class and I'm wondering how to do that with TAP::Harness. Can anyone please answer that question? Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Escape from GNU Autohell - http://www.shlomifish.org/open-source/anti/autohell/ I’d do Windows-- , but this may result in an integer underflow. — an Israeli Linuxer. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
Hi all, can someone (Ovid?) please reply to this post I wrote? I really would like to know. Regards, Shlomi Fish On Fri, 20 Sep 2013 21:29:02 +0300 Shlomi Fish shlo...@shlomifish.org wrote: Hi Ovid, On Sat, 7 Sep 2013 14:16:08 -0700 (PDT) Ovid curtis_ovid_...@yahoo.com wrote: Here's a complete example of a TAP::Harness plugin to create a red/green progress bar. http://blogs.perl.org/users/ovid/2010/05/making-testharness-output-a-progress-bar.html I read that post and have one question: can I easily create several specialised plugins and have them all apply their modified behaviours to the relevant part of TAP::Harness? Seems like I can only set up a single subclass of the relevant parts in each plugin (like for the formatter or whatever). Or am I missing something? I'm asking because with Test::Run, I can set up more than one plugin for each class and I'm wondering how to do that with TAP::Harness. Regards, Shlomi Fish Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/ -- - Shlomi Fish http://www.shlomifish.org/ Selina Mandrake - The Slayer (Buffy parody) - http://shlom.in/selina Larry Wall has been changing the world. By modifying its very source code. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
Hi Ovid, On Sat, 7 Sep 2013 14:16:08 -0700 (PDT) Ovid curtis_ovid_...@yahoo.com wrote: Here's a complete example of a TAP::Harness plugin to create a red/green progress bar. http://blogs.perl.org/users/ovid/2010/05/making-testharness-output-a-progress-bar.html I read that post and have one question: can I easily create several specialised plugins and have them all apply their modified behaviours to the relevant part of TAP::Harness? Seems like I can only set up a single subclass of the relevant parts in each plugin (like for the formatter or whatever). Or am I missing something? I'm asking because with Test::Run, I can set up more than one plugin for each class and I'm wondering how to do that with TAP::Harness. Regards, Shlomi Fish Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/ -- - Shlomi Fish http://www.shlomifish.org/ Freecell Solver - http://fc-solve.shlomifish.org/ If his programming is anything like his philosophising, he would find ten imaginary bugs in the “Hello World” program. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
Hi Ovid, On Sat, 7 Sep 2013 14:16:08 -0700 (PDT) Ovid curtis_ovid_...@yahoo.com wrote: Here's a complete example of a TAP::Harness plugin to create a red/green progress bar. http://blogs.perl.org/users/ovid/2010/05/making-testharness-output-a-progress-bar.html Thanks! I'll take a look. Regards, Shlomi Fish Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/ From: Shlomi Fish shlo...@shlomifish.org To: perl-qa@perl.org Sent: Friday, 6 September 2013, 17:16 Subject: How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness Hi all, I'd like to know what is the best way to create a plugin for https://metacpan.org/module/TAP::Harness which will behave similarly to https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames . I found out that the runtests method can accept aliases to be displayed instead of the filename itself using an arrayref of [ $test, $alias ], so I can simply wrap runtests() in a subclass, process the arguments, and call next::method with the modified arguments. However, I still don't know how to write a plugin like that exactly (and how to get prove to recognise it). This section - https://metacpan.org/module/TAP::Harness#WRITING-PLUGINS - explains a bit about how to do that with some hand-waving, but does not show any complete top-to-bottom example, and I could not find anything with a metacpan search. My motivation for doing this is to port the rest of the functionality I miss in Test::Run (which failed to gain mainstream acceptance, and few people aside from me are using it) into TAP::Harness. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Selina Mandrake - The Slayer (Buffy parody) - http://shlom.in/selina bzr is slower than Subversion in combination with Sourceforge. — Sjors, http://dazjorz.com/ Please reply to list if it's a mailing list post - http://shlom.in/reply . -- - Shlomi Fish http://www.shlomifish.org/ Interview with Ben Collins-Sussman - http://shlom.in/sussman Daniel: Yeah, those guys [= NSA] don’t publish… Andrew: They perish, man. — http://www.shlomifish.org/humour/Summerschool-at-the-NSA/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
How to Port https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames to TAP::Harness
Hi all, I'd like to know what is the best way to create a plugin for https://metacpan.org/module/TAP::Harness which will behave similarly to https://metacpan.org/module/Test::Run::Plugin::TrimDisplayedFilenames . I found out that the runtests method can accept aliases to be displayed instead of the filename itself using an arrayref of [ $test, $alias ], so I can simply wrap runtests() in a subclass, process the arguments, and call next::method with the modified arguments. However, I still don't know how to write a plugin like that exactly (and how to get prove to recognise it). This section - https://metacpan.org/module/TAP::Harness#WRITING-PLUGINS - explains a bit about how to do that with some hand-waving, but does not show any complete top-to-bottom example, and I could not find anything with a metacpan search. My motivation for doing this is to port the rest of the functionality I miss in Test::Run (which failed to gain mainstream acceptance, and few people aside from me are using it) into TAP::Harness. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Selina Mandrake - The Slayer (Buffy parody) - http://shlom.in/selina bzr is slower than Subversion in combination with Sourceforge. — Sjors, http://dazjorz.com/ Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: QA for Perl
Hi Tracy, On Wed, 31 Jul 2013 15:29:18 + Tracy Radel tracy.ra...@shinemed.com wrote: Hello, I'm looking for information on quality assurance documentation for basic Perl. I am trying to do QA on a Perl script that we wrote, but before I can do this I need to do QA on the install of Perl. I've been searching for hours online and cannot find QA or VV documents for Perl. Do any of you know where I might find this documentation, if it exists? If not, do you know how other companies have dealt with QA for the installation of Perl? The perl core (= the Perl 5 implementation) contains a comprehensive test suite, that contains over half-a-million ( 500,000) test assertions for testing perl on the host system. To run it, build perl and type make test. I'm not sure what's the easy way to run it on a perl binary that was already installed to the system, but it should be doable. Make sure you run the test suite of the version that corresponds to the version of perl that you installed. Hope it helps. Regards, Shlomi Fish Thanks, Tracy Radel Nuclear Engineer SHINE Medical Technologies tracy.ra...@shinemed.com -- - Shlomi Fish http://www.shlomifish.org/ Selina Mandrake - The Slayer (Buffy parody) - http://shlom.in/selina I feel much better, now that I’ve given up hope. — Ashleigh Brilliant Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [ESSAY] “Writing tests, motherfucker!”
Hi Jeffrey, On Tue, 29 Jan 2013 16:36:54 -0800 Jeffrey Ryan Thalhammer j...@imaginative-software.com wrote: On Jan 26, 2013, at 1:13 AM, Shlomi Fish wrote: However, now I feel that trying to philosophise about the distinction between all those is not so useful for the people who are actually trying to write the tests. +1000 :-) I once had fervent debates with colleagues about whether something was a unit test or integration test or acceptance test. I always felt the distinction was pointless, but now I understand why it happened. Unit tests were regarded as the developer's realm. Integration tests are the build engineer's responsibility. And acceptance tests might belong to QA. So labeling tests serves as a means for allocating work (and blame). Fortunately, I've seen more and more organizations dismantle their QA teams completely. Quality is everyone's responsibility. Well, I feel that having some testers who try to break the software is useful for programs which have a GUI, a web UI, etc. They don't need to be coders per-ce, but should be clueful to try various things. I am always frustrated that various web UIs don't behave exactly like I want, and I feel that contacting the web-site owner will yield nothing. (Google, I am looking at you). As someone who is obsessed with even the smallest usability details on http://www.shlomifish.org/ and other sites, I feel that the standard “You have a problem with a site, and I agree with you that it's a problem, but I'm not going to make it a high priority to fix it, so f**k you!” (as opposed to what Joel on Software said here - http://www.joelonsoftware.com/articles/customerservice.html . Now, somebody, just write the damn test :) Agreed. :-). -Jeff Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/ My Commodore 64 is suffering from slowness and insufficiency of memory, and its display device is grievously short of pixels. Can anybody help? — Omer Zak Please reply to list if it's a mailing list post - http://shlom.in/reply .
[ESSAY] “Writing tests, motherfucker!”
Hi all,
I hope the *.perl.org filters won't give troubles to my title and content, but
I've done it as a tribute to http://programming-motherfucker.com/ , which I
recommend going over, being the anti-methodology/NoMethodology (but in part
apparently written tongue-in-cheek), and which isn't too long a read, and also
hosts the useful http://programming-motherfucker.com/become.html list of
resources for learning.
So why am I writing this? I used to feel guilty about not being conscious of
the distinction between the various scopes of tests, like unit tests vs.
integration tests vs. system tests vs. functional tests etc. when I wrote the
tests. I just noticed that I need a test here (as a regression test for a bug,
or to TDD a new feature, or after implementing a new feature, etc.), and wrote
it using Test::More or whatever. However, now I feel that trying to
philosophise about the distinction between all those is not so useful for the
people who are actually trying to write the tests.
“Tests are good, mmkay? Just freaking write them!”
chromatic has expressed some sentiments against the so-called “Behaviour Driven
Development” (BDD) Domain-specific-languages (DSLs) such as cucumber here:
http://modernperlbooks.com/mt/2012/04/what-testing-dsls-get-wrong.html
One thing he says in a comment there is:
Our clients are the parents, guardians, and teachers of children between the
ages of eight and twelve inclusive.
The intent of Cucumber is to make readable testcases, just as the intent of
COBOL and AppleScript and visual component programming is to enable
non-programmers to create software without having to learn how to program.
Not only is it impossible to have people who are non-programmers write
structure code without learning how to program (at least until we get
sufficiently intelligent Sci-Fi-like AI that will be able to perform
programming like humans do), I feel that you need to write some kind of code,
however formatted, to write tests, just like HTML and CSS and spreadsheet
programs, involve writing some kind of *code*.
If you want to have your clients write tests, my best suggestion is to other
instruct them in the proper methodology and discipline of coding, or
alternatively have them show you how to reproduce the problem (using
screenshots, screencasts, shared remote desktop sessions, etc.) and then *you*
write a test for it.[Note]
{{{
[Note] - some people fear that teaching laymen how to code will create
competition for professional programmers, and dilute the profession. However,
this is not true, because there's always a difference between a casual dealer
in a craftsmanship or art, and someone who invested a substantial amount of
time doing it. E.g: lots of people can cook well, but not everyone is a
professional Chef.
}}}
So I think the distinction between the various tests may be useful for
methodologists and software engineering researchers (people who try to guide
other people how to code) more than the people who are actually coding. To quote
Picasso: “When art critics get together they talk about Form and Structure and
Meaning. When artists get together they talk about where you can buy cheap
turpentine.” ( taken from http://orip.org/ ). Similarly, literature
critics and researchers have very little to say that is of use for most writers
and even authors. I hated studying Literature (what Americans might call
English although naturally in Israel, we study Hebrew texts) with a
passion, and didn't do too well on the tests (in part because I refused to
write a lot of extraneous text, which the teacher seemed to have liked), only
to become a writer of fiction and essays (see
http://www.paulgraham.com/essay.html ) after graduation, which most people I
talked with seem to have liked and appreciate what I wrote (although I admit
they are certainly not letter perfect).
Similarly, I'm now struggling with this tome -
http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 -
which seems like I cannot see the forest for the trees from it, while I
really enjoyed reading the much shorter and much more hands-on
http://en.wikipedia.org/wiki/Test-Driven_Development_by_Example (by Kent Beck).
The time we talk about how to write tests is often better spent writing tests
(or production code, which is, naturally, what tests are aim to support and
are meaningless without it), so I think we should just “freaking write them”.
“Write tests, m*f*!”
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
Escape from GNU Autohell - http://www.shlomifish.org/open-source/anti/autohell/
Linux — Because Software Problems Should not Cost Money.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: QA Sqitch and the rest of perl-module-rpms
Hi David, On Tue, 23 Oct 2012 12:23:43 -0700 David E. Wheeler david.whee...@iovation.com wrote: Hello QA, The perl-module-rpms Git repository has had a number of changes since its last promotion to production, including the addition of Sqitch. Please QA these for production, as the history database project (née audit service) will require it, as will many other projects coming down the pike (e.g., reporting). Once it looks good, please check with Aaron to make sure his team has had a chance to update the SOAP server installation instructions to prevent any changes from breaking the current release of the SOAP server (and gateway), as described here: http://jira.iovation.com/browse/OPS-1705 Once he has confirmed it, then your QA-approved stuff can be added to the production Yum repo. What is perl-module-rpms about? How is it related to other efforts of packaging CPAN modules as RPMs that are mentioned here: http://perl-begin.org/topics/cpan/wrappers-for-distributions/ Finally, where can it be found? Regards, Shlomi Fish Thanks, David -- - Shlomi Fish http://www.shlomifish.org/ List of Text Editors and IDEs - http://shlom.in/IDEs I hope that if it had not been clear before, it isn’t less clear now. — One of Shlomi Fish’s Technion Lecturers Please reply to list if it's a mailing list post - http://shlom.in/reply .
Getting No error instead of No such file or directory on Win32
Hi all, in this CPAN testers XML-LibXML test failure: http://www.cpantesters.org/cpan/report/d9cf95fc-d5e8-1017-8e8a-88a105085451 I am getting this: [QUOTE] t/01basic.t . ok # Failed test 'error parsing non-existent does_not_exist.xml' # at t/02parse.t line 238. # 'Could not create file parser context for file does_not_exist.xml: No error at t/02parse.t line 237. # ' # doesn't match '(?-xism:\ACould not create file parser context for file does_not_exist\.xml: No\ such\ file\ or\ directory)' # Looks like you failed 1 test of 531. t/02parse.t . Dubious, test returned 1 (wstat 256, 0x100) Failed 1/531 subtests [/QUOTE] My question is - why? Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://shlom.in/file-swap Ran Eilam To Shlomi Fish: so what are you working on? Working on a new wiki about unit testing fortunes in freecell? Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Move Test::More development discussion back to perl-qa?
On Sunday 30 Jan 2011 00:20:28 Michael G Schwern wrote: When I started Test::Builder2 I gave it its own mailing list so it could have its own community and not clutter up perl-qa with detailed chatter about Test::Builder2 and Test::More development. I don't get much response to posts on test-more-users, though I know people are subscribed. perl-qa traffic has dropped off quite a bit. I'm wondering that if I moved Test::More and Test::Builder2 posts back to perl-qa that there would be more discussion? Do people not care? Is it going over everyone's heads? Is everyone just waiting for it to be done? Does it not seem like TB2 is relevant? I'm fine with these posts being posted on perl-qa (even though I'm subscribed to test-more-users). Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/ways_to_do_it.html Chuck Norris can make the statement This statement is false a true one. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Looking for a maintainer Test::Deep
Hi Fergal, On Friday 24 September 2010 23:00:53 Fergal Daly wrote: For a long time now, I haven't had time to maintain this module. I don't write any perl beyond 1-liners these days and work and family take up most of my free time. When I do have some time, tweaking software I don't use any more is not on high up the list. There are a couple of things that need doing for the docs and a couple of small contributed patches to apply for new features but other than that, it's fairly static and low maintenance. I believe there are plenty of users but no real bug has been reported for a very long time. The code itself is very modular, adding a new type of comparison is just a matter of adding a class and tests so if someone wanted to start actively developing new features it would be fairly easy. I (= http://search.cpan.org/~shlomif/ ) have some spare time to work on open- source software. I don't believe I've used Test-Deep before, but may have used it indirectly. In any case, I volunteer to maintain the module unless and until a more suitable developer is found. I have change history available as git or hg. I think a Mercurial repository would be preferable because I think I like it better than git. Is there any difference between the two versions of the change history? While we discuss Test-Deep it seems to have a fairly large number of old versions on CPAN: http://search.cpan.org/dist/Test-Deep/ . Please consider trimming them so CPAN will take less space (they are always available on backpan). Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Humanity - Parody of Modern Life - http://shlom.in/humanity rindolf She's a hot chick. But she smokes. go|dfish She can smoke as long as she's smokin'. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Perl-org-patches] qa.perl.org
On Tuesday 29 Dec 2009 23:54:26 Leo Lapworth wrote: Hi, Please note this is cross posted. Several of the QA people have kindly said they will help with updating http://qa.perl.org/. I'm cross posting to http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/perl-org-patches I've split out the site a bit more, so there is a 'testing your code' and a 'testing cpan' section on the site. So what is needed?... 1) Testing your code - I think this will need the largest amount of work. Hilary, could I ask you to have a look at this? - Are the articles the best we can link to? - Do we need those articles if we update the rest of the content. - can the test-modules.html and testing-guidelines.html be cleaned up and updated (currently in POD, but does not have to stay that way)? 2) Testing CPAN Shaun, would you mind looking at this? - Just needs a quick review/update 3) Phalanx Shlomi, would you look at this? - Clean up, so that it can be put aside as completed/superseded. OK, I will. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Rethinking CPAN - http://shlom.in/rethinking-cpan Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ )
Re: [Perl-org-patches] qa.perl.org
On Wednesday 30 Dec 2009 10:50:35 Shlomi Fish wrote: On Tuesday 29 Dec 2009 23:54:26 Leo Lapworth wrote: Hi, Please note this is cross posted. Several of the QA people have kindly said they will help with updating http://qa.perl.org/. I'm cross posting to http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/perl-org-patches I've split out the site a bit more, so there is a 'testing your code' and a 'testing cpan' section on the site. So what is needed?... 1) Testing your code - I think this will need the largest amount of work. Hilary, could I ask you to have a look at this? - Are the articles the best we can link to? - Do we need those articles if we update the rest of the content. - can the test-modules.html and testing-guidelines.html be cleaned up and updated (currently in POD, but does not have to stay that way)? 2) Testing CPAN Shaun, would you mind looking at this? - Just needs a quick review/update 3) Phalanx Shlomi, would you look at this? - Clean up, so that it can be put aside as completed/superseded. OK, I will. OK, here goes: 1. How many tests? How many bugs in RT? Report to Andy. - which Andy is it and where can I find his contact information. 2. Here's a patch that is a minor update (some formatting and some clarifications). Otherwise, the Phalanx site seems good. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ What does Zionism mean? - http://shlom.in/def-zionism Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ ) Index: phalanx/kwalitee.html === --- phalanx/kwalitee.html (revision 1602) +++ phalanx/kwalitee.html (working copy) @@ -6,23 +6,38 @@ }); %] +h2What is Quality?/h2 + +p +Software quality is the property of software that makes it fit the needs of +the end-users, not get on their nerves, and make them feel good about using +it. The English Wikipedia has +a href=http://en.wikipedia.org/wiki/Software_quality;an article about +software quality/a and Shlomi Fish wrote +a href=http://www.shlomifish.org/philosophy/computers/high-quality-software/;an essay called What Makes Software High-Quality?/a. +/p h2 What is kwalitee? /h2 p -Kwalitee is inexact quality. We don't know exactly what it is, but we know it when we see it. +Measuring quality is hard, and so we coined the term Kwalitee which is +measurable (but inexact quality), so we can know it when we see it. /p h3 What is a bug? /h3 p -If there is any difference between the docs, the code and the tests, it is a bug. Period. The bug might be in the docs or the tests, and the code is fine, but it's still a bug. +If there is any difference between the docs, the code and the tests, it is a +bug. Period. The bug might be in the docs or the tests, and the code is fine, +but it's still a bug. /p p -If there is ambiguity about how the code is supposed to work, it is a bug. The documentation must be clarified, and the code may be out of sync as well. +If there is ambiguity about how the code is supposed to work, it is a bug. The +documentation must be clarified, and the code may be out of sync as well. /p p -If a hoplite discovers something behaving incorrectly, according to the hoplite, it may or may not be a bug, according to the author's intent. +If a hoplite discovers something behaving incorrectly, according to the +hoplite, it may or may not be a bug, according to the author's intent. /p h3 What's a kwalitee module? Index: phalanx/faq.html === --- phalanx/faq.html (revision 1602) +++ phalanx/faq.html (working copy) @@ -14,25 +14,33 @@ How did you come up with the a href=/phalanx/100/Phalanx 100/a list? /h3 p -The specifics of how we derived the list isn't really important. We don't want the focus of the project to become which modules are getting attention. We'll be working on a wide variety of CPAN modules, as well as Perl itself, to improve their tests and documentation. +The specifics of how we derived the list isn't really important. We don't want +the focus of the project to become which modules are getting attention. We'll +be working on a wide variety of CPAN modules, as well as Perl itself, to +improve their tests and documentation. /p h3 No, but really, did you look at logs or something? /h3 p -It really doesn't matter. The list is made and that's what we're going with. We think you'll agree that the 100 modules are a good cross-section of what's popular on the CPAN. Maybe some got missed, maybe some shouldn't be on the list. Still, it's a good start. +It really doesn't matter. The list is made and that's what we're going with. We +think you'll agree that the 100 modules are a good cross-section
Re: qa.perl.org - anyone interested in updating it?
On Saturday 19 Dec 2009 14:54:42 Leo Lapworth wrote: Hi, I cleaned up http://qa.perl.org/ but the content needs a complete review/update. Is anyone interested in doing this? I am! You can contact me here: http://www.shlomifish.org/me/contact-me/ Regards, Shlomi Fish I've chatted with several people, but so far not found anyone interested. If no one is interested we'll shut down the site as a lot has changed and we now have CPAN Testers as well, which is probably where we'd redirect to. Cheers Leo -- - Shlomi Fish http://www.shlomifish.org/ The Human Hacking Field Guide - http://shlom.in/hhfg Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ )
Test-Run 0.0120 - Now With Moosey Goodness
Test-Run 0.0120 is now available from a CPAN mirror near you: * http://web-cpan.berlios.de/modules/Test-Run/ * http://search.cpan.org/dist/Test-Run/ What is Test-Run? - Test-Run is an improved test harness for TAP based test streams. Originally forked from Test-Harness-2.x, it has been heavily modularised and extended, and was ported to use TAP-Parser. It has been split into a front-end, a back- end, a prove-like script-in-a-module, all with several OOP classes, and has several optional plugins on CPAN for such things as colouring the output, using alternate interpreters for running the TAP scripts and trimming the displayed filenames. More plugins can be written. What's new in this release? --- The primary change was the Moosification of Test-Run, which made the code cleaner and more modern. Moreover, NEXT.pm was ditched in favour of the more modern MRO::Compat (which defaults to mro.pm in perl-5.10.x and above). YAML.pm was replaced with the faster and better YAML::XS . Finally, the META.yml was enhanced with resources and keywords. Have fun! Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Interview with Ben Collins-Sussman - http://xrl.us/bjn8s God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: looking for CPANTS (co-) maintainers
On Monday 29 June 2009 23:03:00 Thomas Klausner wrote: Hi! See over there: http://use.perl.org/~domm/journal/39189 Hi Thomas! Is this the reason that CPANTS was out-of-date for a long time? It seemed better yesterday, though. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ The Human Hacking Field Guide - http://xrl.us/bjn8q God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: Fluent tests?
On Tuesday 30 June 2009 21:44:50 Michael Peters wrote:
Ovid wrote:
use Test::Fluent 'no_plan';
my ( $have, $want ) = ( 1, 1 );
have $have, want $want, reason 'Some test name';
have [ 3, 4 ], want [ 4, 5 ], reason 'cuz I said so'; # fails
true 3, reason '3 had better be true';
false 3, reason '3 had better still better be true';# fails
I would much rather see something like
cmp_ok(
have = 1,
want = 2,
reason = 'Some test name',
diagnostic = { world = $world },
);
Much more Perlish. I've always disliked some APIs where it's not
immediately clear what's a function call and what's an argument to that
function: is reason() an argument to want() or have()?. It also seems more
obvious for doing things like data-driven tests where you just have a large
data structure that tests are run against.
I tend to agree with this. However, for my subroutines, I prefer to pass named
arguments in a hash-ref, instead of clobbered into @_. So mysub({%args}),
and my $args = shift; rather than mysub(%args) and my %args = shift;.
In any case, in my opinion, your proposal for syntax is saner than Ovid's
proposed DSL.
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html
God gave us two eyes and ten fingers so we will type five times as much as we
read.
Fwd: [sf-perl] Slides for Evolving Tests
-- Forwarded Message -- Subject: [sf-perl] Slides for Evolving Tests Date: Thursday 26 March 2009 From: Fred Moyer f...@redhotpenguin.com To: San Francisco Perl Mongers User Group sanfrancisco...@pm.org Big thanks to Jeff Thalhammer for the great talk on Wednesday evening. I've posted the slides: http://bit.ly/11TJxs Great to see a lot of enthusiasm at the meeting. I think we are a ways away from being able to take on a YAPC, but if we can keep the momentum going, I think a workshop of some sort would be possible to pull off. Most of the Perl workshops are back east or in Europe, so we could likely attract some attention with an SF Bay Area Perl Workshop. What would we need to make that happen? Volunteers. Regular meeting attendees. Running this group has taken more work than I anticipated. I never appreciated how much effort Quinn put into it until I took the reins :) Email me off list if you are interested in helping contribute to part of the group operations. Next meeting is April 28 (yeah I need to fix the meetup site, it shows May right now). Speaker will be David Lowe, an early SF.pm member. Talk is Half a dozen horrible uses for pack and unpack. Hope to see you there! - Fred ___ SanFrancisco-pm mailing list sanfrancisco...@pm.org http://mail.pm.org/mailman/listinfo/sanfrancisco-pm --- -- - Shlomi Fish http://www.shlomifish.org/ Why I Love Perl - http://xrl.us/bjn88 God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
On Thursday 13 November 2008, Michael G Schwern wrote: Andreas J. Koenig wrote: On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern [EMAIL PROTECTED] said: Now that the CPAN shells and archiving modules are handling it at their end, I think the PAUSE filter should be removed. It's not PAUSE's job to be the code police. It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell and archiving module involved. What I was expressing is that the CPAN shell can do the twiddling to strip flags at the point of extraction, rather than PAUSE stopping it at the gate. Archive::Tar already does this (see $Archive::Tar::INSECURE_EXTRACT_MODE). Archive::Tar does, but Archive::Extract (which CPANPLUS uses) doesn't. The important distinction being that it's done under the user's control and not by PAUSE fiat. PAUSE shouldn't be playing security nanny or any other nanny. It's not even necessary or effective. Because there's already a perfectly sensible and universal way to avoid this problem and that's to set your umask to something sensible. Then no matter what the archive's internal permissions are set to they'll be stripped when it's extracted. I already have a sensible umask. However, CPANPLUS ignores it and sets the permissions to be world-writable. See these bugs: * http://rt.cpan.org/Ticket/Display.html?id=39516 * http://rt.cpan.org/Ticket/Display.html?id=39554 Most systems already do this by default, because it's good security practice. If you don't have a umask set, that's a basic vulnerability *at the user's end*. No amount of hand-holding from CPAN will protect the user without a umask. Some other system will ship a world writable file or a setuid executable or something. Then you're hosed all over again. We are trying to fix a basic, wide-spread, user-end security hole, one that is not at all specific to Perl, at too high a level and too specific a system. It's like plugging one hole in a screen door. It's not necessarily a problem at the user-end, because CPANPLUS ignores the (secure) umask I set and still sets the permissions to 666 or 777. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/ways_to_do_it.html Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
On Thursday 13 November 2008, David Golden wrote: On Thu, Nov 13, 2008 at 3:39 AM, Shlomi Fish [EMAIL PROTECTED] wrote: What I was expressing is that the CPAN shell can do the twiddling to strip flags at the point of extraction, rather than PAUSE stopping it at the gate. Archive::Tar already does this (see $Archive::Tar::INSECURE_EXTRACT_MODE). Archive::Tar does, but Archive::Extract (which CPANPLUS uses) doesn't. It was a bug. Addressed in 0.28 as a result of these discussions. The next non-development release of CPANPLUS will use the new Archive::Extract and close the security hole under discussion. This bug still exists in Archive-Extract-0.28. See my comment at the end of: http://rt.cpan.org/Ticket/Display.html?id=39554 One needs to also set $Archive::Tar::CHMOD . Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Funny Anti-Terrorism Story - http://xrl.us/bjn7t Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Tested File-Find-Object-0.1.1 with Class::Accessor not installed
Hi Chris! These reports: * http://www.nntp.perl.org/group/perl.cpan.testers/2008/10/msg2472650.html * http://www.nntp.perl.org/group/perl.cpan.testers/2008/10/msg2473253.html Have tested File-Find-Object without installing its Class::Accessor pre-requisite: # at t/01ffo.t line 9. # Tried to use 'File::Find::Object'. # Error: Base class package Class::Accessor is empty. # (Perhaps you need to 'use' the module which defines that package first.) at /home/cpan/rel/conf/perl-5.6.2/.cpanplus/5.6.2/build/File-Find-Object-0.1.1/blib/lib/File/Find/Object/Base.pm line 9 And: Here is a list of prerequisites you specified and versions we managed to load: Module NameHave Want ! Class::Accessor 00 Please fix it on your end. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ First stop for Perl beginners - http://perl-begin.org/ Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Tuesday 23 September 2008, Eric Wilhelm wrote:
# from chromatic
# on Monday 22 September 2008 17:37:
Yes. Would someone please explain to me how this issue is not
already made a mostly non-issue by having a proper umask and running
CPAN as non-root?
If I were so inclined and had access to your machine, I could do a lot
of damage through such a mechanism without root access.
There would be no mechanism because tar respects the umask by default
when invoked as a non-root user. Thus, there are no world-writable
files being unpacked from CPAN dists on my machine.
Is a umask of 022 not the default setup? Shlomi?
The default Mandriva umask appears to be 0002 . I have the following line in
my default user's .bashrc:
{{{
umask 022
}}}
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
Understand what Open Source is - http://xrl.us/bjn82
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Tuesday 23 September 2008, Eric Wilhelm wrote:
# from Shlomi Fish
# on Monday 22 September 2008 23:55:
There would be no mechanism because tar respects the umask by
default when invoked as a non-root user. Thus, there are no
world-writable files being unpacked from CPAN dists on my machine.
Is a umask of 022 not the default setup? Shlomi?
The default Mandriva umask appears to be 0002 . I have the following
line in my default user's .bashrc:
{{{
umask 022
}}}
So, how are those files being created with world-writable permissions?
That's what my smoke configuration gives me in user cpan.
You are running smokes as this user or as root?
I'm running smokes as a different user altogether (= cpan) which still has
the 0002 umask. I only explicitly set the umask to 0022 on user shlomi,
which is the user I'm doing most of my work in.
You are using tar or
something else?
See for yourself:
https://svn.berlios.de/svnroot/repos/web-cpan/CPAN-Smoke-AutoSetup/trunk/first-rev/
Even with the 0002 it would only set the group write bit.
Interesting.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Tuesday 23 September 2008, Ovid wrote:
--- On Tue, 23/9/08, Shlomi Fish [EMAIL PROTECTED] wrote:
The default Mandriva umask appears to be 0002 .
That surprised me, so I googled default mandriva umask. All the
references I found say the default umask is 0022 ... unless ...
Mandriva offers a tool to control security settings. It's called Msec:
http://wiki.mandriva.com/en/Msec
http://is.gd/2Zzk
Msec offers 7 security levels. Level 0 (The user should not be allowed to
own a computer) is very insecure (not even a password), and Level 6 comes
with its own tinfoil hat. As it turns out, those different security levels
correspond to different umasks, as detailed here:
http://www.brunolinux.com/07-Security/Mandriva_Security_Settings.html
http://is.gd/2Zzn
The only levels which provide a default umask of 0002 are levels 0 and 1,
both of which are *NOT* recommended, but if that's what you say your
default is, I can only wonder how, exactly, you managed to get your system
in that state. (In fact, distributions generally default to level 3, which
has a default umask of 0022.)
My /etc/sysconfig/msec reads:
{
UMASK_ROOT=022
SECURE_LEVEL=3
UMASK_USER=022
TMOUT=0
}
So it should be OK, but it's not. Even if I login from the console as a
different user, for which I did not set the umask explicitly. I see he has a
umask of 0002. Maybe it's the doing of one of the files in /etc.
Of course, even as Eric pointed out, a umask of 0002 still masks the world
writeable permissions, so I still don't see how you're getting there and if
you've configured your system to give *you* a umask of 0022, then you still
shouldn't be getting the warnings you're getting. I don't understand how
this arose, but I'd be curious to find out how.
OK. I'll investigate.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
What Makes Software Apps High Quality - http://xrl.us/bkeuk
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Tuesday 23 September 2008, Eric Wilhelm wrote:
# from Ovid
# on Tuesday 23 September 2008 00:54:
Of course, even as Eric pointed out, a umask of 0002 still masks the
world writeable permissions, so I still don't see how you're getting
there and if you've configured your system to give *you* a umask of
0022, then you still shouldn't be getting the warnings you're
getting. I don't understand how this arose, but I'd be curious to
find out how.
Me too.
Shlomi, It looks like your tar is /bin/tar, so either TAR_OPTIONS is set
in your environment or something else is weird.
{{{
[EMAIL PROTECTED] ~]$ echo $TAR_OPTIONS
[EMAIL PROTECTED] ~]$
}}}
If you can do a 'look Data::Dump::Streamer' from your smoker user's cpan
environment and 'ls -l Makefile.PL' from inside that shell.
{
CPAN Terminal z Data::Dump::Streamer
[MSG] Trying to
get 'http://mirror.mirimar.net/cpan/authors/id/Y/YV/YVES/CHECKSUMS'
[MSG] Checksum matches for 'Data-Dump-Streamer-2.08-40.tar.gz'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/.patch'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/Changes'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/INSTALL.SKIP'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/Dump/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/Dump/Streamer/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/Dump/Streamer/_/'
[MSG]
Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/Dump/Streamer/_/Printers.pm'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/lib/Data/Dump/Streamer.pm'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/Makefile.PL'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/MANIFEST'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/MANIFEST.SKIP'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/META.yml'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/README'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/Streamer.xs'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/as.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/blessed.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/dogpound.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/dump.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/filter.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/globtest.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/hardrefs.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/impure_madness.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/lexicals.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/locked.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/madness.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/madness_w.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/names.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/overload.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/readonly.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/refaddr.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/refcount.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/refelem.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/reftype.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/sortkeys.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/test_helper.pl'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/tree.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/usage.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/t/xs_subs.t'
[MSG] Extracted 'Data-Dump-Streamer-2.08-40/typemap'
[MSG] Extracted 'Data::Dump::Streamer'
to '/home/cpan/.cpanplus/5.10.0/build/Data-Dump-Streamer-2.08-40'
[EMAIL PROTECTED] Data-Dump-Streamer-2.08-40]$ ls -l Makefile.PL
-rwxrwxrwx 1 cpan cpan 3792 2006-04-16 18:33 Makefile.PL*
}}}
Then
run 'umask' or 'env' or something until you find out what is causing
it.
If I do that, I see -rwxr-xr-x, so no hole.
Now, if it's using Archive::TAR, that's potentially a different thing.
~/apps/perl-5.10.0/bin/perl -MArchive::Tar -e 1 is successful and so it seems
that I have Archive::Tar.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://xrl.us/bjn7i
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
[RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
Hi all.
Today, after I invoked my CPAN smoker for a while, I received another msec
(Mandriva Security) report with many world-writable files in the CPAN
distributions that were left unpacked under /home/cpan/.cpanplus . Among the
gems there are:
/home/cpan/.cpanplus/5.10.0/build/Data-Dump-Streamer-2.08-40/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/Digest-JHash-0.05/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/Getopt-ArgvFile-1.11/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/Kephra-0.3.10.11/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/Readonly-1.03/Makefile.PL
/home/cpan/.cpanplus/5.10.0/build/OOTools-2.21/Makefile.PL
As I noted here - http://rt.cpan.org/Ticket/Display.html?id=39481 :
* Why exactly are you reporting this?
Because msec reports it after I'm smoking CPAN.
* What is the problem with world writeable files in a distro?
Let's suppose Makefile.PL is world-writable. While the distro is being
unpacked, a malicious user writes something like:
{{{
system('rm -fr $HOME');
}}}
to it, and after you come to the perl Makefile.PL stage - you lose
your home-directory. ;-)
In any case, Mandriva's msec warns about them, which bothers me.
* What is your proposed remedy?
Make sure none of the files in the archive are world-writable.
}}}
My suggestion for resolving this is to modify the smoking modules so, after
the archive is unpacked (with a proper umask and arguments to tar), they will
traverse the directory tree and look for any world-writable files. If any are
found, they will report the smoking of the module as FAIL, and delete the
unpacked directory tree, without doing the perl Makefile.PL/Build.PL ...
dance.
We could give an option for doing this, if it bothers you. But I'm tired of
finding these files in the msec report and reporting them manually.
Now I volunteer to implement this.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
What Makes Software Apps High Quality - http://xrl.us/bkeuk
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Monday 22 September 2008, David Golden wrote: On Mon, Sep 22, 2008 at 8:40 AM, Shlomi Fish [EMAIL PROTECTED] wrote: My suggestion for resolving this is to modify the smoking modules so, after the archive is unpacked (with a proper umask and arguments to tar), they will traverse the directory tree and look for any world-writable files. If any are found, they will report the smoking of the module as FAIL, and delete the unpacked directory tree, without doing the perl Makefile.PL/Build.PL ... dance. This isn't just a smoking problem, right? A normal CPAN/CPANPLUS install would trigger the same warning? Yes, it would. We could give an option for doing this, if it bothers you. But I'm tired of finding these files in the msec report and reporting them manually. Now I volunteer to implement this. I think that CPANTS is probably the better place for this kind of analysis, particularly because it's static and because the reason for the Kwalitee point is clear. It sounds like exactly the kind of thing that fits among the core Kwalitee metrics. Well, it does. However, hardly anyone pays any attention to CPANTS, and it's out there in the background, and hardly influences the general perception of the module. There are some reasons I think that CPAN Testers is *not* the right place for this: * The CPAN Testers grades relate only to the ability to build/test a distribution. Unless world writable files prevent that, FAIL or UNKNOWN are not appropriate World-writable files are a security risk and the CPAN shell should refuse to test the distribution if they exist. A security conscious admin won't install such modules if they generate world-writable files. As such, one should not proceed to the build/test stage and fail immediately. * Someone would have to read the FAIL and pay attention to understand that the problem is a world-writable file (whereas it's obvious on CPANTS what the problem is) Someone would have to read the FAIL report in any kind of failure. If we report at the top that it was caused by world-writable files then people would pay attention in case they didn't expect a failure. * CPAN::Testers is no longer notifying authors directly anyway Actually, they do. I receive CPAN Testers Daily Reports in email every day, and am also subscribed to the RSS feed. I pay much less attention to the CPANTS. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ What does Zionism mean? - http://xrl.us/bjn8u Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
Hi all.
Note to Securiteam: there's a link to the possible security problem report
at the bottom.
On Monday 22 September 2008, chromatic wrote:
On Monday 22 September 2008 08:41:31 Michael G Schwern wrote:
Shlomi Fish wrote:
Let's suppose Makefile.PL is world-writable. While the distro is being
unpacked, a malicious user writes something like:
{{{
system('rm -fr $HOME');
}}}
to it, and after you come to the perl Makefile.PL stage - you lose
your home-directory. ;-)
Run that by me again how the Makefile.PL being world-writable has any
effect on that? If a Makefile.PL does an rm -rf $HOME and you run it,
it doesn't matter what permission flags are on the file. Your home
directory is gone.
There's a race condition attack between the time the CPAN client *writes*
the world-writeable file and the time the CPAN client *executes* the
world-writeable file. During that time, anyone on the system can write
anything to the file, replacing its legitimate and safe contents with
malicious contents.
That's completely orthogonal to the problem of the Build.PL/Makefile.PL
containing malicious code.
Right. I decided that it was a major problem with how CPANPLUS handles such
situations (regardless to whether we are smoking or just installing) and
reported it here:
http://rt.cpan.org/Ticket/Display.html?id=39516
Please don't keep it more public than it is already until there's a good fix.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
My Aphorisms - http://www.shlomifish.org/humour.html
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: CPAN Testers Daily Report
Hi all! Here's the CPAN Testers daily report I have got today. I have some questions regarding it. On Saturday 20 September 2008, CPAN Tester Report Server wrote: Dear Shlomi Fish, CPAN Testers Notifications have changed. This mail now comes from a centralised server, and authors should no longer be receiving reports directly from testers. If you do receive reports, please ask the tester in question to update their version of Test-Reporter, which now disables the CCing to authors. Thanks. Please find below the latest reports for your distributions, generated by CPAN Testers, from the last 24 hours. Currently only FAIL reports are listed, with only the first instance of a report for a distribution on a particular platform, using a specific version of Perl. As such you may find further similar reports at http://www.cpantesters.org. Acme-CPANAuthors-Israeli-0.01: - i386-dragonfly-thread-multi-64int / 5.8.8 patch 34376: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2249796 - i386-dragonfly-thread-multi-64int / 5.8.8: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2245013 - i686-linux-thread-multi-64int-ld / 5.6.2: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2246011 - i686-linux-thread-multi-64int-ld / 5.10.0: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2243437 - i686-linux-thread-multi-64int-ld / 5.11.0 patch 34379: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2248253 - i686-linux-thread-multi-64int-ld / 5.8.8: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2243516 Acme-CPANAuthors-Israeli version 0.01 was heavily broken, and I: 1. Already released version 0.0102 2. Deleted the previous versions from the CPANPerl QA perl-qa@perl.org using PAUSE. I don't understand why I'm still getting reports for it, when there are already more updated packages. IO-Socket-INET6-2.54: - i686-linux / 5.11.0 patch 34379: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2247432 CPANPLUS-Dist-Fedora-0.0.2: - i686-linux-thread-multi-64int-ld / 5.6.2: - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/2246029 This is also broken, but there's a new version. Why am I getting reports for it, too? Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ What does Zionism mean? - http://xrl.us/bjn8u Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
World-writable files in CPAN Distributions
Hi all, I'm smoke-testing the CPAN distributions using CPAN::YACSmoke, in an under-privileged user. Now I'm using Mandriva Cooker and have msec running, and, as a result, am getting warnings that I have world-writable files in the directories where the CPAN modules were built: Security Warning: World Writable files found : - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/Changes - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/LICENSE - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/MANIFEST - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/META.yml - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/Makefile.PL - /home/cpan/.cpanplus/5.10.0/build/Acme-EyeDrops-1.54/README . . . - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/Changes - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/LICENSE - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/MANIFEST - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/MANIFEST.SKIP - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/META.yml - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/Makefile.PL - /home/cpan/.cpanplus/5.10.0/build/HTML-Scrubber-0.08/README . . . Some of these are -rw-rw-rw permissions in the .tar archive, but some are also files that are made world-writable by running code. Here are some of my bug reports: * http://rt.cpan.org/Ticket/Display.html?id=39038 * http://rt.cpan.org/Ticket/Display.html?id=39037 * http://rt.cpan.org/Ticket/Display.html?id=39035 I would like to brainstorm about possible ways to deal with this problem. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/ Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: TAP YAML Diagnostics
On Monday 07 April 2008, Aristotle Pagaltzis wrote: * Eric Wilhelm [EMAIL PROTECTED] [2008-04-06 18:45]: (perhaps allow non-first numbers too?) /^[a-z][a-z0-9_]*$/ ? ++ Preceding the key with an underscore or some kind of squiggle should be enough to make it safe. Having ToWrite AllPrivateKeys InStudlyCaps OR_EVEN_SHOUT_THEM_IN_FULL_CAPITALISATION would get terribly old very quickly. I second that suggestion. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V.
Idea: CPAN Category Reviews
Hi all! In regards to the previous discussion about trimming down CPAN and finding better ways to find quality modules, I got an idea of making CPAN category reviews. The idea was originally derived from Freshmeat.net where they often have category reviews of the various software hosted there: http://themes.freshmeat.net/articles/section/category%20reviews/ Now I thought of importing that idea for CPAN. What we will do is have a certain blog (possibly on perl-buzz or Perlc.com or somewhere else) where occasionally someone takes upon himself a certain subject (e.g: templating systems, date/time modules, web frameworks, OOP modules or testing modules), review all of the modules (if possible) or the main contenders, and reach a certain conclusion or recommendation. Often there will be modules for orthogonal purposes, or trade-offs (e.g: Template Toolkit vs. Text::Template vs. HTML::Template, which have very different philosophies), and they'll need to state their pros-and-cons and reach a conclusion. Naturally, if there are modules that are buggy, unmaintained, not recommended, etc. he should note it. Now that I think about it, it may be a good idea to also define a machine-readable format (XML etc.) for the conclusions (possibly more) so they can be processed by the various CPAN interfaces. Later on, there could be back-links from search.cpan.org/kobesearch back to the appropriate reviews on the category reviews, similar to the fact that Freshmeat has this project was mentioned in this article, etc.. After the demise and depreciation of the CPAN registered modules list (I can no longer find the URL on http://www.cpan.org/ but it was horribly out-of-date and misleading anyway), it is acceptable that a better human review of the links could be a good idea. What I suppose is that the category reviews should not be published immediately and should be given to peer review by a forum (like a mailing list) dedicated for it. While the review itself should only be written by a very limited number of people[1], the more people review the article before it is published and comment, the better. So what do you think - is there an interest in this? I'm attaching here a list of OOP modules I found on CPAN (probably not fully encompassing, and any addition will be welcome) which I intended to write a category review for on Perl.com. (But from what I understood from my editor it was rejected). It's not much, but it's a start. Regards, Shlomi Fish This is the summary for the article about modules for facilitating Object Oriented Programming in Perl. * Accessors: * Class::Accessor - Class::Accessor::Fast. - Class::Accessor::Chained. - Class::Accessor::Ref * more. * http://search.cpan.org/dist/Object-AutoAccessor/ - Using AUTOLOAD. * http://cpan.uwinnipeg.ca/dist/Class-Field - by Ingy * http://cpan.uwinnipeg.ca/dist/Attribute-Property - by Juerd * Object-Tiny - by Adam Kennedy - extremely minimalistic. * Class::Data::Inheritable - http://cpan.uwinnipeg.ca/dist/Class-Data-Inheritable - Class::Data::Inheritable::Translucent - http://cpan.uwinnipeg.ca/dist/Class-Data-Inheritable-Translucent * Method generators: * Class::MethodMaker * Class::MakeMethods * Class::BuildMethods * Utility modules: * Delegation: - http://cpan.uwinnipeg.ca/dist/Class-Delegator - Class::Delegate - http://cpan.uwinnipeg.ca/dist/Class-Delegation * Class::Multimethods. * NEXT * Class::C3 * Roles/Traits * Class::Trait * Class::Roles * http://cpan.uwinnipeg.ca/dist/mixin * http://cpan.uwinnipeg.ca/dist/Perl6-Roles * Introspection: * http://search.cpan.org/dist/Class-Inspector/ * Object systems: * Moose. - Class::MOP * Class::Std. * Class::Contract - http://cpan.uwinnipeg.ca/dist/Class-Contract * Prototype-based OO - Self, JS, IO * Class::Prototyped * CGI::Prototype * Class::Classless * Spiffy - Class::Spiffy * Aspect Oriented Programming. * Aspect.pm * OO Testing. * Test::Unit. * Test::Class. * OO Exceptions - Error.pm - Exception::Class - http://search.cpan.org/dist/Class-Throwable/ - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V.
Re: Idea: CPAN Category Reviews
Hi! Thanks for your email. On Saturday 05 April 2008, Guy Hulbert wrote: On Sat, 2008-05-04 at 14:02 +0300, Shlomi Fish wrote: Hi all! In regards to the previous discussion about trimming down CPAN and finding I don't think trimming is necessary if you are successful with this. IMO the problem is just finding things, which your proposal addresses. I also don't think trimming is necessary, though a voluntary marking modules as deprecated, unmaintained, etc. may be nice. I believe CPAN-Forum's tags (see http://www.cpanforum.com/tags/ ) are a partial solution to the problem, but there should also be a way for a maintainer to conclusively tag the status of his module as such. better ways to find quality modules, I got an idea of making CPAN category reviews. The idea was originally derived from Freshmeat.net where they often [snip] etc. he should note it. Now that I think about it, it may be a good idea to also define a machine-readable format (XML etc.) for the conclusions (possibly more) so they can be processed by the various CPAN interfaces. not XML ... there already seems to be a format, viz: .cpan/sources/ authors/01mailrc.txt.gz modules/02packages.details.txt.gz modules/03modlist.data.gz so you could add: modules/04categories.gz Well now we end up with the following extra questions: 1. Is this something that should be centrally maintained by the CPAN admins? Or can it be a side service? 2. If not XML, then YAML or something else? I don't have a lot of problems with XML for many things (especially if I want to write free-form text with tags in it)[1], but sometimes a different format would be preferable. In any case, I'd like the containing format to be extensible, so that would probably leave out most ad-hoc custom formats. 3. I was talking about a format for the category reviews, not the categorisation. By all means, I don't want the category reviews themselves to be distributed as meta-data along with the rest of CPAN. Since a category review also contains a lot of free form text, possibly with markup, it makes more sense to use XML than YAML or JSON. At least to me. 4. Perhaps it would be a good idea to allow authors to categorise their modules using PAUSE or the META.yml. We could use something like Freshmeat.net's TROVE categoricalisation - http://freshmeat.net/browse/18/ - or we can simply let them put arbitrary tags and/or categories into the modules. Naturally, this depends on authors actually taking the extra effort to do so, but this is true of many other CPAN quality indicators. you'd also need a web interface at cpan.org Or elsewhere. [snip] So what do you think - is there an interest in this? Sure. Can you write something more concise, and definite. That would make it easier to discuss. Why do you feel my previous email was not concise or definite? I admit it was a sort-of brainstorming email, but it was not too long. If you want a one paragraph summary then: I suggest having a feed of human readable (and possibly machine readable) reviews of the modules in various CPAN categories, as an indication of which modules are recommended and when and which are not. That's even one choice. I'm attaching here a list of OOP modules I found on CPAN (probably not fully That's a good choice for an example (again, IMO). Thanks! Regards, Shlomi Fish [1] - the whole argument that XML is basically just S-expressions in desguise is quite silly, in my opinion. We might as well argue that every data can be encoded as 1's or 0's, or that we can write any program using NAND gates. Both of these claims are correct, but they still miss the point. What do you find clearer: bodyHello b id=nameGuy Hulbert/b! Today is b id=daySaturday/b/body Or: (body Hello ((b :id name) Guy Hulbert) ! Today is ((b :id day) Saturday)) Likewise, S-expressions are more suited for writing Lisp code in than XML markup is. Syntax, no matter how superficial people believe it is, is still very important. - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V.
Re: Idea: CPAN Category Reviews
On Saturday 05 April 2008, Guy Hulbert wrote: On Sat, 2008-05-04 at 15:16 +0300, Shlomi Fish wrote: one paragraph summary then: I suggest having a feed of human readable (and possibly machine readable) reviews of the modules in various CPAN categories, as an indication of which modules are recommended and when and which are not. already exists ( cpan-testers ? ). I don't see it existing. All cpan-testers do is fetch the module from the CPAN (sometimes very old ones), and make sure they pass all tests (if they exist), and can be installed. They don't say how otherwise good the module is. A test coverage may give you better indication of how good the quality of the module is, but it may still be high-quality code implementing low-quality[1] semantics. [1] - for some value of low-quality. What I suggest is a way for individuals (and the community as a whole) to say out of the various XML-processing/OOP-frameworks/Web-frameworks/etc. $X, $Y and $Z are good but different in the following aspects, $T, $S, $R are not recommended but still maintained, and $A, $B and $C should be avoided. Ok. Snark aside, let's look at your list: 1. Maintained by CPAN admins. 2. If not XML then YAML. 3. Format for category reviews rather than categorization. 4. Perhaps (see above) ... allow authors. These are all questions about HOW someone (who?) is going to improve something and at certain people's expense (1 CPAN admins, 4 CPAN authors). I think it is better to start with WHAT are the problems with CPAN (and perl). Make the list as short as possible. Pick the most important one. DO something about it. So, what are the problems ? Here is what I see: a) It is not sufficiently easy to find useful modules. b) There are several ways to create modules[1]. c) Existing documentation is contradictory. I think a) is the most important problem which I'm trying to address. I'll repharse as also that it's not sufficiently easy to find whether a given module is good (of any of the aspects of good), or what is generally recommended, or what most people are using, or what has been deprecated, or what should not be used except for legacy, etc. etc. You get the idea. I don't see b) as a problem. I'm using Module::Build and am happy with it. EU::MM is still maintained because it was the original and people still depend on it. Some people claim M::B is not good. Module::Install has a different philosophy than either EU::MM or M::B, and some people prefer it this way. As for c) - which existing documentation? CPAN Meta-documentation? The documetnation of the individual modules and distributions themselves? Can you point to any proof that this is the case? How is it contradictory? [1] At least: Module::Build Module::Install ExtUtils::MakeMaker I think (a) is the most important problem to solve. So do I. Concisely, I think the best solution is to add some restrictions at the upload interface. To be consistent with TMTOWTDI, these would not prevent modules from being uploaded but not following them would result in making the module more obscure (see 3 catgories below). Hmmm do you suggest it would be omitted from search.cpan.org searches? One way, I have though this could be done is to create cpanp.org or cpan6.org (the latter is on the todo list for perl6 ;-) Right, but from what I understood CPAN6 is not limited to Perl 6 (and possibly not limited even to Perl.) and import all of CPAN into the new system ... but that might annoy people or worse, get you ignored. So a better way would be to clone cpan.org, add the new upload feature, import some modules into it and see what people think. Make it work and minimize the changes and I'm sure you would have people (see 4 above) request the CPAN admins (see 1 above) upgrade. It still looks like a big job to me. A new CPAN... isn't it the chicken-and-the-egg problem? If people know they won't be able to find most obscure modules on NewCPAN, why should they go there instead of OrigCPAN? They probably won't. === details === I actually had to stretch a bit to get (b) and (c) since they are things that I have found but have not been discussed in detail since I have been on the list. I think to some degree that (a) is the cause of (b) and (c). Also, (b) is not a problem on its own but it seems that this is one area that the authors involved seem to agree that there should be some convergence rather than divergence. I could add: d) Namespace confusion / pollution. but that is part of (a). On documentation, I try to start with 'perldoc' and then go to google. I wrote a script to parse the .cpan/sources files so I could find things. I found that the author of ExtUtils::MakeMaker has tried to deprecate it ... but that's been contradicted on this list in the past 3 months. In particular 'perldoc perlmodlib' (i think) in 5.10 still says
Re: Changing the focus of the chronic CPAN problem
kwalitee, then the author has: 1. Updated it recently. 2. Probably intends to support it into the future. I admit that in the CPANTS game, I often just increased my kwalitee by relatively superficial means. But at least it means I'm still alive and kicking and care enough about the module to release a new version. Now the number of open bugs is a poor indicator. If a module has no bugs, either the author is very diligent and handles all of them, or perhaps no one uses the module. On the other hand if it has a lot of bugs, it obviously means quite a few people are using it, but it also may mean that despite it it is incredibly.[1] [1] - For example, XML::Simple is very popular, but I find its concept and way of implementation broken-by-design, and have a policy against helping people with problems with it. So we need to be a bit smart. I think adding some (optional) meta-data to the META.yml for categories, tags and for some flags or a status indicator saying things like deprecated, don't use, in deep maintenance mode, under development, API is not frozen, etc. would be a step in the right direction. I can try filing an RFC about it for the META.yml spec and implementing it into Module::Build, etc. And there could be a Kwalitee metric that the author set these flags. What other parameters can we think of? 1. Last update date - doesn't mean it's not good (see http://perl.plover.com/yak/12views/samples/notes.html#sl-9) , but usually a good one. 2. Average activity over time. (How many releases and how frequently). 3. Kwalitee metric. 4. CPAN Testers (?). 5. Number of incoming references/dependecies in (WWW, CPAN, etc.) - PageRank-like. 6. CPAN Ratings/Reviews. 7. Test coverage. 8. Author tagging/categorising/marking. 9. User-contributed tagging/categorising/marking. I'm not sure if there's one metric we can rely on exclusively. It probably needs to rely on many factors. (Just like Google relies on many factors and heuristics). I don't think there's a single Aha! silver bullet, but we just need to be very smart. Now Freshmeat.net has a similar problem, but I'm not sure if they solved it too well in their search. Nevertheless I think it's encouraging that CPAN has become so full of good modules (because like Andy Lester noted, it's also so full of junk) that we now worry about how to find them. Many languages have a problem of lacking such good APIs and abstractions in the first place, or that they are scattered across many places, and lack the comprehensiveness of CPAN. I think CPAN faces the same problem that the web faced a few years ago before Google - how to find good and relevant information in a lot of low-quality one. This means we have a lot of good and bad information, where that information is code. Anyway, I'll probably set up a wiki page about it, so we can brain-storm more easily. Hopefully we can make this CPAN-Rank happen. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V. * Abstract * Introduction: - The fc-solve-discuss thing. - industrial strength Freecell solvers - I'm not going to discuss what makes a software industrial strength, enterprise-grade, etc., but rather will discuss what makes it high quality. - What's high-quality? - hard to define. - Good software. - that most people like or advocate. - that just works. - often has a lot of FUD or written badly, but at the end of the day, it's what most people use or are even told to use. - Software that is of exceptional quality: - Vim - Subversion - gcc - perl - Note about python - Note about Ruby - bad online documentation - no internal UTF-8 support. - slow - Note about PHP - KDE - Note about GNOME * Parameters for Quality: + - The software is available for download or buying. + - The software has a version number in the archive, or package. + - The software has a homepage. + - An SF.net /project/mysoft/ page does not count. + - The software has packages for most common distributions. + - The software is easy to compile, deploy and install. + - Not too many dependencies. + - Source code is freely available. + - Licence is as permissive as possible. + - Free software. + - GPL compatible. + - LGPL or better. + - BSD-style. + - Just works. + - Builds out of the box, with minimal hassles. + - ./configure --prefix= ; make ; make install + - There are no show-stopping bugs. + - The software has all the featuers people want. + - Good usability + - Good and extensive
Re: Changing the focus of the chronic CPAN problem
On Saturday 05 April 2008, Andy Lester wrote:
On Apr 5, 2008, at 1:34 PM, Shlomi Fish wrote:
Thanks for the comments. See below for my response. It will be a
rather
stream-of-consciousness thing, but I hope something can come up of it.
I've expanded my original comments here:
http://perlbuzz.com/2008/04/rethinking-the-interface-to-cpan.html
Overall it's a good summary. I have some comments, but I'll comment later.
Meanwhile I've set up the wiki pages as promised:
http://perl.net.au/wiki/Finding_a_Module_on_CPAN/Module-Rank
The reason I'm using perl.net.au instead of the Perl 5 Wiki is that:
1. I feel that MediaWiki is more suitable for such brainstorming and massive
editing due to the fact it has a better diff-based feed; a dedicated
discussion page; the less AJAXy editing interface which I feel is a good
thing in this case; and the fact that one can easily edit a sub-section of
the page.
2. We can always move it to somewhere else at a later stage.[1]
{{
[1] - Legal and licensing issues put aside of course, but I hereby proclaim
that the licensing by any contributors will remain compatible. We can say
it's Public Domain (Creative Commons, etc.) or MIT X11 for the sake of the
argument. In any case, arguing about the licence is counter-productive.
}}
So be bold and edit. There are some other pages I have in mind, but let's have
something we can play with on a wiki. It's possible that this pair of
discussions are going to take enough energy of the Perl mongers who will have
to read through them after the weekend (or the Sabbath). I'm not saying it's
not important just that such long and similar discussions tend to get
annoying.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
I'm not an actor - I just play one on T.V.
Re: Find all the modules 'use'd in a directory
On Friday 08 February 2008, Dominique Quatravaux wrote: Andy Lester wrote: First, install ack, either installing App::Ack or downloading the standalone version from http://petdance.com/ack/ Interesting. Would you be so kind as to implement grep -n-style output format for us Emacs users? ack outputs line numbers by default. If you're interested in Emacs integration, see: http://perladvent.pm.org/2006/5/ (Search for Emacs.) Note that this is a cut-and-paste-and-modify of an existing XEmacs Elisp code. I couldn't figure out a better way to do it. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V.
Re: Searching CPAN repositories in a chain
Hi Matisse! First of all, don't start new threads by replying to existing messages. Write a new message to perl-qa@perl.org On Friday 05 October 2007, Matisse Enzer wrote: I'd like to be able to; check mirror-list-number-one (probably all private, inside our firewall) check mirror-list-number-two and so on, for each thing that is being installed, including dependencies. This will allow having a local CPAN that contains locally created stuff, and specific versions of public modules, but allows for using public CPAN repositories for modules not available in the private repos. Does anyone else want this? Yes, I also want secondary CPANPLUS repositories, so people can set up their own in-house repositories for in-house code, or that people can set up entirely new CPAN-like networks. Does this exist? Not that I'm aware of. Shall I patch CPAN or CPANPLUS? That would be nice. I intended to do it myself for quite some time, but did not get to it. Regards, Shlomi Fish Shall I just have a drink and be quiet? -M --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/ -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ If it's not in my E-mail it doesn't happen. And if my E-mail is saying one thing, and everything else says something else - E-mail will conquer. -- An Israeli Linuxer
Re: CPANTS reports in e-mail
On Thursday 31 May 2007, Andy Armstrong wrote: On 31 May 2007, at 08:28, Eric Wilhelm wrote: Wouldn't it would be interesting if there were a multiplexing service for this sort of thing? E.g. maybe a system that allows you to subscribe to a personal mailing list of sorts in much the same way that you can get an rss feed for a given rt query. Cue debate over push vs pull. I'm sure RSS is the way to go - at least as an option. No problem with opting in / opting out / loosing stuff in their spam filter. Sounds good to me, although an email feature will also be nice (though there's always rss2email or a different RSS to email gateway). I should note that like Gabor said I'd like this feature to be opt-in, because I don't want it. I don't care too much about the CPANTS so-called kwalitee, although sometimes when I'm bored, I raise the kwalitee of some of my modules. Still, I see it as just a silly game, and not really an indication of quality. But Gabor's idea is good. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ If it's not in my E-mail it doesn't happen. And if my E-mail is saying one thing, and everything else says something else - E-mail will conquer. -- An Israeli Linuxer
Re: Eliminating STDERR without any disruption.
On Sunday 18 March 2007, Michael G Schwern wrote: Ovid wrote: Amusingly, when I was at last year's Google Test Automation Conference, lots of folks were talking about their XML output from their test harnesses and many of them weren't happy with it (having to wait for a well-formed XML document sucks, particularly when a human can read the partially formed document and still understand things). I wound up giving a lightning talk on TAP in hopes of reeling in the people who were unhappy with XML, but no dice. It would be nice to know what those other systems do that TAP does not. Steal their ideas. Another problem is we're not even on most people's maps. Here's one example. http://opensourcetesting.org Might it be time we start up a TAP-only mailing list? If nothing else it would unclog perl-qa from those who want to talk about something other than TAP. I think that's a good idea. I believe many people here got tired of the TAP-related discussions, and they grew to unpreceded volume. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
ANN: Test-Run-Plugin-AlternateInterpreters
Test-Run-Plugin-AlternateInterpreters version 0.0101 was uploaded to the CPAN
today:
http://search.cpan.org/dist/Test-Run-Plugin-AlternateInterpreters/
This is a plugin for Test-Run and an accompanying Test-Run-CmdLine plugin that
enable one to specify alternate interpreters for running the test files.
Here's a demonstration:
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ ls
mokcat1.yml~ my-interpreters.yaml t
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ cat my-interpreters.yaml
---
- cmd: '/usr/bin/python'
pattern: \.py\z
type: regex
- cmd: '/usr/bin/ruby'
pattern: \.rb\z
type: regex
- cmd: '/usr/bin/perl'
pattern: \.pl\z
type: regex
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ ls -l t/
total 12
-rw-r--r-- 1 shlomi shlomi 94 Mar 16 11:22 test.pl
-rw-r--r-- 1 shlomi shlomi 256 Mar 16 11:15 test.py
-rw-r--r-- 1 shlomi shlomi 222 Mar 16 11:13 test.rb
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ cat t/test*
use strict;
use warnings;
use Test::More tests = 1;
# TEST
ok (1+1 == 2, 1 and 1 is 2);
num = 1
def ok(test, msg):
global num
if test:
extra =
else:
extra = not
print extra + ok + str(num) + - + msg
num = num + 1
print 1..2
ok((5+5 == 10), 5 and 5 is 10)
ok((3*8==24), 3 times 8 is 24)
$num = 1;
def ok(test, msg)
extra = test ? : not
if (test)
puts #{extra}ok #{$num} - #{msg}
end
$num += 1
end
puts 1..2
ok((5+5 == 10), 5 and 5 is 10)
ok((3*8==24), 3 times 8 is 24)
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ export
HARNESS_PLUGINS=ColorSummary AlternateInterpreters
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ export
HARNESS_ALT_INTRP_FILE=`pwd`/my-interpreters.yaml
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$ runprove t/test*
t/testok
t/testok
t/testok
All tests successful.
Files=3, Tests=5, 0 wallclock secs ( 0.08 cusr + 0.02 csys = 0.10 CPU)
shlomi:~/progs/perl/cpan/Test/Test-Harness/Temp$
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Worrying about future proofing TAP is a little premature
On Tuesday 13 March 2007, Michael G Schwern wrote: So, we seem to have drifted from the topic of test groups over to this topic of future proofing against broken versions and TAP producer / parser version negotiation. I have a simple solution for this. If all we do is argue about TAP extensions and never actually produce one we will never have to worry about new versions! Brilliant! I'm a god damned genius. And it seems that we're steady on track on this one, batting 1.000 since May 2001. [1] Point is, its a little premature to worry about future proofing TAP against versioning mistakes when we're not producing new versions! I said last week that I'm worried about how much time has been spend talking about TAP extensions and so little actually writing code and I'm serious. There are four tasks to be done. Andy Armstrong has done one. Andy, Ovid and Eric are working on TAP::Parser. There's been one edit to the TAP spec, which I suspect was done by Andy. Hmmm I sent Andy a patch to correct some typos in TAP.pm (the TAP spec) and received no reply. Here is the message for your inspection. Regards, Shlomi Fish And nothing done to work on the TAP diagnostic syntax, easily the most pressing new TAP feature. I'm not even going to address the issue further, consider it shelved until we get a TAP extension implemented. [1] Technically Andy Armstrong went ahead and actually implemented the TAP version spec in TAP::Parser breaking our perfect record. Boo! ;) -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ---BeginMessage--- Hi Andy! I went over TAP.pm and corrected some typos. Here's the patch. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. --- TAP.pm.orig 2007-03-10 10:19:23.585295498 + +++ TAP.pm 2007-03-10 10:27:52.886318909 + @@ -13,7 +13,7 @@ TAP, the Test Anything Protocol, is Perl's simple text-based interface between testing modules such as Test::More and a test harness such as -Test::Harness 2.x or TAP::Harness 3.x. +Test::Harness 2.x or TAP::Harness. =head1 THE TAP FORMAT @@ -52,7 +52,7 @@ The plan tells how many tests will be run, or how many tests have run. It's a check that the test file hasn't stopped prematurely. It must -appear once, whether at the beginning or end of the output. +appear once, whether at the beginning or at the end of the output. The plan is usually the first line of TAP output and it specifies how many test points are to follow. For example, @@ -86,7 +86,7 @@ point. C/^ok/ is a successful test point. This is the only mandatory part of the line. -Note that unlike the Directives below, Cok and Cnot ok are +Note that unlike the directives below, Cok and Cnot ok are case-sensitive. =item * Test number @@ -297,7 +297,7 @@ =head2 Got spare tuits? -The following example reports that four tests are run and the last two +The following example reports that four tests were run and the last two tests failed. However, because the failing tests are marked as things to do later, they are considered successes. Thus, a harness should report this entire listing as a success. ---End Message---
Re: Worrying about future proofing TAP is a little premature
On 3/13/07, Andy Lester [EMAIL PROTECTED] wrote: On Mar 13, 2007, at 2:39 AM, Shlomi Fish wrote: Hmmm I sent Andy a patch to correct some typos in TAP.pm (the TAP spec) and received no reply. Here is the message for your inspection. Dude, two days in patch land is teeny. Applied, thank you. You're welcome. Regards, Shlomi Fish xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance -- -- Shlomi Fish http://www.shlomifish.org/ If his programming is anything like his philosophising, he would find 10 imaginary bugs in the Hello World program.
Test::Run 0.0105
Hi all! Up on the hills of the release of TAP::Parser 0.51, I released a new version of Test::Run that works against it: http://search.cpan.org/dist/Test-Run/ The Changes file reads: 0.0105Mon Mar 12 23:46:34 IST 2007 * Converted from TAPx::Parser 0.3x to TAP::Parser 0.51, including various changes to the tests and code to get over several regressions. While I was in the swing, I also started cleaning up the code a bit (in the trunk only so far): 1. Removed some unused package variables. 2. Converted use MyModule; @ISA=(qw(MyModule)); directives to use base 'MyModule'; 3. Extracted several classes to their own files. (Not over with it yet). 4. Implemented the increment function for the totals in a better way. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: TAPx::Parser - TAP::Parser?
On 3/7/07, Adrian Howard [EMAIL PROTECTED] wrote: On 5 Mar 2007, at 22:30, Ovid wrote: (Resent from the address I've actually subscribed from!) Hi all, Per an email from Schwern, he does not object to renaming TAPx::Parser to TAP::Parser. Hence, we have an official 'blessing' from him for claiming this namespace. Does anyone have any thoughts/objections to this? I realize that enough people are using TAPx::Parser that it might be a tiny speed bump for some, but I can't see any major difficulties here. Any concerns/objections? Nope. Also fine by me, as Test::Run only uses TAPx::Parser on a small number of places. Regards, Shlomi Fish Adrian -- -- Shlomi Fish http://www.shlomifish.org/ If his programming is anything like his philosophising, he would find 10 imaginary bugs in the Hello World program.
Re: a safer way to use no_plan?
On Sunday 04 March 2007, chromatic wrote:
On Saturday 03 March 2007 18:18, Andy Lester wrote:
Good Lord do I get frustrated at the handwringing over test
counting. Look, it's simple. You write your tests. You run it
through prove. You see how many tests it reports. You add it at the
top of the file. Voila!
But Andy, what if I modify the test file? I don't want to have to modify
the test file to tell my test harness that I've modified the test file!
If only we had something that flies through space
My solution to this is:
http://search.cpan.org/dist/Test-Count/
It's not a perfect solution but it Works For Me.tm
What I do is add comments in a small domain-specific language that allow me to
count how many tests were added. These comments are usually placed close to
the tests themselves, so they can be updated at the same time. Examples for
such comments are:
# TEST
is ($mystring, Hello, String is Hello);
# TEST*3
for my $i (0 .. 2)
{
ok ()
}
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Custom extensions to META.yml
On 3/1/07, David Golden [EMAIL PROTECTED] wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no I would prefer the second option because it is more modular. However, there should be a way to add things to it easily when preparing the META.yml. Regards, Shlomi Fish Thanks in advance for your thoughts. David -- -- Shlomi Fish http://www.shlomifish.org/ If his programming is anything like his philosophising, he would find 10 imaginary bugs in the Hello World program.
Re: Generating test data and testing it
Hi Ovid!
On 2/20/07, Ovid [EMAIL PROTECTED] wrote:
Here's a common enough problem that I assume someone else has solved
it.
Tools in question:
Test::Class
Test::WWW::Mechanize
We want to test creating users (pseudo-code, but close to what we
actually use):
sub add_user : Tests(5) {
my $test = shift;
my $mech = $test-mech;
$mech-get_ok( $add_user_page, 'get the Add User page' );
$mech-submit_form(
form_name = 'add_user',
fields= { name = $some_name }
);
$mech-content_like( qr/User added/ );
$mech-back;
$mech-submit_form(
form_name = 'add_user',
fields= { name = $some_other_name }
);
$mech-content_like( qr/User added/ );
$mech-get_ok( $user_page, 'get the List User page' );
$mech-content_like( qr/2 users found/ );
}
So that's all well and good, but another class has another method where
we to add accounts, but we must have a customer backing each account
successfully added. We'd rather not simply duplicate the above logic
and since the code's already written, I had the (quite possibly stupid)
idea of rewriting the above like this:
sub add_user : Tests(5) {
my $test = shift;
my $mech = $test-mech;
my $override = override_if_fixture(
test = $test,
mech = $mech,
overrides = {
get_ok = sub {
my ( $mech, $page ) = @_;
$mech-get($page);
},
content_like = sub {},
}
);
Maybe I'm missing something, but in your second example, you declare
$override as a lexical and don't use it anywhere. May I inquire what
was your real intention?
Regards,
Shlomi Fish
$mech-get_ok( $add_user_page, 'get the Add User page' );
$mech-submit_form(
form_name = 'add_user',
fields= { name = $some_name }
);
$mech-content_like( qr/User added/ );
$mech-back;
$mech-submit_form(
form_name = 'add_user',
fields= { name = $some_other_name }
);
$mech-content_like( qr/User added/ );
$mech-get_ok( $user_page, 'get the List User page' );
$mech-content_like( qr/2 users found/ );
}
The idea is, in this scope, we'd convert the 'get_ok' and
'content_like' methods to *not* be tests for the current scope. This
allows us to use our tests as test fixtures rather than duplicate this
logic.
I think this is a horribly clumsy idea, but the above is a simplified
example and some test data could get hairy to setup and if we change
our Web pages, I'd hate to find all of the duplicated logic for setting
up this test data and testing that it actually works (note that we
could be testing a remote server and not always be in a position to
access the database directly).
Thoughts?
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
--
--
Shlomi Fish http://www.shlomifish.org/
If his programming is anything like his philosophising, he
would find 10 imaginary bugs in the Hello World program.
Re: Regression Behaviour between TAPx-Parser-0.41 to TAPx-Parser-trunk
On Friday 16 February 2007, Ovid wrote: Can anyone else comment on this? I understand exactly where Shlomi is coming from and I know that he's wrong in his thoughts, but there is certainly a difference of opinion regarding 'correct' behavior. Actually, I wasn't claiming the current behaviour of Test::Run and Test::Harness is the correct one. I only claimed that Test::Run behaves the same as T::H and that TAPx::Parser broke it in this respect. I find it unlikely that my code differs in interpreation from Test::Harness in this regard. After all, my code is derived from Test::Harness, and I don't recall changing the tests inside t/test-harness.t. Furthermore, the results specification for the test for 'bignum' is the same in both places. I can understand that. In this case, I'm not sure where Test::Harness goes wrong, but it's wrong. After conversation with Schwern, it was determined that any tests run which are more than the 'planned' tests are 'not ok'. I think Test::Harness is wrong in this regard and that's possibly part of the reason why the prove output is so strange. Very well - I guess I agree with that. I'll wait until the new TAPx::Parser has a stable version on CPAN and modify the tests and behaviour of Test::Run accordingly while bumping the required version of TAPx::Parser to the new one. (Due to the incompatibility changes). $ prove badplan badplan...FAILED tests 3-4 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail List of Failed badplan22 3-4 Failed 1/1 test scripts. -2/2 subtests failed. Files=1, Tests=2, 0 wallclock secs ( 0.01 cusr + 0.01 csys = 0.02 CPU) Failed 1/1 test programs. -2/2 subtests failed. First it says that 2/2 failed and that 0.00% were OK and later says that -2/2 failed. Both 2/2 and -2/2 are wrong, since 2/4 tests 'failed'. 2 tests were planned, 4 were run. We don't have any way of knowing if the plan is wrong or if the final two tests were run in error. Only a human looking at the code can determine this. Thus, the 'prove' output is incorrect (and contradictory and non-sensical). Yes, you're right. (Note: this isn't meant to be a slam on Schwern or Andy Lester. They've both done great work with a code base which has evolved into a corner.) Sure. $ runtests badplan badplan All 2 subtests passed Test Summary Report --- badplan (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 Parse errors: Bad plan. You planned 2 tests but ran 4. Files=1, Tests=4, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) That's much clearer. As pointed out, 'runtests' output is clearer, non-contradictory, documented, and tells the programmer what happened, unlike 'runprove' or 'prove'. This is one case where I think that following the exact behavior of T::H and 'prove' is an error. OK. It does, but I still don't know how to emulate the Test::Harness behaviour using the new TAPx::Parser API. Admittedly, I don't know your design goals, but I don't think you should emulate broken behavior. You've done enough work on Test::Run that I suspect that fixing confusing output is not a bad thing. If you really want to emulate the behavior, check 'has_todo' and 'actual_ok' in TAPx::Parser::Result::Test. Those might help. No, that's OK - I'll change the behaviour. And furthermore, I'm not sure I'll be able to rely on the new API until a stable version of TAPx::Parser 0.5x is released, That's fair. We're working on getting a stable release (there are enough changes that it might bump up to 0.6). Thanks again for pointing this out. In writing more tests for it, I found a subtle bug with my implementation. It won't fix your problem and might even make things worse. (I was comparing $parser-tests_planned to $result-test_num -- which might be wrong if tests are misnumbered -- instead of to $parser-tests_run). You're welcome. Thanks and regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Integrating Test::Run into an ExtUtils::MakeMaker+Test::Manifest Setup - Take 2
Hi all! In regards to: http://www.nntp.perl.org/group/perl.qa/2006/11/msg7395.html I applied Schwern's input into the Makefile.PL process of XML::RSS: http://svn.perl.org/modules/XML-RSS/trunk/Makefile.PL Enjoy! Regards, Shlomi Fish -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Regression Behaviour between TAPx-Parser-0.41 to TAPx-Parser-trunk
Hi!
Test::Run works fine with TAPx-Parser 0.41, but it breaks with the
TAPx-Parser from the trunk:
shlomif:$trunk/modules/Test-Shlomif-Harness$ perl -Ilib t/test-harness.t
1..182
ok 1
ok 2 # skip don't apply to a bailout
ok 3 # skip don't apply to a bailout
ok 4 # skip don't apply to a bailout
ok 5 # skip don't apply to a bailout
ok 6 # skip don't apply to a bailout
ok 7 - bailout - No warnings
ok 8 # skip special tests for bailout
ok 9
ok 10 - bignum - all ok
ok 11 - bignum - has total
not ok 12 - bignum - totals
# Failed test (t/test-harness.t at line 522)
# Structures begin differing at:
# $got-{ok} = '2'
# $expected-{ok} = '4'
ok 13 - bignum - failed
ok 14 - bignum - Got proper warnings
ok 15 # skip special tests for bailout
not ok 16
# Failed test (t/test-harness.t at line 518)
# got: 'Assert failed! at lib/Test/Run/Straps.pm line 333
# '
# expected: ''
.
.
.
While:
shlomif:$trunk/modules/Test-Shlomif-Harness$ prove -I lib -I
~/progs/perl/cpan/Test/TAPx-Parser/TAPx-Parser-0.41/lib/
t/test-harness.t
t/test-harnessok
30/182 skipped: various reasons
All tests successful, 30 subtests skipped.
Files=1, Tests=182, 3 wallclock secs ( 2.54 cusr + 0.57 csys = 3.11 CPU)
I'll try to investigate further. In the meanwhile you can see what I'm
doing by svn checkout'ing this:
https://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/trunk/
Regards,
Shlomi Fish
--
--
Shlomi Fish http://www.shlomifish.org/
If his programming is anything like his philosophising, he
would find 10 imaginary bugs in the Hello World program.
Re: Regression Behaviour between TAPx-Parser-0.41 to TAPx-Parser-trunk
Hi all!
On 2/15/07, Shlomi Fish [EMAIL PROTECTED] wrote:
Hi!
Test::Run works fine with TAPx-Parser 0.41, but it breaks with the
TAPx-Parser from the trunk:
Replying to myself I'd like to note that from my analysis at least the
bignum test failed because of the following code in the new
TAPx::Parser:
sub is_ok {
my $self = shift;
return if $self-is_unplanned; # ---
# TODO directives reverse the sense of a test.
return $self-has_todo ? 1 : $self-ok !~ /not/;
}
Since the test is reported as unlpanned, then it always returns false,
regardless of the true verdict. And I don't see a way to get the
second condition evaluation (which is what I need) without duplicating
its logic.
In TAPx::Parser 0.41 we have:
sub is_ok {
my $self = shift;
# TODO directives reverse the sense of a test.
return $self-has_todo ? 1 : $self-ok !~ /not/;
}
So this is apparently what broke Test::Run.
Regards,
Shlomi Fish
shlomif:$trunk/modules/Test-Shlomif-Harness$ perl -Ilib t/test-harness.t
1..182
ok 1
ok 2 # skip don't apply to a bailout
ok 3 # skip don't apply to a bailout
ok 4 # skip don't apply to a bailout
ok 5 # skip don't apply to a bailout
ok 6 # skip don't apply to a bailout
ok 7 - bailout - No warnings
ok 8 # skip special tests for bailout
ok 9
ok 10 - bignum - all ok
ok 11 - bignum - has total
not ok 12 - bignum - totals
# Failed test (t/test-harness.t at line 522)
# Structures begin differing at:
# $got-{ok} = '2'
# $expected-{ok} = '4'
ok 13 - bignum - failed
ok 14 - bignum - Got proper warnings
ok 15 # skip special tests for bailout
not ok 16
# Failed test (t/test-harness.t at line 518)
# got: 'Assert failed! at lib/Test/Run/Straps.pm line 333
# '
# expected: ''
.
.
.
While:
shlomif:$trunk/modules/Test-Shlomif-Harness$ prove -I lib -I
~/progs/perl/cpan/Test/TAPx-Parser/TAPx-Parser-0.41/lib/
t/test-harness.t
t/test-harnessok
30/182 skipped: various reasons
All tests successful, 30 subtests skipped.
Files=1, Tests=182, 3 wallclock secs ( 2.54 cusr + 0.57 csys = 3.11 CPU)
I'll try to investigate further. In the meanwhile you can see what I'm
doing by svn checkout'ing this:
https://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/trunk/
Regards,
Shlomi Fish
--
--
Shlomi Fish http://www.shlomifish.org/
If his programming is anything like his philosophising, he
would find 10 imaginary bugs in the Hello World program.
--
--
Shlomi Fish http://www.shlomifish.org/
If his programming is anything like his philosophising, he
would find 10 imaginary bugs in the Hello World program.
Re: Regression Behaviour between TAPx-Parser-0.41 to TAPx-Parser-trunk
On Thursday 15 February 2007, Ovid wrote:
--- Shlomi Fish [EMAIL PROTECTED] wrote:
Replying to myself I'd like to note that from my analysis at least
the
bignum test failed because of the following code in the new
TAPx::Parser:
sub is_ok {
my $self = shift;
return if $self-is_unplanned; # ---
# TODO directives reverse the sense of a test.
return $self-has_todo ? 1 : $self-ok !~ /not/;
}
This does appear to be a bug.
I know how it came about and I'm looking
at how to get around it.
OK, thanks.
Thanks for the heads up.
You're welcome. Of course, this is only the cause for the first failure of the
Test::Run tests. There may be more regressions in TAPx::Parser that the other
failures in Test::Run. You may wish to see that everything passes while
you're at the neighbourhood.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Regression Behaviour between TAPx-Parser-0.41 to TAPx-Parser-trunk
On Thursday 15 February 2007, Ovid wrote:
--- Shlomi Fish [EMAIL PROTECTED] wrote:
Test::Run works fine with TAPx-Parser 0.41, but it breaks with the
TAPx-Parser from the trunk:
I've figured it out and that's because TAPx::Parser 0.41 was buggy and
the latest TAPx::Parser has found a point where your code differs in
interpretation from Test::Harness.
I find it unlikely that my code differs in interpreation from Test::Harness in
this regard. After all, my code is derived from Test::Harness, and I don't
recall changing the tests inside t/test-harness.t. Furthermore, the results
specification for the test for 'bignum' is the same in both places.
Replying to myself I'd like to note that from my analysis at least
the
bignum test failed because of the following code in the new
TAPx::Parser:
sub is_ok {
my $self = shift;
return if $self-is_unplanned; # ---
# TODO directives reverse the sense of a test.
return $self-has_todo ? 1 : $self-ok !~ /not/;
}
You noted that the 'bignum' test failed. Well, let's look at that one:
print DUMMY;
1..2
ok 1
ok 2
ok 136211425
ok 136211426
DUMMY
If you try and run that through 'prove', you'll get a strange Can't
detailize, too big error, so let's keep it simple, with normal tests
but a bad plan:
$ cat badplan
print DUMMY;
1..2
ok 1
ok 2
ok 3
ok 4
DUMMY
And then use 'prove':
$ prove badplan
badplan...FAILED tests 3-4
Failed 2/2 tests, 0.00% okay
Failed Test Stat Wstat Total Fail List of Failed
badplan22 3-4
Failed 1/1 test scripts. -2/2 subtests failed.
Files=1, Tests=2, 0 wallclock secs ( 0.01 cusr + 0.01 csys = 0.02
CPU)
Failed 1/1 test programs. -2/2 subtests failed.
Hmm, 2/2 tests failed with 0.00% ok? Later we get -2/2 subtests
failed?
I'm getting:
shlomi:$trunk/modules/Test-Shlomif-Harness$ prove badplan
badplan...FAILED tests 3-4
Failed 2/2 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
badplan22 100.00% 3-4
Failed 1/1 test scripts, 0.00% okay. -2/2 subtests failed, 200.00% okay.
And with runprove (the Test::Run-based prove equivalent):
badplan...FAILED test 3-4
Failed 2/2 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
badplan22 100.00% 3-4
Failed 1/1 test scripts, 0.00% okay. -2/2 subtests failed, 200.00% okay.
Which seem exactly identical to me.
What does 'runtests' say? ('runtests' will handle the 'bignum' test
above, too):
$ runtests badplan
badplan All 2 subtests passed
Test Summary Report
---
badplan (Wstat: 0 Tests: 4 Failed: 2)
Failed tests: 3-4
Parse errors: Bad plan. You planned 2 tests but ran 4.
Files=1, Tests=4, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00
CPU)
That's much clearer. The problem happens because you've run two more
tests than you planned, so the third and fourth tests are 'unplanned'.
As a result, the harness has no way of knowing if you have a bad plan
or if you have spurious tests being run. Hence, running more tests
than you have planned is an error.
Note that 'is_unplanned' is documented to always return false with a
trailing plan because you can't know until you reach the plan (or
never, with an infinite stream) if any tests were unplanned.
OK.
I'm also about to commit more tests to guarantee this behavior since it
is documented but not tested well enough.
I hope that explains things.
It does, but I still don't know how to emulate the Test::Harness behaviour
using the new TAPx::Parser API. And furthermore, I'm not sure I'll be able to
rely on the new API until a stable version of TAPx::Parser 0.5x is released,
in which case, I'll have to require this particular version in my requires
field. (Just as I'm requiring version 0.33 now).
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Module::Build and the Test Harness Report in the CPAN Testers
Hi all! In this message to Israel.PM: http://perl.org.il/pipermail/perl/2006-September/008165.html Yuval Kogman claimed that Module::Build generates CPAN testers reports with no output from the test harness. Now, I released Math::GrahamFunction, which is based on Module::Build, a few days ago and today received this failure error report: http://nntp.x.perl.org/group/perl.cpan.testers/397523 And indeed it does not contain the output of the test harness. Is this a known problem with Module::Build? Is it intentional, or are people otherwise working on resolving it? Is there anything I can do about it? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Test Coverage vs. Refactoring
As I've been increasing the test coverage of XML::RSS, something has occured
to me. Let's suppose we have the following pseaudo-code:
sub func1
{
my ($self, @params) = @_;
.
.
.
if (COND)
{
$self-do_something(...);
}
.
.
.
}
sub func2
{
my ($self, @params) = @_;
.
.
.
if (COND)
{
$self-do_something(...);
}
.
.
.
}
Now, in order to achieve full test coverage we need to cover both (identical)
conditional in func1 as well as func2. However, after we refactor the code to
extract the conditional, we get the following code:
sub handle_cond
{
my ($self, ...) = @_;
if (COND)
{
$self-do_something(...);
}
}
sub func1
{
my ($self, @params) = @_;
.
.
.
$self-handle_cond(...);
.
.
.
}
sub func2
{
my ($self, @params) = @_;
.
.
.
$self-handle_cond(...);
.
.
.
}
Now we only have to cover the outcomes of the condition in only one function.
(or two different outcomes in different functions). So our test coverage is
not as comprehensive as the previous one.
This is naturally a limitation of test coverage in general which only checks
coverage for individual code atoms, and not for all the different paths of
execution (their Cartesian products).
Right now an ad-hoc solution is to make sure that one has a good test coverage
before one refactors the code. But I think the philosophical problem is also
interesting.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: TAPx::Parser 0.05_03
Hi Ovid! On Monday 08 January 2007 22:26, Ovid wrote: It's on its way to the CPAN now. Thanks for lots of feedback. I'd really love to hear from Windows users as to whether or not it seems to work OK there. Also, if you're using TAPx::Parser and you think your project/organization wouldn't mind, I'd love to start including a list of users, just to show folks that it's being used. For example, I know someone in Yahoo! is using it to 'tag' test output (this is public knowledge via the Perl-QA mailing list). More feature requests welcome. 0.05_03 08 January 2007 You said 0.05_03 once here ^^^ and once in the subject. However, there's already 0.41 on CPAN. Didn't you mean 0.50_03? Regards, Shlomi Fish - Fixed bug where '-q' or '-Q' with colored tests weren't suppressing all information. - Fixed an annoying MANIFEST nit. - Made '-h' for runtests now report help. Using a new harness requires the full --harness switch. - Added 'problems' method to TAPx::Parser and TAPx::Parser::Aggregator. - Deprecatd 'todo_failed' in favor of 'todo_passed' - Add -I switch to runtests. - Fixed runtests doc nit (smylers) - Removed TAPx::Parser::Builder. - A few more POD nits taken care of. - Completely removed all traces of C--merge as IPC::Open3 seems to be working. - Moved the tprove* examples to examples/bin in hopes of them no longer showing up in CPAN's docs. - Made the 'unexpectedly succeeded' message clearer (Adam Kennedy) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/ -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: The Wiki Has Been Spammed
On Tuesday 05 December 2006 04:53, Michael G Schwern wrote: Shlomi Fish wrote: Hi all! The wiki has been spammed: http://qa.yi.org/index.php?title=TAP%3A%3AHarnessdiff=1744oldid=1611 And there isn't any contact information on the wiki anywhere. You can find the porocedures to battle it here: http://www.iglu.org.il/wiki/index.php/Hamakor_Servers/MediaWikis_Spam_Fig hting Thanks for reporting this, but its also nice to clean up what you see. It a wiki, edit it. Well, there are scripts to clean spam. (See: maintenance/cleanupSpam.php in the MediaWiki distribution). They should be run instead of humans cleaning up the spam manually. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
The Wiki Has Been Spammed
Hi all! The wiki has been spammed: http://qa.yi.org/index.php?title=TAP%3A%3AHarnessdiff=1744oldid=1611 And there isn't any contact information on the wiki anywhere. You can find the porocedures to battle it here: http://www.iglu.org.il/wiki/index.php/Hamakor_Servers/MediaWikis_Spam_Fighting Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Integrating Test::Run into an ExtUtils::MakeMaker+Test::Manifest Setup
Hi!
Sorry for the late response - I've been distracted.
On Wednesday 01 November 2006 22:13, Michael G Schwern wrote:
Shlomi Fish wrote:
Hi all!
See http://xrl.us/sw5o for a recipe for integrating make runtest and
make distruntest targets into a Makefile.PL-generated Makefile that
makes use of Test::Manifest.
I needed that when working on XML::RSS, so I wrote it.
What has me scratching my head here is why you're hacking in a new target
for Test::Run rather than just overriding the test target using the much
cleaner test_via_harness(). Either the author wants to use Test::Run or
they don't. If the intention is for your own personal use while hacking
other's modules, it seems much easier to simply have a prove command-line
equivalent for running tests with Test::Run and Test::Manifest then to have
to hack up each author's Makefile.PL.
Well, my original motivation was to have make test still use Test::Harness
so one will not need to use Test::Run to run the tests. I don't want to
impose Test::Run. Now instead, those that have Test::Run installed will be
able to say make runtest or make distruntest (which is harder to
implement as a command line utility.)
I already have runprove which is a Test-Run-based command line utility
like prove. However, running runprove -l t/*.t or in our case, something
using Test::Manifest, is more error prone than typing make runtest
and make distruntest would be even harder to get right this way.
Over-riding make test and make disttest would not be a good idea, because
it will necessisate Test::Run in order to test the module.
As for the implementation, here's some notes to avoid MakeMaker land mines:
Your perl is hard coded. You should be using $(PERLRUNINST) so that the
tests run with the same perl used to run Makefile.PL.
Thanks, I'll correct it.
You probably want to stash the bulk of the command line code off in a
function somewhere like ExtUtils::Command::MM::test_harness() and
Test::Manifest::run_t_manifest(). Long command lines mean portability
problems.
Yes, that would be a good idea.
This is not how you override methods in MakeMaker. Its not backwards
compatible and it pokes at the guts which are likely to move.
sub ExtUtils::MM_Any::test_via_harness {
Well, this function was added to the XML::RSS Makefile.PL before I modified it
to add Test::Run support. I guess it would still be a good idea to fix it.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Integrating Test::Run into an ExtUtils::MakeMaker+Test::Manifest Setup
Hi all! See http://xrl.us/sw5o for a recipe for integrating make runtest and make distruntest targets into a Makefile.PL-generated Makefile that makes use of Test::Manifest. I needed that when working on XML::RSS, so I wrote it. Enjoy! Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Suggestions for cpantesters
On Saturday 30 September 2006 01:16, Alexandr Ciornii wrote: Hello! For a long time I'm using Test::Reporter. Now I participate in Vanilla Perl project (http://win32.perl.org). I've started CPAN smoke. I've come to several ideas regarding cpantesters. I want your opinion on them. 1. YAML files on http://cpantesters.perl.org/ should include compiler info. Most important example: distinguish between ActiveState Perl and Vanilla Perl. I have both. Special case would be using gcc to compile modules for ActiveState (don't know how to check for it). Maybe also include some identifier (like Perl included in OS or compiled). That would be a good idea. 2. Develop http transport for Test::Reporter (partially done by me). Good idea. In addition to submitting the test report by email. 3. Modify CPANPLUS to report versions of dependencies even in case of success. CPAN::Reporter already does this. Good idea. 4. Modify CPAN::YACSmoke to have better configuration and to always skip distributions in corresponding list in config. Right. 5. We should have a list of hanging modules with comments for skipping on CPAN smoking. Also list modules that require external libraries to skip on Win32. Sounds good. 6. Add posibility to module developers (or anybody) to subscribe to FAIL reports. Right. Via email or RSS. It was discussed previously, how authors get notifications of RT issues, but don't get notificiation of the module smoke tests. 7. Dupe checks for reports. That would be good. 8. External libraries versions also should be included in report. That may require some support from EU::MM/M::B/etc. because one cannot know in advance which external libraries are used by the modules. 9. AFAIK reports from people not on cpan-testers/AT/perl.org list are manually checked. I don't want to subcribe to this list, if I want, I read it via NNTP. With http transport there is no need for such checks. What do you mean? 10. CPAN::YACSmoke should also store dependecies in it's DB. If it is testing module again it should report again it also if dependencies versions changed. Sounds good. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: A Suitable Iterator for TAPx::Parser
On Tuesday 19 September 2006 17:59, Ovid wrote:
- Original Message
From: Shlomi Fish [EMAIL PROTECTED]
my $parser =
TAPx::Parser-new(
{
stream = TAPx::Parser::Iterator-new($test_output_orig),
}
);
I'd recommend trying this:
my $parser = TAPx::Parser-new( { source = $source } );
I converted the code to use this convention in the svn trunk. Seems to work
nicely. Thanks for the advice.
I did that to simplify building parsers and it's new as of 0.30. $source
can be one of:
1. An array reference of TAP lines.
2. A complete string of TAP output.
3. A filehandle.
4. The path to an existing file.
The original interface is still available with a desire to not break
people's code (plus, I use it internally).
So far it seems to work well, with the only caveat being that filenames are
not permitted to have newlines in them (I forgot to document that). Thus,
if the iterator changes in the future, it hopefully won't break your code!
H you may wish to differentiate between #2 and #3 by saying that a
filename is passed as a plain string, while a string is passed by taking a
reference to it. That's what Template Toolkit and other modules are doing.
BTW, the documentation for the interface that the stream = argument
expects on the TAPx::Parser pod may be misleading:
Thanks. I need to clean that up, too!
No problem.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
A Suitable Iterator for TAPx::Parser
Hi all! I thought I could safely rely on using a Test::Run::Iteratory (essentially the same as Test::Harness::Iterator) object as a an argument to stream = in TAPx::Parser. However, then Ovid added more required to the iterator. Switching to TAPx::Parser::Iterator : http://search.cpan.org/~ovid/TAPx-Parser-0.30/lib/TAPx/Parser/Iterator.pm Solved this problem. However, the TAPx::Parser::Iterator POD says: FOR INTERNAL USE ONLY!. So, Ovid, what am I supposed to do? Can I safely use it? I'm just instantiating an object for a stream or an array and using it as is in Test::Run. Is this still OK? Else, should I roll up some iterator of my own? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: A Suitable Iterator for TAPx::Parser
On Tuesday 19 September 2006 15:03, Ovid wrote:
- Original Message
From: Shlomi Fish
Switching to TAPx::Parser::Iterator :
http://search.cpan.org/~ovid/TAPx-Parser-0.30/lib/TAPx/Parser/Iterator.pm
Solved this problem.
However, the TAPx::Parser::Iterator POD says:
FOR INTERNAL USE ONLY!.
Can you send me a short code example of how you're using it?
Sure:
# $test_output_orig is a ref to an array.
sub analyze {
my($self, $name, $test_output_orig) = @_;
my $parser =
TAPx::Parser-new(
{
stream = TAPx::Parser::Iterator-new($test_output_orig),
}
);
return $self-_analyze_with_parser($name, $parser);
}
sub analyze_fh {
my($self, $name, $fh) = @_;
my $parser =
TAPx::Parser-new(
{
stream = TAPx::Parser::Iterator-new($fh),
}
);
return $self-_analyze_with_parser($name, $parser);
}
That's it!
BTW, the documentation for the interface that the stream = argument
expects on the TAPx::Parser pod may be misleading:
http://search.cpan.org/~ovid/TAPx-Parser-0.30/lib/TAPx/Parser.pm
Reading from it:
* stream
The value should be a code ref. Every every time the reference is called, it
should return a chunk of TAP. When no more tap is available, it should return
undef.
I think I may be able to remove that notice now, but I'm not quite ready to
yet. Still, I do show provide examples of how to use it, so I guess that's
contradictory. Oops.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Integrating Test::Run with Module::Build
Hi all!
Today, after a long session of hacking on XML-Grammar-ProductsSyndication
(more about that later), I experimented a bit with integrating Test::Run into
a Module::Build build system. It turns out to be very easy, with just having
to add ACTION_runtest and ACTION_distruntest with the appropriate logic. My
complete Build.PL (for the Test-Run distribution) now looks like this:
use strict;
use warnings;
use Module::Build;
my $class = Module::Build-subclass(
class = Test::Run::Module::Build,
code = 'EOF',
use strict;
use warnings;
sub ACTION_runtest
{
my ($self) = @_;
my $p = $self-{properties};
$self-depends_on('code');
local @INC = @INC;
# Make sure we test the module in blib/
unshift @INC, (File::Spec-catdir($p-{base_dir}, $self-blib, 'lib'),
File::Spec-catdir($p-{base_dir}, $self-blib, 'arch'));
$self-do_test_run_tests;
}
sub ACTION_distruntest {
my ($self) = @_;
$self-depends_on('distdir');
my $start_dir = $self-cwd;
my $dist_dir = $self-dist_dir;
chdir $dist_dir or die Cannot chdir to $dist_dir: $!;
# XXX could be different names for scripts
$self-run_perl_script('Build.PL') # XXX Should this be run
w/ --nouse-rcfile
or die Error executing 'Build.PL' in dist directory: $!;
$self-run_perl_script('Build')
or die Error executing 'Build' in dist directory: $!;
$self-run_perl_script('Build', [], ['runtest'])
or die Error executing 'Build test' in dist directory;
chdir $start_dir;
}
sub do_test_run_tests
{
my $self = shift;
require Test::Run::CmdLine::Iface;
my $test_run =
Test::Run::CmdLine::Iface-new(
'test_files' = [glob(t/*.t)],
# 'backend_params' = $self-_get_backend_params(),
);
return $test_run-run();
}
EOF
);
my $build = $class-new(
module_name = Test::Run,
requires =
{
'Class::Accessor' = 0,
'File::Spec' = 0.6,
'Test::Harness' = 2.53,
'Scalar::Util' = 0,
'TAPx::Parser' = 0.21,
},
dist_version_from = lib/Test/Run/Obj.pm,
);
$build-create_build_script;
Now, the -do_test_run_tests() method is much shorter than its Test::Harness
equivalent. I had to copy and paste some code in the $self-ACTION_...
methods. Perhaps the M::B hackers would like to abstract the common
functionality somehow.
In other news, Test::Run now makes use of TAPx::Parser to parse the TAP. It
still collects the statistics on its own, because I couldn't remember whether
TAPx::Parser does that or not, and it was too much work to do at one time.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: todo tests in the TAP Plan
On Wednesday 06 September 2006 22:50, Michael G Schwern wrote: Shlomi Fish wrote: t/sample-tests/todo in the Test-Harness distribution reads: print DUMMY_TEST; 1..5 todo 3 2; ok 1 ok 2 not ok 3 ok 4 ok 5 DUMMY_TEST As one can see, the 1..5 plan is followed by the todo 3 2; directive. This is supposed to indicate something about plan ahead todo tests. (Instead of the # TODO directives in the individual tests' outputs. Now: 1. t/sample-tests/todo is being run by Test-Harness, which seems to think the not ok 3 is a todo test. 2. This todo-enabled plan is not documented in: http://search.cpan.org/~petdance/Test-Harness/lib/Test/Harness/TAP.pod 3. TAPx-Parser version 0.20 cannot handle it. -- I'd like to know what I should do about this feature, because right now I'm trying to convert Test-Run to use TAPX::Harness, and this is giving me problems. These old style todo tests were never really documented until I stumbled on them inside Test::Harness and Test.pm, nobody really understood, aren't very useful and weren't really used. They were deprecated a while ago. Since they were never really documented or used I just hid the deprecation notice inside Test::Harness as it was only interesting to folks hacking on it. This notice used to appear in Test::Harness but it appears to have been removed. =begin _deprecated Alternatively, you can specify a list of what tests are todo as part of the test header. 1..23 todo 5 12 23 This only works if the header appears at the beginning of the test. This style is Bdeprecated. =end _deprecated Don't push them forward into TAP. Any feature which relies on static test numbering is broken. Just let them die. OK, thanks. I'll forward-port this sample-tests script to the new # TODO syntax , and would not take measurements to handle this situation. Thanks for the heads up. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
todo tests in the TAP Plan
t/sample-tests/todo in the Test-Harness distribution reads: print DUMMY_TEST; 1..5 todo 3 2; ok 1 ok 2 not ok 3 ok 4 ok 5 DUMMY_TEST As one can see, the 1..5 plan is followed by the todo 3 2; directive. This is supposed to indicate something about plan ahead todo tests. (Instead of the # TODO directives in the individual tests' outputs. Now: 1. t/sample-tests/todo is being run by Test-Harness, which seems to think the not ok 3 is a todo test. 2. This todo-enabled plan is not documented in: http://search.cpan.org/~petdance/Test-Harness/lib/Test/Harness/TAP.pod 3. TAPx-Parser version 0.20 cannot handle it. -- I'd like to know what I should do about this feature, because right now I'm trying to convert Test-Run to use TAPX::Harness, and this is giving me problems. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: TAP ain't Test All Perl
On Monday 21 August 2006 17:48, Ovid wrote: - Original Message From: Adrian Howard [EMAIL PROTECTED] Of course this issue is nothing to do with any intrinsic property of TAP. There's nothing stopping TAP being integrated much more tightly - there just needs to be somebody with that itch to scratch. Except that there needs to be some movement on TAP again. There was a flurry of enthusiasm, upgrading the perl-qa wiki with plans for TAP::Harness, talks about subsequent versions of TAP, but then it died. Hell, I have the core in place to move on this, if only I could get an official blessing on it. Having heard nothing, I just gave up. I'd like to make use of TAPx::Parser in Test::Run. Another thing I'd like to do is extract all the non-core functionality from the main Test::Run module into plugins. I did not completely forget it, just was busy. Speaking of tests, I wrote Test::Count, and placed it on the CPAN: http://search.cpan.org/dist/Test-Count/ Its purpose is to keep track of the number of tests in a test script, by having meta-comments in the code. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: TAP ain't Test All Perl
On Monday 21 August 2006 21:56, Ovid wrote: - Original Message From: Shlomi Fish [EMAIL PROTECTED] I'd like to make use of TAPx::Parser in Test::Run. Another thing I'd like to do is extract all the non-core functionality from the main Test::Run module into plugins. I did not completely forget it, just was busy. Thanks! Let me know if there's anything you need changed which can support this. Sure. Speaking of tests, I wrote Test::Count, and placed it on the CPAN: http://search.cpan.org/dist/Test-Count/ Its purpose is to keep track of the number of tests in a test script, by having meta-comments in the code. No offense, but I can't tell from the docs how to use this. This has to be remedied, I guess. Quick primer: # TEST*[[EXPR]] add [[EXPR]] tests to the total. # TEST+[[EXPR]] does the same. # TEST:$VAR1=[[EXPR]];$VAR2=[[EXPR]]; are variable assignments. You can later use these variables in subsequent lines. Note that the space after the # is significant and TEST is always uppercase. But I'll write this in the POD. Regards, Shlomi Fish Cheers, Ovid -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Kwalitee metric: Community support channels
Hi Salve! See below for my comments. On Monday 24 July 2006 16:23, Salve J Nilsen wrote: Shlomi Fish wrote: On Wednesday 19 July 2006 17:08, Salve J Nilsen wrote: Just a wild thought... Would it be useful to check for references to community support channels like mailing lists, IRC channels, public bug trackers and official web pages? Interesting idea. One thing I should probably note is that ESR has this recommendation in The Cathedral and the Bazaar: [http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.htm l] [Shlomi's experiences using different community channels] What did I want to say? Yes, often the scope or maturity of the module does not justify a special community support channels. So I'm not sure whether penalising CPAN distros for not having this information is a good idea. But I'll have to think about it some more. I'd rather look at these metrics as a way of encouraging developers to think about issues around community sustainment. That way, we can use the game as a tool for software improvement in addition to improving the codebase. Sure, that's probably good. Which specific types of channels one should get points for may warrant discussion, but if our goal is the improvement of the software, we should at least encourage a mininmum number of ways to reach the users and developers of a software project. I would suggest giving a point for explicitly (and in a consistently machine-readable manner) stating the project's... * primary public bugtracker (frontpage URL) in use by it's users and developers Well, we have rt.cpan.org for free. I believe module-starter and friends can put it in the YAML by default, while allowing you to override with something else (in case you have your own different bug tracker, as is the case for Catalyst with their Trac.). +1. * main public mailing list (subscription URL) in use by it's users and developers Well sometimes people segment between the mailing list for developers and mailing list for users of the software. I was involved with the Subversion development for a while, and they had one common mailing list. Then they decided to separate it into [EMAIL PROTECTED] and [EMAIL PROTECTED] I should also note that there are other types of mailing lists: 1. Mailing list for Version Control Commits. 2. Wine-style Licence/flames mailing list. (Just kidding). 3. Mailing list for individual components (Mozilla style madness, where I can never determine where to post something). 4. Etc. * publically searchable archive of the mailing list (search page URL) Well, Google as well as mail-archive.com, yahoogroups, googlegroups etc. give you an archive and a search for free. The archive should be publicly accessible, and have some search functionality. I set up a htdig search for the entire Perl Mongers domain, and it was a pretty straightforward experience. * publically readable code repository (e.g. to a CVSWeb or SVN::Web frontpage URL) H... would a standard Subversion HTTP/S tree be enough? Instant communication channels like IRC and IM can of course be useful, but since the chat logs usually aren't stored and indexed publically, their lon term usefulness for the community are somewhat limited. True, but I solved many problems using IRC or at least got a lot of help. One could of course say distros that don't state ANY contact information or community support channels could be penalized, but I'd guess these developers probably don't care enough about their software or the game to feel much penalty from losing those points. Yes. The rest of us (the CPAN/Perl community) can still get all the good stuff, in addition to some hints on which projects one shouldn't expect any improvements or support. :) Yes. I daresay that sometimes a simple forward or developer email address is enough as a contact address. Recently I encountered some people in Israel (relatively new to the Internet scene) who seem to dislike mailing lists and prefer web forums and other mediums. Some of them even complained that some relatively low volume mailing lists were high volume, while in fact they were less than p5p and perl6-language, and much less than BugTraq or the Linux Kernel Mailing List. There is some software for multiplexing between a web forum, a newsgroup, a mailing list and an RSS feed, which could be useful. But we need to consider whether we also want a forum (a la Gabor's http://www.cpanforum.com/ ) as well. I wonder if there's anyway I can become automatically subscribed to all the distributions I've ever maintained on cpanforum.com? That would be cool. Gabor, can you shed some light on this issue? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day
Re: Kwalitee metric: Community support channels
On Wednesday 19 July 2006 17:08, Salve J Nilsen wrote: Just a wild thought... Would it be useful to check for references to community support channels like mailing lists, IRC channels, public bug trackers and official web pages? Interesting idea. One thing I should probably note is that ESR has this recommendation in The Cathedral and the Bazaar: It's fairly clear that one cannot code from the ground up in bazaar style [IN]. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn't try it. I didn't either. Your nascent developer community needs to have something runnable and testable to play with. When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future. http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.html I can attest from my experience that my most successful projects started from some code I wrote for myself, for some reason or another, and then finalised and released to the public. I usually didn't start a mailing list right away for them, and instead just publicised them on Freshmeat and collected the mails I received regarding them in my inbox, until there was enough to form a mailing list. Some of them still don't have a mailing list. In regards to IRC channels: I tend to avoid starting one IRC channel for every limited-scope Perl module I put on the CPAN. There are enough channels I'm trying to participate on Freenode as it is, and usually cannot concentrate on one or two channels at a time. I feel that such modules should be discussed on channels of larger scope like #perl. (Albeit larger scale projects such as POE, Catalyst/Jifty/etc. Perl-QA, etc. may justify their own channels). For example, LeoNerd and I have coordinated the development of Error.pm on #perl. Note that #perlcafe (on Freenode) is intended as #perl's chat channel, where one can also banish discussions that tend to flood #perl and have too little interest on the other #perl participants and lurkers. Another note is that I'm often not on the IRC on my waking hours, because I'm finding it too distracting and addictive. People can always reach me on IM or on Email: http://www.shlomifish.org/me/contact-me/ What did I want to say? Yes, often the scope or maturity of the module does not justify a special community support channels. So I'm not sure whether penalising CPAN distros for not having this information is a good idea. But I'll have to think about it some more. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.
Re: Test::More, BEGIN use_ok, plan, what?
On Friday 21 July 2006 19:50, A. Pagaltzis wrote:
Hi Adriano,
* Adriano Ferreira [EMAIL PROTECTED] [2006-07-21 15:20]:
If I run this script
use Test::More;
plan tests = 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says nothing about the use_ok. It is
not counted as a test, it does not ruin the plan, it does its
job (requiring and importing a foo subroutine).
I assume it’s because, despite the order in the file, the BEGIN
block runs before the `plan tests = 2` line.
Sure looks like a bug.
I don't think that it is. Perl preprocesses the files and at compile time
executes any BEGIN { ... } blocks it encounters and execute them before the
rest of the program. If you want to execute the plan at the beginning either
also put it in a BEGIN { ... } block, or use the use Test::More tests =
$num_tests directive.
It's not a bug - it's a feature. BTW, the use Perl keyword is also executed
in compile time. There's some equivalent code to it in perldoc -f use:
http://perldoc.perl.org/functions/use.html
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: [Slightly OT] Understanding Software Licences
On Saturday 08 July 2006 08:21, Adam Kennedy wrote: From my interpretation, what he said was I don't care to understand licenses enough so I don't want to be bothere with it. Now I think this is a rather small-minded approach to this issue, which I think is very bad. Perhaps, the response to Ovid about it instead of this message was not appropriate, or I may have misunderstood what Ovid said. ... What I did claim that people who refuse to understand the various common open source licences and when it is appropriate to use one of them, are acting small-mindedly (or small-headedly) in this context. For the record, I refuse to understand the various common open source licenses, and when it is appropriate to use one of them. So instead, for the win32.perl.org logo and the Strawberry Perl license bundling issues, even though I don't see a problem, on the advice of Randal and Allison I've asked to pass on the details of both issues to the TPF Intellectual Property lawyers for revue, and I've been lucky enough that I've been allowed to burn a few hours of their time on this issue. I may be ignorant, but I'm not naive, and I know it matters. But I shouldn't have to put in the effort to learn this stuff. And most of the people here are the same. They remain ignorant, not because they don't care, but because they prefer to defer to others who DO understand more than we ever could. This does not make them small-minded at all, just pragmatic. Fair enough. I prefer to be both knowledgable and pragmatic. I.e: hope I understand when something is legal, but also perhaps have to consult lawyers when in doubt. I should also note that licences such as the GPL are often mis-understood or can have various grey areas by anyone (including some lawyers). For example, recently after Solaris became OpenSolaris under a free software but non-GPL-compatible licence, some people wanted to start a Debian GNU/Solaris distribution. However, some people in Debian told them that the GPLed code in Debian could not be linked with the OpenSolaris standard libraries (libc, libm, etc.) that were non-GPL compatible. Obviously this is non-sense, because it was perfectly legal to build and distribute the binaries for the various GPLed GNU programs for Solaris and other proprietary Unixes (and MS Windows, too) before they became open source, because the GPL allow it. But still a concern was raised. My wiki page was not aimed at anyone personally - I was just trying to set up a good resource to better educate people about it. It's not a replacement for consulting with a lawyer on various fine points, but it can help to better understand the surrounding issues, and also make better decisions. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Using Perl in QA departments
On Saturday 17 June 2006 22:12, Gabor Szabo wrote: If anybody is interested on this list, the slides and the examples of my 2 days course are available here: http://www.szabgab.com/perl_in_test_automation.html Started reading them - they're very nice. Thanks for sharing them! One note I'd like to add: I believe that in: http://www.szabgab.com/talks/perl_in_testing/test-functions-improved.html You'd want to add: local $Test::Builder::Level = $Test::Builder::Level + 1; To the testing function, so it will correctly report the line from which it was called. (Because T::B uses caller()). Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
[Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
Hi Ovid! On Friday 07 July 2006 12:30, Ovid wrote: - Original Message From: Shlomi Fish [EMAIL PROTECTED] Not exactly. I suggested that if anyone is interested in working on Test::Run, he can file a proposal for a grant saying he'd like to work on it with me as a mentor. I still don't have anyone who can work on it. This is similar to Adam Kennedy's Strawberry Perl developer wanted: http://use.perl.org/~Alias/journal/29174 I oversee the grant committee but I don't speak for it so it's quite possible that what I say is wrong, but I'm willing to bet money that if someone requests a grant for Test::Run under its current license, it has ZERO chance of being approved. The grant committee members aren't lawyers and they're not going to sit around and wonder if the license is compatible, nor are they simply going to take your word for it. This kind of attitude was also said by another responder to this mailing list. It's sort of a small headed (see http://www.joelonsoftware.com/items/2004/12/06.html ) I just want to write code and am not interested in any legal details attitude. Well, I'm not a lawyer, either, but I still have a good amount of working knowledge about software licences and how they relate to each other. It's essential for a developer to have such a knowledge and not be completely oblivious of such issues, because for better or for worse - legal, ethical and moral issues affect the way we build, distribute, use and modify software. To battle such ignorance and give people (especially those with some non-negligible authority) a quick-and-dirty intro to such issues, I've set up the following wiki page: http://perl.net.au/wiki/Legal_Resources_for_Hackers I believe anyone can add things there, even without being logged in. There are other legal issues I'd like to add links there, but it will have to wait for later on. Regards, Shlomi Fish Of course, even with that little issue taken care of, I still can't say that Test::Run would be approved. We'd probably need evidence that the core Perl-QA people supported the project. We get enough grant requests in that we generally have to trust that those in the Perl community with the most experience in a given area know what they're talking about. Maybe that's not the best approach, but sooner or later we have to trust *someone's* judgment. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: [Slightly OT] Understanding Software Licences
On Friday 07 July 2006 17:07, Pete Krawczyk wrote: Subject: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]] From: Shlomi Fish [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 16:13:58 +0300 }Well, I'm not a lawyer, either, but I still have a good amount of working }knowledge about software licences and how they relate to each other. The former necessarily excludes the latter. Wrong. You can still be knowledgable about licences while not being a lawyer. And some lawyers are completely ignorant of the fact. For example, someone I know who now studies law in Israel had a friend who wanted to take a GPLed CMS, set it up on his site, and possibly customise it with some minor customisations. My friend told me he had to release his customisations to the public because that's what the GPL says upon any modification. However, the GPL (and any other free software licence) explicitly allows making a use or modification for in-house or internal use without being obliged to release them to the public. (see Freedom 1 in http://www.gnu.org/philosophy/free-sw.html ). So he misled his friend, while I was more knowledgable about it. And obviously lawyers who didn't specialise in Copyrights or Software law may not be completely aware of its finer points. (Possibly less so than many clueful programmers who are not lawyers). For the record, it is possible to be interested and knowledgable about law, without having a Law Diploma. This is similar to the fact that you can program without having a B.Sc. in Computer Science or whatever. Are you familiar with contract law in America? Finland? Australia? Do you know what other people with far more expertise than you have said about this issue? Contract Law? From what I know FOSS licences are licences, not contracts. See: http://lwn.net/Articles/61292/ I'm not sure even EULAs are contracts. http://www.gnu.org/philosophy/license-list.html says: License of Perl This license is the disjunction of the Artistic License and the GNU GPL--in other words, you can choose either of those two licenses. It qualifies as a free software license, but it may not be a real copyleft. It is compatible with the GNU GPL because the GNU GPL is one of the alternatives. We recommend you use this license for any Perl 4 or Perl 5 package you write, to promote coherence and uniformity in Perl programming. Outside of Perl, we urge you not to use this license; it is better to use just the GNU GPL. Gee, even the FSF and RMS himself say, Use the Artistic for Perl code! RMS also says it is usually preferable to use the GPL for everything you write. I, however, like to use BSD-style licenses for all the software that I originated: http://www.shlomifish.org/open-source/projects/ I can tell you from my experience that one of my projects would not have become half-as-successful as it has been, if it had been released under the GPL instead of the Public Domain. Note that if I did not originate a certain piece of code, I contribute my code under the same terms, and also disclaim any implicit or explicit ownership of my contributions (to facilitate a future re-licensing). Thus I have GPLed modifications in the GIMP, GPL+Artistic modifications for perl*.pod and for CGI.pm, and Apache licence modifications in Subersion. (Along with some smaller patches to many other modules). I'm not saying this because I'm anti-GPL or pro-BSD-licence or whatever. But I prefer to license Perl software under a BSD-style-licence for the same reason I'm licensing my C programs under them. }It's essential for a developer to have such a knowledge and not be }completely oblivious of such issues, because for better or for worse - }legal, ethical and moral issues affect the way we build, distribute, use }and modify software. And as a developer, I defer my less-knowledgeable position to what those before me have found and discussed. I make all my contributions available under the license of Perl, and other licenses as appropriate (my 2005 YAPC talk is also licensed CC at the request of the conference organizers, for example). I have also signed the form that gives explicit licensing for any contribution I make to Perl to the TPF under their preferred terms - have you done the same? http://www.perlfoundation.org/legal/licenses/cla.html All code I originated and which I've decided to distribute as open source is either under the Public Domain or MIT X11. These licences allow anyone to relicense them under any other licence. (While the original will still remain OK.) All of my public creations (articles/essays, humourous stories and bits, photographs, artworks, etc. see http://www.shlomifish.org/ ) are publicly re-distributable. Most of my articles and essays are CC-by, most of my larger scale stories are CC-by-sa, and graphics and photographs
Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
Hi Chris! On Friday 07 July 2006 17:04, Chris Dolan wrote: On Jul 7, 2006, at 8:13 AM, Shlomi Fish wrote: This kind of attitude was also said by another responder to this mailing list. It's sort of a small headed (see http://www.joelonsoftware.com/items/2004/12/06.html ) I just want to write code and am not interested in any legal details attitude. May I suggest a compromise? As the author of the MIT-licensed code in Test::Run, Shlomi has the option of releasing the code under any license he prefers. Shlomi can releases *two* versions of Test::Run with every update -- a mixed license version and an Artistic/GPL version. With that solution, Shlomi himself shoulders the burden of resolving license compatibility and tracking which line of code is under which license. Right. Finally a reasonable approach. Thanks. I do believe that the quest for license simplicity in the Perl core is not small headed or rooted in ignorance, but is instead inspired. I didn't say it was. What I wanted to say is that people should have the minimal knowledge to understand that MIT X11 licence is compatible with GPL+Artistic (where Artistic is 1.0 or 2.0) code and can be re-licensed to it at will, even without requesting permission from its originators. In regards to putting it in the core - there's still a long way to go before Test::Run and its auxiliary modules are suitable for being placed in the core. When and if this is going to happen we'll see what I have to do about it. But we should cross the bridge when we get to it. Until then I believe that licensing my newly written code under the MIT X11 licence is a long-term benefit *because* it can be re-licensed to a different licence without asking anyone for permission. While many developers or TPF itself could easily delve deep enough to decide whether MIT/BSD licensed code in the core is a threat, I think that would be a wasted effort. The increased complexity of licensing (whether real or perceived) could easily turn off third parties with less dedication to Perl, thereby decreasing the attractiveness of the language. Right. I don't mind my BSD-licensed code to be re-licensed as GPL+Artistic before entering the core (when and if it is going to enter the core). But I'd like to keep it as BSD-license until then, and hopefully be able to maintain it as BSD on CPAN separately afterwards. After all, software engineering is largely about reducing the exposed complexity of a project. Right. I should note that it's not as if one .pm file is BSD and its neighbour is GPL+Artistic in the Test::Run svn repository. I have several directories each for every CPAN distribution. The Test::Run distribution was derived from Test::Harness and is such Perl-licensed. The Test::Run::CmdLine distribution which was re-implemented from scratch and serves as its command line backend is X11-licensed. The plugins are also BSD-licensed as they were re-implemented from scratch. And finally Test-Run-TAP-Model, which is a port of Test-TAP-Model for Test-Run is also GPL+Artistic, because it is derived work. I daresay this thread did not quite meet my expectations, possibly because of bad phrasing of the original proposal on my part. What I wanted to say is: 1. Test::Run could use some work. 2. If anyone wishes to work on it and get paid, he can try getting a grant from TPF. 3. I'm not interested in such a grant as I already have a full time job. However, I can act as a mentor. 4. a) Code that originated from existing Test::Harness code or is somehow associated with it, should be kept as GPL+Artistic. b) New plugins, wrappers, etc. should preferably be MIT X11. In any case, the author can specify any common and GPL-compatible licence in the Copyright section of the POD in the directory in which the module resides in. -- This is what I wanted to say on one leg. Maybe my over-wordy description was not clear enough. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
On Friday 07 July 2006 18:39, Andy Lester wrote: Those who disagree with Shlomi on licenses are small-headed and ignorant. Got it. Keep digging that hole, Mr. Fish! That's not what I said or meant. What I meant was that someone here said and I quote: http://www.mail-archive.com/perl-qa%40perl.org/msg06038.html Personally, I'm happy enough to sign my modules as licenced under the same terms as Perl itself, thereby letting other people deal with a matter for which I have next to no interest in. My own take on this is that even if your code was better, I wouldn't use it, since I couldn't be sure that my use of it may in some way violate its terms. At least I know where I stand with the GPL and AL. Life is short, and the less I have to think about licensing issues, the better. From my interpretation, what he said was I don't care to understand licenses enough so I don't want to be bothere with it. Now I think this is a rather small-minded approach to this issue, which I think is very bad. Perhaps, the response to Ovid about it instead of this message was not appropriate, or I may have misunderstood what Ovid said. You said: Those who disagree with Shlomi on licenses are small-headed and ignorant. Got it. That's not true. Like I said - I release all my original software under BSD-style licences. Some people would believe that the GPL or the LGPL would be more appropriate for it. So they and I disagree. But I do not claim they are small-headed and ignorant. What I did claim that people who refuse to understand the various common open source licences and when it is appropriate to use one of them, are acting small-mindedly (or small-headedly) in this context. Please do not try to give your own labeling interpretation to what I said before you made sure you understand what I'm saying. (I'm reachable on IM during most of my waking hours, if you want to ask me to clarify things.). I think I've spent enough precious time and energy on this thread, which is pretty much useless. And my head hurts from trying to understand what we're fighting about. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Proposal Suggestion - Test::Run
On Thursday 06 July 2006 00:36, Jonathan T. Rockway wrote: Two comments, pretty much agreeing with chromatic and Ricardo: 1) How would this proposed module benefit the perl community? Why can't you fix things in Test::Harness and send the patch in? If you fix deployed modules, everyone wins. If you write your own module, it sits on CPAN unused. What exactly is wrong with Test::Harness, anyway? The development team is pretty agreeable, the code is good, the module works, etc. Is there some large problem I'm missing? (A problem so large that TPF needs to *pay* someone to fix it!?) I've answered some of these things in the following links: http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/ http://use.perl.org/~Shlomi+Fish/journal/27467 http://use.perl.org/~Shlomi+Fish/journal/27887 Also see my other replies to this thread: http://www.mail-archive.com/perl-qa%40perl.org/msg05987.html And also the resource that Schwern pointed to: http://www.mail-archive.com/perl-qa%40perl.org/msg06014.html 2) If you use GPL'd code in an MIT-licensed app, the entire app becomes GPL. I don't think you can say, this requires xyz GPL'd code, but if it didn't it would be MIT. It's GPL by virtue of requiring GPL code. (Hence the accusation that the GPL is 'viral' or whatever.) IANAL, but this is my understanding from reading the license, the FSF's site, etc. If the code isn't derived, though, feel free to MIT license it. There is a difference between derived code and inclusive code. The code that originated from other people's code was kept under the same licence (GPL+Artistic in this case). I also disclaimed any explicit ownership of it. OTOH, the code that was written from scratch and was my original code was licensed under the X11 licence, because it did not include anything else. (The fact of the matter, though, is that Perl uses the Perl license. I don't really love the Artistic license, but I release my perl code under the dual license because Everyone Else Does. I don't like doing everything only because everyone else does them. I like to think for myself what is the best course of action and long time strategy. It makes everything work nicely and builds community too :) I don't see using the X11 licence for my software as anti-social. Like I said, anyone can easily fork it as a software of a different licence. It's also more permissive than the GPL+Artistic licence (and much less problematic than the Artistic 1.0 licence, which some people don't even consider as free-as-in-speech.) So far I've released all the software (Perl or otherwise) for which I had a choice under the Public Domain or X11 licence. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]
Hi all! I'd like to suggest a generic proposal for the Perl Foundation Grants. Note that I'm not going to take it myself, because I just started a new job and would like to commit to it. However, I can be the mentor for this grant. I'm posting it here to get some reactions before I put it in my use.perl.org journal, etc. The grant is about Test::Run, which is a fork of Test::Harness that aims to greatly refactor and modularise it. I've already revamped and re-written a lot of code for it, but there's still a lot that needs to be done. Here are some Test::Run links: 1. Lightning Talk about Test::Run - http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/ 2. use.perl.org journal entries: http://use.perl.org/~Shlomi+Fish/journal/27467 http://use.perl.org/~Shlomi+Fish/journal/27887 (they contain a lot of links). --- Licencing Issues: = Some of the code in Test::Run is derived from the code of Test::Harness, which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code was written from scratch and due to my personal preferences, it was licensed under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 licence, and that existing code will retain its original licensing terms. Comparison with Similar Efforts: * Test::Harness is the old harness module of Perl 5, from which Test::Run was derived. It is not very Object Oriented, suffers from some modularity issues, and is generally hard to properly adapt. Often, customisations to it need to be kept and maintained in house. Test::Run is no longer backwards compatible with Test::Harness. The internal and external interface was changed. * TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. It has similar goals to Test::Run, but has a different methodology of trying to achieve it. * TAP::Parser by Ovid is a work-in-progress module that aims to be a modular event-based parser for TAP output. Test::Run may eventually convert to use it instead of its current ad-hoc TAP handling routine (that was inherited from Test::Harness). Orthogonal to all of these are the various Perl and non-Perl TAP generators such as Test::Builder, Test::Simple, Test::More, Test::Base, and the http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness/TAP.pod#Non-Perl_TAP . Test::Run and friends are not concerned by them as long as the script that performs the tests' generates correct TAP. Scope of the Project: = This project aims to do the following: 1. Finish refactoring Test::Run::Obj, Test::Run::Straps and the other modules derived from Test::Harness. One should probably have read Refactoring by Martin Fowler, for some indication on which bad smells exist in bad code, and how bad code should be methologicaly refactored if it has them. Perl Best Practices is also possibly a good read. (albeit I only began reading it). 2. Move some of the functionality of Test::Harness that's currently in the Test::Run::Obj core into plugins. 3. Update the POD documentation for the new version. 4. Extend (using plugins, etc.) for: - Formatting the messages using templates or callbacks. - Colours in the output. (Already exist to some extent). - HTML, XML and YAML (and others) Output. - Persistent Running. - Interrupted GUI running. Michael G. Schwern also suggested the following: (in the context of TAP::Harness) Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a URL and get the TAP from that; run HTML through a validator which produces TAP; run a C program which spits out TAP), enhanced TAP output (ex. colors; levels of verbosity), and the ability to smoothly handle TAP extensions. Roles in the Project: = Like I said I'm going to be the mentor for the project, not the one who actually performs it. The one who takes it will receive most (or all) of the money of the grant while doing most of the work on Test::Run. I will aid the project proposer by giving him a Berlios.de developer status for the Test-Run project (with Subversion commit access) and also eventually make him a CPAN co-maintainer for the appropriate namespaces, so he can upload modules there. One note is that so far I did most of the work on Test::Run, and so no-one else has much first-hand experience with it. However, I believe any prior experience with the Test::Harness code or even with Perl 5 testing in general will do, and I'll be glad to help any newcomer feel comfortable with the code. I can be reached in the following means: http://www.shlomifish.org/me/contact-me/ Regards, Shlomi Fish [1] - The MIT X11 Licence ( http://en.wikipedia.org/wiki/MIT_License ) a BSD-style licence that is almost entirely public
Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]
On Wednesday 05 July 2006 23:51, Ricardo SIGNES wrote: * Shlomi Fish [EMAIL PROTECTED] [2006-07-05T15:28:28] The grant is about Test::Run, which is a fork of Test::Harness that aims to greatly refactor and modularise it. I've already revamped and re-written a lot of code for it, but there's still a lot that needs to be done. [...] Some of the code in Test::Run is derived from the code of Test::Harness, which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code was written from scratch and due to my personal preferences, it was licensed under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 licence, and that existing code will retain its original licensing terms. [...] TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. So, you want to have someone (other than you) work on a project that largely seems to duplicate the functionality of existing code. Among the existing code whose functionality is being duplicate is code still under development. Let me try and understand what you mean and explain what I want. Test::Run was started before TAP::Harness in the aim to transform Test::Harness into something more modular. A large part of this goal was already acheived, see what exists now at: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ Among the tasks that were achieved so far in Test::Run are: 1. More tests were added. 2. An almost complete Object-Oriented interface instead of a procedural interface. 3. Many long functions were broken into smaller one. 4. All the command line and %ENV handling was moved into a separate module. 5. A plugin interface was defined and several plugins were written. But like I said there is still a lot of work to be done. Now TAP::Harness was started several months after the first release of Test::Run. Its aim is to provide another implementation for processing TAP, which from what I understood will share much of the goals. The other project is being done with no TPF funding and will be capable of becoming part of the core in future Perls, largely superseding the existing test framework. So hopefully will Test::Run. Except that now that I have a full-time job, it would be nice if someone can work on it as well as me. You want funding for a parallel project that will be not be license-compatible with the core. Test::Run is licence-compatible with the core. Some of Test::Run is licensed under the GPL and Artistic (version 1.0) licence which is the licence of the perl 5 core. The other part is licensed under the MIT X11 license which can be freely linked against each one and can also be converted to the Perl dual-license by anyone who re-distributes the code. And like I said, I don't want the funding for me - I want it for someone who volunteers to work on the project. I don't see how this would be worth TPF's money. It might be a very useful project for people who use the code or for people who want to steal ideas, but I don't see how it fills a really critical void in the language or its toolset. Please read my answers above and also re-read my original draft of the proposal. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]
On Wednesday 05 July 2006 23:55, chromatic wrote: On Wednesday 05 July 2006 12:28, Shlomi Fish wrote: I'd like to suggest a generic proposal for the Perl Foundation Grants. Note that I'm not going to take it myself, because I just started a new job and would like to commit to it. However, I can be the mentor for this grant. I'm posting it here to get some reactions before I put it in my use.perl.org journal, etc. You want TPF to pay some unspecifed and unidentified other person Not exactly. I suggested that if anyone is interested in working on Test::Run, he can file a proposal for a grant saying he'd like to work on it with me as a mentor. I still don't have anyone who can work on it. This is similar to Adam Kennedy's Strawberry Perl developer wanted: http://use.perl.org/~Alias/journal/29174 Albeit mine was possibly too badly phrased. to continue a fork of a core module that can't ever replace the core module because of its licensing? Test::Run has no licensing problems. Some parts of it are under the Perl dual-license. The other parts are under the MIT X11 license. One can easily re-license MIT X11-licensed code under any other licence. Sheez... Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP::Harness
On Sunday 02 July 2006 23:37, Adam Kennedy wrote: The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit. With Adam Kennedy's permission, I can also move the files to his Subversion repository, where everyone with a PAUSE ID can commit to. I'd prefer not to add it at this point. That's not so much because of the code itself, but because currently it's MY repository for the module _I_ maintain, please a few other things I'm very very tight with and likely to have to do releases for anyway (PITA/Win32). They are structured a certain way, the licenses must be Perl (at present the dist-builder would change your license at release time) and it's build around the way I do things. While it might some time in the future end up as the kernel of some sort of larger svn.cpan.org it is absolutely NOT that at the moment. That particular issue is one I want a year or so of experience with the current setup under my belt before I address. But you also have dozens of modules, so I imagine it would be worth you just creating your own setup, be it Trac, Insurrection (assuming you can get the damned thing installed) or otherwise. That way you're able to set it up as you like, rather than me forcing my structures and policies onto you. I'm sorry but I don't have the time, energy or money resources to set up my own CPAN-wide Subversion hosting like that. At the moment I prefer to use a Subversion hosting maintained by someone else or by a Subversion hosting provider[1], rather than start messing with a setup like this under my own responsiblity. Similarly, I can't seem to be able to maintain (install, upgrade, keep spam clean, etc.) several web-apps on several different hosts, and would rather get providers that provide such services (like Wikia for MediaWiki, etc.). If I encounter a problem there - it will be fixed, not only for me but for everyone. Hostings I already have: 1. Subversion at http://stalker.iguide.co.il:8080/svn/shlomif-homepage/ . I'm keeping the sources of my homepage there because some of its content may not be open-source, and I feel that it won't be nice to use http://opensvn.csie.org/ or whatever for that. But I may be wrong, and it is not against the policy of some Subversion providers. I have a shell account on stalker, and occasionally need to compile Subversion, Apache 2, etc. However, I might get my admin to install these packages from the Debian pool. 2. http://www.shlomifish.org/ - this is an entirely static (but pre-rendered) site that serves as my homepage. It is hosted at http://eonspace.net/ [2] and I've moved it there so it will have good bandwidth. I have ssh access there, and am using rsync to upload the files. I once tried to install YaBB there, but my hostmaster and I failed due to some obscure Apache configuration problems. Maybe I'll have better luck next time, but at the moment, I don't have an immediate need for anything dynamic. (Except perhaps a small script or two.) 3. http://www.iglu.org.il/ - this is a community site that I got burried in maintaining. I have a root password for it. While I have some stuff there, I tend to avoid using it for anything serious, because the server is rather under-powered and the connectivity to anywhere except Israel tends to be slow. My homesite used to be hosted there, but it has been moved to eonspace.net. --- What I'm trying to say is that the last thing I need right now is to buy a server of some sort and put and maintain Subversion on it, and I believe that's the case for other people. And I think one central Subversion server (with some mirrors) is better than several dispersed ones. Adam, in case you have the configuration of the server (scripts, conf files, etc.) available somewhere public, I could try helping you once you're ready for it. No promises though. The number of tasks on a project's todo list always grows or remains constant, and so do the number of projects a developer is involved in. Regards, Shlomi Fish [1] - http://subversion.tigris.org/links.html#hosting [2] - Yes, I know there's nothing much there yet. - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP::Harness
On Sunday 02 July 2006 01:24, Michael G Schwern wrote: On 7/1/06, Shlomi Fish [EMAIL PROTECTED] wrote: One thing I'm wondering about is whether you are going to code all of this into TAP::Harness from scratch. I believe I mentioned, I intend to steal lots of code from Test::Harness and Straps. Steal in the cut paste sense. I have already adapted much of Straps-analyze_line as well as copied Point and Results wholesale. OK. Good. Folks might cringle at the cut paste, but I do not TAP::Harness to have any dependencies upon Test::Harness. Plus, I've also been planning similar things for Test::Run too, (and already started implementing to some extent) I glanced at Test::Run today and had two initial observations. 1) Your licensing is possibly incompatible. You're using a mix of MIT X11, BSD and Artistic. I'm not familiar with the former two. I can't use anything not licensed Perl style. For one, it will not be able to enter the core. OK, OK. Let me explain. When I say BSD there, it's actually MIT X11 and that's because the MIT X11 licence falls under the BSD licenses. The reason it says so is because module-starter did not have a choice for MIT X11, and so BSD was the closest thing. Not what are MIT X11/BSD? They are Public Domain-like licences that basically allow *almsot anything* to be done with the code (including relicensing under any different licences). For more information see: http://www.faqs.org/docs/artu/ch19s05.html http://blogs.zdnet.com/Burnette/?p=130 http://blogs.zdnet.com/Burnette/?p=131 Now where it was used? Whenever I wrote entirely new code, from scratch. And I used the MIT X11 licence because I like to use it for code I'm starting from scratch, because it's the closest one get to Public Domain but keeping it copyrighted and without the warranty clause. There isn't any legal problem because MIT X11 is compatible with anything, and you can relicense it to the GPL+Artistic or whatever, or include it at the core using this licence. 2) I think your model does not perform a clean enough break with Test::Harness compared to what I'm planning. I realize this claim is vapor until I post the design. Yes. PS You might want to fix your copyright notices. I thank you for retaining our copyright for our portions of the code you took from Test::Harness but we do not have copyright over Test::Run::Obj, for example. IANAL so I don't know what should be there, but it probably shouldn't just be me and Andy. Test::Run::Obj is derived from Test::Harness. From what I recall, I left the copyright notice verbatim from Test::Harness. (and to not complicate things further, diclaimed any ownership of my own changes). I'd hate to see some duplicate effort. Sometimes you have to make a clean break with the past. The code in Test::Harness was started almost 20 years ago. That's right, t/TEST in Perl 1 became Test::Harness. Its designed along procedural lines and we've been trying to slowly morph it into a more flexible model over the years and still haven't succeeded. Its not a large or complex module, it should not take this long I see. Further, I think the duplication is healthy. Part of the problem with Test::Harness is its the only game in town. Its the only thing which can parse TAP. Its very bad for a protocol to have only one implementation. The monolithic and inflexible nature of Test::Harness has held back Perl testing in the last few years. Having more than one TAP harness implementation will be healthy. OK. I'm starting over. You're free to do whatever you want. Please do not consider this email as an attack against your attempt to write code or fix what's broken with Test::Harness. I don't mind having some competition. However, I'm trying to see whether there is some way we can consolidate our efforts. Licencing issues mentioned above prevent any code sharing, but I'll look at your lightning talk and see what ideas I can steal. Thanks. And like I said the licencing issues are non-existent. If you wish, you can take my original MIT X11 code and relicence it with the GPL+Artistic licence. But you can also safely use it as it is, which would be preferable. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP::Harness
On Saturday 01 July 2006 22:36, Michael G Schwern wrote: Those of you who were/are at the YAPC Hackathon might know, I've begun work on what started as Test::Harness 3 and is now TAP::Harness. This is brand new, ground up rewrite of the idea of a harness for TAP sources (a foo.t file is a TAP source). Its being designed to be extendable to handle all the things we'd like to do with Test::Harness over the last few years without having to worry about backwards compat. . . . * Will I be able to do X with TAP::Harness? The goal is to encompass the largest set of X. Another goal is to have the extender be able to focus on the display aspects and not the TAP parsing. Right now the use cases I have in mind include things such as parallelized test runs, fancy GUI and HTML outputs (for example, TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a URL and get the TAP from that; run HTML through a validator which produces TAP; run a C program which spits out TAP), enhanced TAP output (ex. colors; levels of verbosity), and the ability to smoothly handle TAP extensions. I can't readily think of other stuff now. One thing I'm wondering about is whether you are going to code all of this into TAP::Harness from scratch. Plus, I've also been planning similar things for Test::Run too, (and already started implementing to some extent) and I'd hate to see some duplicate effort. As some of the people who may know I like to start from an existing codebase when I can. This may be due to a bit of hacker's superstition as backed up by: http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html (Not to mention Things you should never do part 1 and Rub a dub dub by Joel Spolsky).[1] Now, I started Test::Run so it will be an incompatible Test::Harness-like module, only more modular, object oriented, pluginnable, etc. I found the Test::Harness code to be somewhat lacking in some respects, but believed (due to my superstition) that I can bang on it until it exceeds its current limitations. I hope the Test::Harness maintainers can understand that I had no intentions of fragmenting, but rather as a way to create a better harness. Test::Run still has many issues, but I think that it will still be easier to start from it than from an empty code. I didn't make a stable release of Test::Run yet, and would not recommend people to depend on its API being stable, so everybody's who's interested can go there and even break the API (as long as he also fixes the tests.) Refactoring and extension of existing code is much more brainless than starting to work on a brand-new codebase, and is more rewarding. Please do not consider this email as an attack against your attempt to write code or fix what's broken with Test::Harness. I don't mind having some competition. However, I'm trying to see whether there is some way we can consolidate our efforts. The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit. With Adam Kennedy's permission, I can also move the files to his Subversion repository, where everyone with a PAUSE ID can commit to. A lightning talk I gave at two occassions (OSDC::Israel::2006 and an Israel.pm meeting) can be found here: http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/ * Will TAP::Harness include X extension to TAP? No. TAP::Harness is using the current TAP spec from Test::Harness::TAP. Extending TAP is another problem. It may be a good idea to have a parser that outputs an events' stream and an analyzer that reads and analyzes the events. Then we can have a different protocol than TAP. Regards, Shlomi Fish [1] - Another module which I did not write from scratch is HTML::Widgets::NavMenu. I was looking for alternatives on CPAN, found 3, and chose HTML::Widget::SideBar by Yosef Meller (a fellow Israel.PM-er). http://search.cpan.org/dist/HTML-Widget-SideBar/ Overtime I had to patch the module, subclass it and write some glue around it. Eventually, I wrote my tree-generation logic for generating a site map, and ported the rest of my code to it, leaving my module with none of Meller's original code. Would it have been easier to re-write everything from scratch? I can't tell for sure, but in any case, it was less intimidating to start from scratch. ESR has other stories like that. - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test::Harness wrangling
On Thursday 29 June 2006 13:27, Michael Peters wrote: Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? Not a bug, but a feature request. Abstract out the TAP parsing into a separate module so that it can be done by more than just Test::Harness::* modules. A very good idea, which was already discussed in the Perl blogospher. Here, if I remember correctly. What other people said they would like to see is some kind of an event-driven parser, with the events being transmitted to a sub-class or a different class or callbacks. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Monday 24 April 2006 01:46, Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. Am I missing something or isn't that what Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can extract a class out of Test::Run::Straps that will provide a reusable TAP parser. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 23:11, chromatic wrote: On Sunday 23 April 2006 12:46, Shlomi Fish wrote: I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) No. I see. Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? No, why should it? I meant that writing several test harnesses would imply that. It was a semi-rhetoric question. Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? I don't believe that plugin systems reduce complexity in general. I do strongly believe in customization, but I remain unconvinced that plugins promote reuse and customization as strongly as, for example, roles and subclasses do. I see. Well the final conclusion remains the same: we still need a good test harness that we should be able to customise using roles, subclasses, plug-ins or whatever. I still don't see where the well-definition of the test output protocol has anything to do with this issue. How would a well-defined test output protocol help with making the test harness customisable? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Generator for Modules-Installing Makefiles
On Thursday 06 April 2006 22:34, Adam Kennedy wrote:
Wow, what great timing :)
To add to your use case, on the project I'm currently working on, we
have 5 CPAN-style dists, probably 10 by the time we are done, but they
all need to be installed in a particular order.
Due to the peculiarities of the situation, doing a CPAN::Inject style
setup isn't going to work for us.
Is this usable in that sort of situation?
I think so.
If so could you demonstrate the usage?
Just specify the directories in which these distributions reside in the order
in which you want to have them installed. (as arguments to --dir for the
script). Then type make to build, test and install all of them.
You may need to tweak the script a little to add various parameters at various
stages.
Regards,
Shlomi Fish
Thanks
Adam K
Shlomi Fish wrote:
Hi all!
As part of developing Test::Run, I maintain several CPAN modules and
install them to a directory under my home-dir. Now, until today what I
did was write a bash function to run the installation commands (perl
Makefile.PL PREFIX=$FOO, make, make test, make install, or the
Module::Build equivalents), one by one for each of the modules. However,
if one of the commands would have failed, it would still proceed.
A long time ago, I thought of a better idea in which I generate a
makefile that will run the commands and break if one of them fails.
Today, when I needed to update the list of installed modules, I decided
to catch two birds with one stone, and wrote the makefile generator. I
wrote it in Perl and it is included below. (it is licensed under the MIT
X11 licence).
Now here's how I'm using it. In my bash theme ([1]), I have:
__prepare_install_all_to_temp_makefile()
{
(
perl ~/bin/gen-perl-modules-inst-makefile.pl \
--prefix=$inst_modules_dir \
-o $modules_makefile \
--dir=$test_run \
--dir=$cmdline \
--dir=$modules_dir/plugins/backend/Test-Run-Plugin-ColorSummary \
--dir=$modules_dir/plugins/cmdline/Test-Run-CmdLine-Plugin-ColorSummary
)
}
This is the function that calls the generator script to prepare the
makefile.
And then I use this makefile by calling make all to build, test and
install all the modules one by one, or make $(pwd) to build one of
them.
I hope you'll find this piece of advice useful.
Regards,
Shlomi Fish
[1] - http://www.onlamp.com/pub/a/onlamp/2006/02/02/bash_themes.html
Here's the script:
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
my $o_fn = -;
my $prefix = /usr;
my @dirs;
GetOptions (
o=s = \$o_fn,
prefix=s = \$prefix,
dir=s\@ = [EMAIL PROTECTED],
);
my $text = ;
sub process_dir
{
my $dir = shift;
if (-e $dir/Build.PL)
{
process_mb_dir($dir);
}
elsif (-e $dir/Makefile.PL)
{
process_eumm_dir($dir);
}
else
{
die Unknown install method for directory $dir.;
}
}
sub process_eumm_dir
{
my $dir = shift;
handle_deps($dir,
[
perl Makefile.PL PREFIX=\$prefix\,
make,
make test,
make install,
]
);
}
sub process_mb_dir
{
my $dir = shift;
handle_deps($dir,
[
perl Build.PL,
./Build,
./Build test,
./Build install prefix=\$prefix\,
]
);
}
my $id_num = 1;
sub handle_deps
{
my ($dir, $deps_ref) = @_;
my @deps = reverse(@$deps_ref);
my $id = target . ($id_num++);
$text .= ${dir}: $id-step0\n\n;
foreach my $i (0 .. $#deps)
{
$text .= $id-step${i}: .
(($i == $#deps) ? : ($id-step . ($i+1))) .
\n;
$text .= \t(cd $dir . $deps[$i] . )\n;
$text .= \n;
}
}
foreach my $d (@dirs)
{
process_dir($d);
}
if ($o_fn eq -)
{
open O, STDOUT;
}
else
{
open O, , $o_fn;
}
print O all: , join( , @dirs) . \n\n;
print O $text;
close(O);
--
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.
