This Week on p5p 2000/12/17


You can subscribe to an email version of this summary by sending an empty message to

Please send corrections and additions to where YYYYMM is the current year and month.

Object creation and destruction

Ilya came up with another startling patch this week, but this one was a little more complex: he estimates, however, that it "decreases the overhead of creation/destruction of objects 3-4 times". It does this by applying the same "handler" mechanism that operator overloading uses to DESTROY methods. He also says that "other handlers can be easily done the same way", which (I think) means that similar speed-ups are possible in BEGIN and END blocks.

More cool PerlIO stuff

Nick has been working his magic yet again; you can now say

    use Encode;
      || die "Cannot open $greek:$!";

This makes me ecstatically happy.

He also suggested it should be possible to use a scalar as data to be read from a filehandle, something I imagine every programmer's wanted to do at least once in their life. That is:

    $data = "...";
    open FH, "<", \$data or die "This really can't happen";
    while (<FH>) {

While he hasn't coded this yet, it shouldn't be very difficult, and would be a nice general solution to all sorts of problems.

What to do with bugs

Jarkko pointed out that there was a problem in the bug process, in that bugs can very easily be forgotten about without a trace, and there's no feedback between us and the bug reporter. We obviously want to fix this, so there's communication with the reporter, and so we make sure that every bug is dealt with and doesn't get forgotten.

Richard Foley suggested sending out a reminder of open bugs to the bug admins and p5p; there was then some wonderful set theory mathematics about which categories of currently open bugs we should start the ball rolling with and how many there were. This process will definitely happen with bugs submitted from now on, though. Read about it.

UV Preserving Arithmetic

Nicholas Clark's great work with UV/IV preserving arithmetic (You know, so that $a=3; $b=5; $a + $b results in an IV, not an NV) seems to have collapsed around his feet. It seemed like everything was going well, after a couple of 70-odd K patches starting this thread managed to get the whole thing working quickly and accurately, but then Jarkko discovered it was giving nasty results on some platforms. Helmut Jarausch found it failing on Irix, and Jarkko was having it cause strange problems on Digital Unix. The patches have been pulled out of the repository temporarily, and Nick is reportedly looking for access to "something slightly more esoteric than FreeBSD".

STOP PRESS! This from Nick:

Jarkko and I worked hard at hammering out the problems - I was relying on strtoul behaviour when presented with a number with leading "-" working everywhere the way it does on FreeBSD, linux (and Irix Jarkko reports) but it didn't work that way on Digital Unix, and that's where his nasty problems came from. I re-wrote that bit of code in sv.c to avoid even passing in the string with the leading "-" and with this solution it works everywhere we've tested, and seems to be in the repository as of yesterday (Saturday)

Code checkers

Last time I asked:

(Hey, maybe someone would like to try writing a program that automatically extracts example code from the documentation and makes sure it compiles?)

Well, Tels did it, and produced Pod::Checker::Code; initially, it checked the synopsis and examples sections of module documentation, but I suggested it should be extended to the example code in /pod. Tels duly did that, but this raised another question: how to mark up the code appropriately so that it can be checked? Various ideas were raised, the most promising being

    =code perl


I don't think anything was actually decided; check the rest of the thread for details.


Jeff Pinyan reminded us again that the output of

    $x = 10;
    print ++$x / $x;

is not what you might expect; Johan Vromans trumped this with

    $i = 1; @a = ($i++, $i++, $i++, $i++, $i++);
    $i = 0; @b = (++$i, ++$i, ++$i, ++$i, ++$i);
    print "@a\n@b\n";

Now, we all know that if you do things with multiple side-effects at the same time, Weird Things occur. However, there was some argument as to whether this ought to be the case. Johan said:

I expect

$x = 10; print ++$x / $x--;

to produce the same output as:

$x = 10; $x1 = sub { ++$x }; $x2 = sub { $x-- }; print $x1->() / $x2->();

If not, it's a bug, or we'd better have a _good_ explanation.

Various people disagreed; it's not just a question of side-effects, but also a question of the order of evaluation of operands. C leaves the order of evaluation undefined, but do we want Perl to go this way? Nicholas Clark maintained that keeping the order undefined allows for flexibility in the implementation: if we promise a certain evaluation order, but then someone comes up with a huge speed increase hack which jiggles the evaluation order, we can't use it. John Peacock summed it up rather differently: "Doctor, it hurts when I do this!". Read about it.

Reminder about the FAQ

Daniel Stutz asked how to get the latest development sources, (Answer: read perlhack, it tells you - well, the perlhack in the latest development sources does...) and also complained that "it's very hard to find information about P5P". Various people pointed out that P5P is mentioned in the first part of the Perl FAQ, and I finally remembered to post the FAQ.

Do you know about the P5P FAQ? You should. Email for a copy, or read it here.


Until next week I remain, your humble and obedient servant,

Simon Cozens
Visit the home of the Perl programming language:

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en