Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Isn't the issue simply this line

    (($c < 200) and ($@||'')=~ m/^Resource temporarily/) and redo;

    in IPC::Run::IO? It's string-matching against $!, which is pretty stupid. Is 'Ulazno/izlazna greáka' simply (mangled) Croatian for EAGAIN?

    • It is more pervasive than just the single spot.

      Adding || $@ =~ /^Ulazno\/izlazna gre/ at line 2404 of causes the error to go away.

      I think using $! in numeric context gives access to the errno value which would be portable between locales but you may need some help from IO::Pty in order to get access to that.

      • Unfortunately you can't rely on $! still having the right value by the time the exception is caught. Really all those croaks in _read &c. should be throwing proper exception objects which catch the (numeric) value of $!. I would want to switch the whole thing to use autodie, but that's quite a major change.
    • It's Croatian, but it means "Input/output error".

  • I usually workaround the IPC::Run test failure by setting the locale to C. So maybe you can just do the same in the test script, somehow, locally.

    • It is a real error, though, not a bug in the tests. If someone uses IPC::Run in a non-C locale it will fail to work correctly: if anything, tests should be added to catch the bug.

      Setting the locale to C somewhere appropriate in IPC::Run itself might be a workaround, but I've no idea how the stringification of $! reacts to changing the locale. I would expect it to be quite system-specific: here (FreeBSD) I can't get perl to give me localized error messages at all (I think the translations may simply not exi

  • Found this little thing that might interest you about one of the t/pty.t bugs. [] It seems that the "bug" is still present in IPC-Run-0.83. I don't have access to a MacOSX machine, but maybe someone else can verify if it FAILs or PASSes.
  • I had similar problems with access to machines when I was fixing Crypt::Rijndael. I realized that I had Solaris 10 media on my shelf, and set up a virtual machine in VMWare. Now I have access to it.

    If you want the virtual machine we could figure out how to exchange it, but you can also get OpenSolaris [] on your own.

    I know that the community can also chip in, but I found that model like taking your punch cards down to the operator's office and waiting for him to run your program. Even though some Solaris peopl

    • If the CPAN Testers identified the specific VM/configurations they were using to run tests, it would certainly make it easier to replicate their bugs.

      • I think we talked about this in Iceland. Wouldn't life be grand if a CPAN tester could send you a VM of the setup causing the failure!

        • Forget "sending".

          I want the CPAN Testers report to state the URL or UUID of the VM that was used to make it.

          That way you wouldn't need to co-ordinate, you just go to some website and pull it.