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)

Sunday May 28, 2006
10:01 PM

Update on the "Refactoring Perl Editor"

[ #29744 ]

I get fairly regular enquiries from people about my semi-secret (in the sense it still doesn't exist on the TPF site :) ) Perl Foundation "Refactoring Perl Editor" grant.

To recap, the aim of the grant is to take the PPI Perl parser, which is ONLY a raw parser and doesn't do anything else, and build up a collection of functionality around it to allow the creation of editors and other more-robust smart Perl tools, culminating in a proof-of-concept Perl editor.

Since about January, the grant has been mostly stuck in an almighty Yak Shaving exercise, that I'm happy to say is finally starting to come to an end.

So I thought perhaps an update would be appropriate now.

So far, I've created all the infrastrucure I think will be necesary for the underlying system, including caching, taking over File::HomeDir and a few other bits and pieces like Perl::Metrics. And luckily for me, Perl::Critic took off without me having to write it (although I do help them out with the occasional change to PPI itself).

So as far as the parts not directly related to the editor go, that's finished.

The editor itself will consist of two major parts.

Firstly, Perl::Editor itself, which will not be an actual editor, but rather a plugin-aware bridging model that will standardise the building of editor plugins, and present a unified discovery and action API to a "host" editor.

As I keep pointing out, the big shiny feature of doing it this way is that a single CPAN Perl::Editor plugin can then work with vi, and emacs, and any other editor that wants to write an implementation of a host. Companies can write task-specific plugins that all their employees can use, and if you want to change the editor you use and move to a different one, you can take all your own plugins with you! :)

I haven't considered this to be worth working on without a real editor to try it out with, because this will be my first attempt at creating this sort of bridging API.

But the good news on this front is that now we'll have two editors from the beginning, as I've had an offer to write a vi(m) host extension, by someone that is writing PPI functionality for vi already (interfacing directly to PPI). This means that I can write Perl::Editor without having my thinking tied into any one type of editor, and as a result we should get an API that makes much less assumptions.

The second half is the editor itself, for which I'm using the PCE pure-Perl/wxWidgets/Scintilla editor.

From what was originally a non-CPAN and somewhat unusually structured editor, I've gradually helped make this editor more CPAN-compatible and more friendly to other people help out, and herbert has put a lot of work (way more than me) into this as well.

But three blockers remained.

1. PCE is not usable as a name, as it clashes with another editor.

The long search for an appropriate name is finally over. The editor will shortly be renamed and will be known as "Xeper". The completion of the CPANification of the editor should thus be able to occur soon, now it has a legal namespace to go in as.

2. PPI is not available on Windows by default.

As someone who put a huge effort into trying to reduce the dependencies of PPI as much as possible, it hurts me that this problem still exists.

The ActivePerl PPM repository has PPI at 0.990, fatally out of date.

This is because of the well known Scalar::Util "dual-core" problem in the PPM build system, a problem that I spent almost a year pestering to have fixed, to no avail. ActiveState has also been trying to fix the problem, but I'm just not able to wait any longer.

As a result, I (and others) have been working on our own Windows Perl distribution. After some false starts last year, in January I announced a competition to get past what I saw as the key problem, and one of the entrants was Vanilla Perl, which we have been using ever since to explore Win32 core-related bugs and issues.

After several months of consulting with the about a dozen authors of the modules within Bundle::CPAN, I'm happy to say that Phase 1 of the Win32 Perl work will shortly be coming to a close. After an enormous amount of work by Ilya to fix the highly tenacious Term::ReadLine::Perl bugs, only one show-stopping bug remains.

This is actually a few bugs, but can be summed up as "Module::Signature has some big problems still".

We're going to be solving this problem in the short term by removing Module::Signature from Bundle::CPAN altogether, and disabling support for signatures by default in CPAN.pm. Andreas has been a little tied up recently, but is expecting to make the changes and release shortly.

This means that Phase 2 of the Win32 Perl efforts, Strawberry Perl, should see a "build 1" release soon. My goal is to have a few test builds of "Strawberry Perl 5.8.8" float around over the next couple of months, and then do a first production release with "Strawberry Perl 5.8.9".

Since Nicholas has started turning his attention to 5.8.9, this looks like a good plan.

In addition, I have been starting to set up a http://win32.perl.org/ website to deal with Win32-specific issues across all the Windows Perl distributions (ActivePerl, CamelPack, Vanilla, Strawberry).

Although the domain and server are up, the deployment of the wiki remains forthcoming, but now my move is over I promise to deal with it "real soon now".

3. WxPerl can't install from CPAN

The other showstopper has been that in order to install Xeper from CPAN, we also need to install WxPerl from CPAN. And this is no small feat.

Fortunately, Mattia has been putting a huge effort into Alient::wxWidgets, and I'm pleased to say that as of now (0.11) it installs cleanly on top of Vanilla Perl.

The only step left (I believe) is a (non-developer) CPAN release of WxPerl itself that can auto-detect the installed alien version on Win32. And I'm assuming this should be available "Real Soon Now" now that the alien install works.

In addition to the use with the Refactoring Perl Editor, I think this also means that for the first time we will have a desktop widget library that Just Works and is usable as a normal CPAN dependency. It would mean that the time of "Desktop Perl", or no-fuss CPAN-installable fully cross-platform desktop Perl applications, has finally arrived.

All of this activity means that the Yak Shaving may finally be coming to a close shortly, and we might finally see some forward progress again on the grant.

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.
  • I just checked and, by golly, it's not! Adrian Howard pointed this out to me a while ago and I shot off an email to the responsible parties, but didn't hear back. I assumed it was handled. I'll follow through (again)?

  • .. Subject says it all! Well done and keep it up :) A.
    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;