acme (email not shown publicly)
http://www.astray.com/
Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.
Fix the sorting (Score:2)
--
xoa
Re:Fix the sorting (Score:2)
--
xoa
Re:Fix the sorting (Score:2)
Make it configurable from out of the package ... (Score:1)
I mean, if I don't want my module to be tested (grin), I should be able to say that.
Maybe I want to be kept up-to date on the testing progress, so a test email - to send results to - would be a nice config.
Johan
Perl Version on 'show' page (Score:1)
Perl Version... and more (Score:2)
Could we somehow specify in some standard way what kind of configuration is important for testing?
An example (at random ;--): as far as I know XML::Twig couldn't care less whether the perl it runs on is multi-threaded or not, the architecture itself is not even that important, beyond the basic Windows/*nix thingie. But the version of Perl, XML::Parser, Scalar::Utils and expat are important, and they don't appear in the main page.
A standard way to specify a string that would identify a configuration would
mirod
Re:Perl Version... and more (Score:1)
I include a test script in each distribution solely for the purpose of dumping out version numbers of the packages I depend on. For example: XML-Simple:t/0_Config.t [cpan.org].
Then when I get a test failure report like this [perl.org], I can see at a glance the test machine has an old verson of LibXML with buggy namespace support.
Re:Perl Version... and more (Score:2)
Good idea, especially as I check the version numbers during the perl Makefile.PL phase, I'll add something like this in the next release.
Thanks
mirod
Re:Perl Version... and more (Score:1)
Cheers
Arthur
sky
Re:Perl Version... and more (Score:2)
I realize the architecture is very important... for some modules. I know that in my case it doesn't matter whether threading is on or off for example. In the end, other factors are way more important, and yet they do not appear on the main report.
mirod
Re:Perl Version... and more (Score:1)
Your module runs on the perl interpreter, and if two different architectures make the interpreter run totally different code, or in a totally different way, then that architecture setting is important to your module, and also, more importantly perhaps, to other people who wish to see the testers result for your module.
Cheers
Arthur
sky
Re:Perl Version... and more (Score:2)
There are lots of things that are important, amongst which, for XML::Twig, the architecture is one of the least important. So having the test report only display the architecture is not as much help to users (or to me) as displaying the rest of the significant environment.
If I wanted to push the discussion further I might even go as far as to say that it would be more useful for users to see _only_ the version of Perl or of XML::Parser, rather than the architecture. But I won't ;--)
In any case I am not a
mirod
Re:Perl Version... and more (Score:1)
sky
Re:Perl Version... and more (Score:2)
By looking at the bug reports.
And by testing, pre-release, on a bunch of combinations of architectures and versions of the various layers under the module: if it passes on Linux then it _always_ passes on Solaris and OS X, provided the rest of the environment is identical. It passed on Dec-OSF1 4.1G, whatever that is, with a configuration that was known to pass on other architectures. I had a few cases where the install wouldn't work on Windows, regardless of the rest of the configuration, but that was eas
mirod