This Week on p5p 2001/09/03

Notes

This Week on P5P

Testing, testing

Coderef-in-@INC

Default random seed

local chdir()

File::Spec

Smoking!

Various

Please send corrections and additions to perl-thisweek-YYYYMM@simon-cozens.org where YYYYMM is the current year and month. Changes and additions to the perl5-porters biographies are particularly welcome.

Testing, testing

The focus this week has very definitely been on testing, with the great Michael Schwern providing all sorts of QA advice, tests and patches. He patched: t/op/rand.t, t/op/time.t, t/op/srand.t, t/op/local.t, t/op/concat.t, t/op/misc.t, t/run/segfault.t, pod/perlhack.pod, t/op/pack.t, lib/Cwd.pm, lib/File/Find.pm, and lib/File/Find/taint.t, in an earnest attempt to deprive himself of $500.

He also wrote a CPAN.pm testing module, and passed on tests from Andrew Wilson (thanks, Andrew!) for CGI::Switch, CGI::Apache and CGI::Cookie.

Uhm. Wow.

Jonathan Stowe wrote a test suite for Shell.pm (Yes, honest) and Rafael Garcia-Suarez, who seems to have taken responsibility for the coderef-in- @INC feature, wrote some tests for that. Rafael also wins the prize for the funniest JAPH I've seen in a long time, but I'm going to make you hunt through the archives to find that. :)

Coderef-in-@INC

Rafael also sought to make the information in %INC useful for modules loaded via the coderef-in- @INC. Now, for instance, you could see entries in %INC such as

     /loader/0x81095c8/Foo.pm - CODE(0x81095c8)

The address in the "loader" section matches the address of the coderef.

Artur complained that the tests would only work on PerlIO, and could be rewritten to be more general; Rafael knew about this and tried to find a cleaner solution.

Gisle, on the other hand, was more concerned about the nature of what was going in %INC:

What is still missing is to make sure pp_require() invokes the hook again when an absolute filename starting with things like "/loader/0x81095c8/" is used. Currently this bypass the @INC search which is quite likely to make the require fail.

If you for instance try to serve up the Tk modules via a hook like this you will discover that it has a special AUTOLOAD function that construct absolute file names based on the %INC value. It will then load its .al files like this:

    require '/loader/0x81095c8/auto/Tk/Frame/scrollbars.al';

Rafael said that AutoLoader falls back to a relative path if it has problems, and also discussed the possibility of having DynaLoader serve up binaries via a @INC hook. (Blugh.)

Nick Clark, who's one of the evil minds behind this whole thing, wanted something less plausible than /loader/whatever which could conceivably be a path if someone's really out to get us, and so Rafael counter-proposed &(0x...). Nick also expressed suitable disgust at the getting-binaries-from-a-coderef idea.

Default random seed

Michael Schwern (Yes, him again) noticed that in certain circumstances, calling srand twice with no argument can produce the same set of random numbers. He asked for more pseudo-random data that we can use to perturb the seed of srand on machines that don't have /dev/urandom. Merijn suggested times, but Jarkko said that the usual granularity for that was only a jiffy, which might not be enough. Jarkko and Mike Guy both pointed out that running srand twice was generally speaking a Don't Do That, Then error. Mike Guy's comments on srand bear repeating:

You shouldn't ever use srand() (i.e. without argument) more than once in a script. The internal state of the RNG should contain more entropy than can be provided by any seed, so calling srand() again actually *loses* randomness. And you shouldn't use srand() at all unless you need backward compatibility with *very* old Perls.

Of course, srand($x) with an explicit argument is a quite different kettle of fish. But you should only be doing that if you know what you are doing ...

Jarkko pointed out that

    srand(31337);
    @first_run  = mk_rand;

    srand(1138);
    @second_run = mk_rand;

might fail if we have really, really, really bad luck. But with 100 numbers in each array, it would have to be cosmically significantly bad luck. And Mike Guy pointed out that if we do get the same sequence back, then our rand isn't sufficiently random and this could be considered a bug.

local chdir()

Michael Schwern (Yes, him again) expressed his deep-seated longing for

    local chdir($foo);

which changed directory back once the scope is over. Kurt Starsinic said that we wouldn't always be able to go back, and so you might as well fork if that's what you want. (Amazingly, Artur didn't suggest using threads.) Jeremy Zawodny got really excited by the idea, and suggested being able to local an entire block of code and have the effects rolled back at the end of the scope. Yeah, right. However, he did suggest writing a little pushdir/popdir module, which was a little more sensible than hacking core for fun and profit. Schwern wrote something using Abigail's DESTROY trick, and Abigail showed a nicer variant by using a tied scalar which changed directory when you assigned to it.

Abhijit Menon-Sen got in a particularly silly mood and actually implemented local chdir($foo) (with a bit of help from you're truly, who's always in a particularly silly mood) which caused Schwern to ask for more, more, more... select, umask, chmod and so on were now on the table. Sarathy expressed some dismay at the waste of precious op_private bits, as well as the "semantic complexity" of the idea itself. Abhijit himself summed up the opinions of several of us:

I'm not convinced that we should allow localizing actions (as opposed to values), and adding destructors piecemeal for random ops would make me very uncomfortable.

That said, I wouldn't object to a module which -- with suitable hooks in the core -- allowed arbitrary leave_scope() actions to be registered. I might even write it sometime.

That'd be worth seeing.

File::Spec

Michael Schwern - oh no, it was Chris Nandor - had a problem with File::Spec:

In Mac OS, you can tell it to be relative by making the first argument a leading empty string. So catfile("a", "b") is absolute, while catfile("", "a", "b") is relative. In Unix/Windows, it is exactly the opposite: the default is relative, but adding a leading empty string makes it absolute!

As Chris rightly pointed out, "Yikes!" If File::Spec is supposed to make things more portable, we have a problem. Chris suggested making relative paths the default and breaking MacPerl in the interests of sanity. Barrie Slaymaker, who owns File::Spec said that he'd be willing to accept patches if he thought the MacPerl community could cope with the breakage. Peter Prymmer said that the required change on VMS probably wouldn't break that much and he was more interested in making the API cross-platform. Tim Jenness asked whether or not catdir ought to support volumes, such as on DOS or VMS. Phillip Newton reminded us that there is a difference between A:b\c and A:\b\c, and that he expected catdir('a:', 'b', 'c') to do the former rather than the latter. Yup, each drive has its own idea of the current working directory.

Anyway, it looks like the consensus was that Chris's suggestion will be adopted once Barrie gets Mac and VMS patches, File::Spec will be truly portable again, and all the world will rejoice.

Smoking!

The daily build project is great! Quite a few interesting bug reports have come out of the fact that we have Perl being tested almost continuously now on different platforms and architectures with all manner of different build options. I started smoke testing my desktop this week and confirmed some bugs that other people were seeing on AIX and FreeBSD, probably saving Merijn from a lot of unpleasant AIX and pains. If you want to get involved and donate some of your processing power, subscribe to the daily-build mailing list.

Paul Marquess found a potential DB_File bug with the help of Merijn's smoke results, and Artur got to track down a bizarre segfault in the File::Taint tests. Will Coleda broke Cygwin, but Gerrit Hasse thinks that was his own fault. Nick Clark found a bug in MANIFEST of all places, but this was explained as being a bad time to resync.

Various

Ed Peschko asked why we don't have $SIG{__EXIT__} and was told by various people to use an END block.

Paul Johnson produced the useful but perhaps dangerous coretest make target, which only runs a subset of the testing suite, allowing you to dash off your latest patch without completely testing you haven't broken anything subtle. (I know, because I did it last week.)

Nicholas Clark silently went on making more and more of Perl able to preserve IVs where possible. Nobody cared. He also found lots and lots of interesting bugs.

Artur, pumpkinging madly, found a lovely bug in HP-UX which we can probably blame on gcc: inet_ntoa always returns 0.0.0.0. This is obviously not useful. He also found a bug in the tests of Time::Hires where every so often the test fails due to rounding error between the ordinary integer version of time and the floating-point hi-res version.

Yusuf Goolamabbas asked whether something (lack of support for large files) was a Perl problem or a RedHat packaging problem. Two people took the opportunity to pass the buck. Amusingly, Chip Turner from RedHat turned up to pass it back:

I believe Large files are supported only with 2.4 kernels and certain glibcs. Which basically means for proper large file support, you will need Red Hat 7.1. Even then, some utilities don't work, Perl being one.

Ouch.

Daniel Lewart picked up a few miscellaneous bugs in Time::Local, and Rafael fixed up the example of an array shuffle in perlfaq4 to be less confusing to the learner. (It used the same variable name for an array and an array reference!)

Jarkko is now back, and rapidly catching up on his P5P backlog, so it's time for me to go and generate some more for him, and until next week I remain, your humble and obedient servant,


Simon Cozens
Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en