Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

The part of the Perl community I really hate 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Wouldn't it be easier if you just posted your root password?

    Having a (standardized?) vmware image is missing the point as it's the different configurations that finds the errors that you as a developer can't test yourself.

      - ask
    --

    -- ask bjoern hansen [askbjoernhansen.com], !try; do();

    • It doesn't need to be heavily standardised. It only need to behave in a very limited number of specific ways. The bits that _are_ standard are likely to be outside the testing scope for all but a few cases.
  • I got the impression while reading your post that you think "they" should do it. Try posting this on perl.qa group. I am sure "they" would encourage "you" to do it and in the meantime "they" will continue with building the test modules "they" are working on.
    • That is not point. The point is that I should not have to be the one to write _everything_. I'm absolutely sick of people that offer to help, and the proceed to describe not only why the thing they are offering to help on sucks and won't work, or "isn't needed cause you can solve your specific case like so". When it will work, and it is needed.
  • There are currently around 60 regular CPAN Testers, who test on a variety of platforms and perls. Last month there were 22 different platforms and 11 different perls giving 241 different setups. Being able to have perhaps a good selection of images, with at least the major perl releases and the most popular platforms is a good idea. And the idea you're proposing would hopefully catch most of the obvious bugs, but you aren't going to get away from using CPAN testers. I am pretty certain every single one of t
    • CPAN Testers doesn't solve the problem of testing. Full stop.

      They solve ONLY the limited subset "testing released CPAN packages".

      CPAN Testers is no solution at all for company or private packages.

      And of course they test only what they want. If they didn't want to be in CPAN testers, they wouldn't be there.

      They have full control over what they do, and I have ZERO control over them, as you would expect from people contributing their time in this way.

      I'm just starting to get a little frustrated that every
      • CPAN Testers doesn't solve the problem of testing. Full stop.

        No it does solve complete coverage of testing, but it goes a long way to covering the bulk of scenarios. Trying to test every scenario that exists is a huge task and one I don't think will ever be achieved.

        CPAN Testers is no solution at all for company or private packages.

        Why? I assume you're talking from your own experience. In my experience the cpan-testers have proved useful to know what works on various platforms out of the box and what

      • Don't you think that a "company or private package" only has to work in the "company or private" environment and that consequently the "company or private" developer can, if he likes, use exactly the same tools as the CPAN testers to do his testing?

  • First of all, an offering. Below is some bash-shell code that might be a start toward a portion of what you requested. The code was passed a parameter that was the name of a perl source tar-ball (.gz). It built the version of perl and installed it to a local usr/test/ directory tree relative to where it was installed, and at the time would execute the CPAN module's 'autobundle' command and write to a file. (It also removed the 'built-in' and 'command line' entries from the various Makefiles, because of issu

  • We can tell several things from your journal entry.
    1. You don't know any good sysadmins. When you say "for some reason, admins seem to have a particular approach to life, that being to take an approach of doing things with the least amount of work possible. And BOFHs do this aggresively (with a good dash of misogeny thrown in)" you miss the point that most of a sysadmin's job is tedious and easily automatable, and so it *should* be automated away. This isn't because he's lazy and wants to sit back and do
    • Your claim that developers want to solve problems in the widest most generic way possible just ain't true. Developers work to deadlines and to customer requirements.

      Indeed, and they are compromises from the ideal.

      You seem to think that sysadmins don't plan ahead. A good sysadmin is *not* thrown into a panic when hardware fails. A good sysadmin *knows* that the hardware is out to get him, and will have automatic failover configured (and tested!) or will have plans to temporarily restore service elsewher

  • My very own thoughts: typical perfect world developer mindset to assume that a big and complex problem is straightforwardly and fully solvable. I expect that if you actually try, you’ll find reality to be pricklishly difficult, full of nasty edge cases and little ratholes. Testing is a messy problemspace; that’s why CPANPLUS is still rough.

    However, I am open to being shown otherwise; if you think you really can solve this, go ahead and try. You’ll either find out that everyone else was r

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.