Thanks largely to Jarkko's help, the second trial version of perl
v5.6.1 is now available. (CPAN may need some time to catch up.)

If this release passes muster, I will update perldelta.pod and send
it to CPAN as v5.6.1. Owing to the large number of patches, testing
is very very important. So give it all you've got on all your
favourite platforms!

In particular, I'd like to see some purify (or similar) runs. Patches
to documentation are also welcome. Changes to *.[ch] are probably
out unless they are fixing serious bugs.

Naturally, this produced a deluge of test results, the vast majority of
which were successful. As usual, if you've got any weird and funky
platforms, give it a spin.

And, of course, well done to Jarkko and Sarathy for putting this one
together.

I forgot to mention this last week, but it's important enough for me to
mention it this week: Chris Nandor has taken over the MacPerl pumpkin.
If you have a Mac and you want to run Perl on it, (or even better, help
move MacPerl up to 5.6.1) then you really ought to read Chris'
State of MacPerl posting.

Barrie Slaymaker mentioned that he wanted to get
select() working on Win32, and that Perforce were interested in funding the
work. Nick Ing-Simmons said that the PerlIO abstraction layer would help
with this:

he problem is that on Win32 to use
select() the Socket has to be in synchronous mode. While to use
WaitForMultipleEvents() the Socket has
to be in asynchronous mode - thus if you want to use Win32's native
"poll-oid"
API you cannot use
select(). In addition MS's C runtime (
read/
fread etc) will not work on sockets in asynchronous mode (or non-blocking IO in
general).

So you need to replace
read and
stdio with another IO subsystem and get perl to use it - hence PerlIO.

Uri Guttman predictably took this as a cue to push for a portable event
interface; Rocco Caputo said that he'd added an event-driven
IPC::Run-style process communication model to his
POE module which worked fine on Win32, using TCP sockets as a form of
select()-able pipe emulation.

Nick wanted to work at the problem from the other end, by building up a
new PerlIO bottom layer for Windows, using the native Windows IO calls.
Sean McCune, who's working with Barrie on this, said that's what he
would try to do. As Jarkko pointed out:

First fork() emulation and now select()? If we are not careful in ten
years or so NT/W2K/W2010 will be almost as useful as UNIX was in
mid-1980's.

At last, Schwern's Test::Harness patch made it in, after a tiny bit more
messing around. The discussion turned into a useful thread on patching
strategies. For instance, it's apparently not very widely known that if
you add a new file to the Perl distribution, you also need to patch the
MANIFEST file. There's also a load of good information in the file
Porting/patching.pod. Andreas Koenig also put in a plug for Johan Vroman's
makepatch utility:

Johan Vromans has written a powerful utility to create patches based
on large diretory trees -- makepatch. See the JV directory on CPAN for
the current version. If you have this program available, it is
recommended to create a duplicate of the perl directory tree against
which you are intending to provide a patch and let makepatch figure
out all the changes you made to your copy of the sources. As perl
comes with a MANIFEST file, you need not delete object files and other
derivative files from the two directory trees, makepatch is smart
about them.

Nicholas Clark suggested that each time you plan to make a change, you
can call configure with
-Dmksynlinks which creates a symlink farm. Then when you change a file, remove the
symlink and replace it with a real copy of the file. This means you can
maintain multiple patch trees without the space overhead of full source
trees. Other suggestions included various version control systems, and
some people provided programs to sync up
bleadperl with their local version control repository.

Schwern also came out with a load of documentation patches explaining
the difference between
chop and
chomp from a portability point of view, and changing the examples to use
chomp where they previously used
chop.

I have a CHECK block that checks that
all the methods requested by the interface are accessible. No problem.

Until, one of my class's client classes comes to do a deferred load
using require and everything falls over in a heap because it's

Too late to run CHECK block.

And I can't, for the life of me, understand why.

So, what's a
CHECK block? The idea is that they're supposed to be called after compilation
is completed. They're intended to be used by the compiler backends, to
save the program state once everything's been assembled into an op tree.
However, there's no reason why you can't use them for other things
instead.

The problem that Piers was coming up against was that we expect
CHECK blocks to be run every time something is compiled, but this doesn't
happen yet; Sarathy explains:

In the current implementation, there is exactly one point at which
CHECK and INIT blocks are run (this being the point at which the
Compiler would do its work, when it saves and restores program
state, respectively).

But I believe Larry has stated that CHECK blocks should be able to
run at the end of compilation of every individual "compilation unit",
whatever that happens to be (file/BEGIN block/eval"").

As far as I'm aware, nobody is currently working on making those new
semantics reality, but I don't think it would be too difficult.

I compiled a list of standard C library functions that are either
reimplemented in the Perl core, or redefined to have more predictable
semantics. This helps you write more `politically correct' internals
code. For instance, instead of saying

Lupe Christoph came up with some patches to make Solaris's
malloc the default rather than Perl's
malloc on that platform; this works around a known problem with Perl's
malloc with more than 2G of memory.

Doug MacEachern had a really neat patch which shared globs containing
XSUBs across cloned
Perl interpreters, something that could save a lot of memory for those
embedding Perl. (Especially things that clone a lot of interpreters,
like
mod_perl)

And that's about it. Until next week I remain, your humble and obedient servant,