It seems like only yesterday we passed epoch 1000000000 when in fact it was nearly eight and a half years ago. On the other hand I remember epoch 1111111111 quite clearly since it was just before my birthday.

And now we come to another momentous epoch, that of 1234567890. I just happened to notice this as I was watching a Cyrus imapd logfile.

2009-02-13 23:31:30 UTC, by my reckoning. A good excuse for a pint, if you ask me.

"Are these names considered to be a public non-changeable interface by virtue of having been placed in these directories for a while, even though they were never documented as far as I can tell? Or are these files considered to be an internal implementation detail of Perl, not for external use, and hence subject to change or deletion?" -- Karl Williamson, waging war on two fronts simultaneously, Perl and Unicode.

This Week on perl5-porters - 3-9 November 2008

"PS: Hi, guys. Been a while. How you been?" -- Chip Salzenberg, back on the chain gang.

This Week on perl5-porters - 27 October-2 November 2008

"So we're doing things at BEGIN time in UNIVERSAL with source filters. With a garnish of messing with @ISA in some other classes. What could possibly go wrong?" -- Nicholas Clark, trying to address serious bugs lurking somewhere in code this funky.

A couple of usability bugs turned up when File::Path was dragged kicking and screaming into the third millennium, with its new options hash interface.

Refactoring the code introduced a nasty symlink chmod 777 error, and the heuristics for detecting the new way of calling rmtree and mkpath made the wrong call in some circumstances.

All should be fixed, and the code as it stands should be ready to be bundled with perl 5.8.9. To help this happen, could people give this a spin?

Notably, users of minicpan should see errors about uninitialized variables go away, and people who see spurious all-digits directories created in $HOME should also see them go away.

Also, is the documentation clear? Please lodge RT reports for any problems you encounter.

This Week on perl5-porters - 15-21 September 2008

This is sort of like one of those useless Windows alert boxes that pop up to tell you something perfectly normal has happened and you should do nothing. "A USB device was safely removed!" Yes, thank you, I just removed it. It's this sort of hand-wringing user interface design ("but the user might not have expected that USB device to be removed, they should be told so they can maybe, possibly do something!") that I'd like Perl to avoid. -- Michael G. Schwern, wanting numeric upgrades to JFDI.

(Please take note of the date. I'm posting the backlog of summaries after having encountered problems trying to post them last month).

This Fortnight on perl5-porters - 28 September-12 October 2008

"... because a git repository is a collection of assembled changes, not a linear progression, using a commit ID as a way to find out where your code came from doesn't work. This is not git's fault but is an issue with every distributed version control system (SVK tries to pretend otherwise). You could perhaps use a combination of the git repository you pulled from and the last commit ID, but [...] fundamentally the idea is gone. It's a small price to pay." -- Michael G. Schwern, coming to terms with the future.

"I'm really tempted to fix toke.c:S_incline() instead. I don't think there will be much breakage, right?" -- Rafaël Garcia-Suarez, hiking in mountain boots where angels fear to tread.

Both Gabor and Herbert have been discussing what they see as desirable in an editor.

I think most of the specifics of what this tool should do or that tool should do are largely irrelevant, because as a user interface we're facing what is fundamentally an "Open Problem".

What we can do, however, is identify the underlying effects that we need to achieve in the creation of tools for wide audiences, and then refer back to effects when looking at individual features.