Stories
Slash Boxes
Comments
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

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Monday October 15, 2007
09:24 PM

Mea Culpa PPI 1.200

[ #34687 ]

Yesterday, after a little over a 1 year wait between productions, I (finally) uploaded the final release of PPI 1.200.

This is the second time I've made the mistake of trying to get too ambitious with a major release, at the risk of never releasing.

I knew the features I wanted, but I had no idea when I'd have the time to actually write them, and I felt that I couldn't release until they were done.

But my desire to avoid releasing also had the problem that general fixes and parsing regressions/bugs weren't going into prod, they were going into 1.200.

So my tardiness with the new features was also damaging the production release, and in the process hurting projects like Perl::Critic who had contributed those fixes (or the failing regression tests) and weren't getting anything back for their contribution.

Although, as chromatic has pointed out, that Free Software can take a long time to release, as far as I'm concerned this is a wrong approach for cases where one single author is blocking development.

There needs to be a line at which the slow pace becomes not a programming issue, but a management issue, and for me this line is 1 year.

If you (or I) have exclusive control of an Open Source project, and someone brings a fault/bug (and ideally a fix) to the attention of the maintainer, and this fault is not addressed for a year or longer, I consider the maintainer to be guilty of project mismanagement.

They need to either get the bug fixed, hand off the module to a new maintainer, give commit rights to the person that wants the bug fixed, or otherwise just get the hell out of the way and stop being a problem.

Of course, chromatic's original case of Perl 6 doesn't apply, because the Perl 6 people are quite happy for you to join up and work on Perl 6.

I gave about a year notice to ActiveState on the PPM build farm problems, to Andy regarding Template Toolkit's terrible treatment of Win32, and to Test::Reporter on the SMTP problems.

All three had people that weren't fixing problems, but weren't allowing others to fix them either.

And I think in all three cases, moving to a more aggressive posture (creating a better Perl Distribution in Strawberry Perl, briefly taking over Template Toolkit, and publicly and harshly reviewing Test::Reporter) has had very positive results.

If I'd done it immediately, things would be less good. I made a terrible mistake in the early days of getting my CPAN admin bit when I forcefully took over Email::Send, and I've regretted it ever since.

People deserve a chance to fix their problems. But for me, if you can't fix your problems in a year you need to either start being the solution or get the hell out of the way.

And so PPI 1.200 is not everything I originally wanted it to be.

It was simply time for me to get a stable release out there, no matter what, because I was starting to be the problem and not the solution.

Most of the features and much of the regression work in PPI 1.200 are the work of amazing Chris Dolan. He deserves far more credit for PPI 1.200 than I do.

The biggest user-visible change is the complete refactoring of the PPI::Token::Number tree, which not contains separate sub-classes for each of the numeric types.

These also contain the beginning of the ->literal method implementation, which lets you (safely) get the actual Perl value for various tokens or trees.

I had wanted a fuller implementation allowing the literal'ing of nested ARRAY references and so on, but I simply didn't have time to implement it.

Internally, the biggest change is to move to exceptions for error handling inside the tokenizer and lexer. This removed a TON of cases like

  $self->foo or return undef;

In the process, simplifying these cases also allowed a number of methods to be inlined and all the extra inlining plus the removal of all those conditionals should result in a slightly faster tokenizer (before the addition of any extra code to handle regressions).

Speaking of regressions, PPI 1.200 contains a whole crapton of lexical improvements and regresions tests.

In particular, the handling of { } in various contexts is vastly improved.

The PPI constructor now also has time-out support, so that the parsing of large pathological documents can be aborted safely and without any DOM (and thus memory) leaks.

Pending any major incompatible changes, my hope from here on is to add features MUCH more gradually from here on, and a greater addition of partly implemented methods labelled as experimental, in recognition of my inability to spend vast amounts of time on PPI and push large features through.

Again, my apologies for the delay, and please enjoy the new release.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.