I fought against the most for a long time, on the basis that the tool support for git on Windows was just terrible and it would make contributing to Perl difficult for Windows people.

Fortunately, with the availability of tools like SmartGit and GitHub for Windows this is no longer a problem.

So it looks like the time has for me to start the giant job of moving my repository over to GitHub myself (no small task considering it contains something like 300 modules).

As a first step, I am porting my personal release automation over to allow me to release modules from GitHub directly without the need for git client integration or a checkout at all.

The core of this new release automation is my new GitHub::Extract module.

GitHub::Extract is a wrapper for GitHub projects over the top of Archive::Extract and File::pushd and makes use of the "Zipball" feature of the GitHub website.

In a single statement you can download a project zipball from GitHub, extract it, and then change into the root directory of the exported project.

my $pushd = GitHub::Extract->new(
    username   => 'adamkennedy',
    repository => 'test-class',
    branch     => 'master'
)->pushd;

# Do the rest of the release tasks here

The current working version of the new release automation is here (yes, it's in svn for now)

http://svn.ali.as/cpan/trunk/ADAMK-Release/lib/ADAMK/Release.pm.

It needs a few more small tweaks, but it deals with the things I care about and it should be good enough to start building releases from.

The next step is to start the process of porting modules into GitHub, and that seems like a much bigger job (anyone got a script for splitting one giant svn repo into lots of small github ones while retaining history?)

More to come...

It's been a while since I've written much Perl as well, looking at my CPAN page shows a long gap since I moved over to America (and the Microsoft stack) to work at Kaggle.

The break has caused quite a few problems in terms of maintainership of various things. Padre's progress towards 1.00 has suffered quite a bit, and I've handed off a few modules where people showed interest in taking them over.

The time away from Perl has also given me a chance to reassess my work and the CPAN ecosystem and to think about which parts of it are actually important and which are in desperate need of a shake up.

The first project that badly needs some love is CPANDB, which is a single relatively small SQLite database (and ORM) layer that aggregates all the most important data about CPAN authors, distributions and modules together in one place.

The original one was trapped using the 2gb download version of the CPAN Testers data, failed to install on Windows, merged data poorly without tolerance for delays or degradation in the data, and did not deal with dependencies properly after the introduction CPAN::Meta.

The new CPANDB 0.18 fixes all of these problems.

http://svn.ali.as/cpan/releases/CPANDB-0.18.tar.gz

The new version of the client removes some problematic dependencies (and reduces the dependency load generally), while the generator on the server side fixes and number of problems.

The data it needs is reduced to the point I can now safely put it on a twice-daily cron to keep it properly up to date.

With the return of CPANDB comes the return of my old prototype CPAN Top 100 website.

The Top 100 website integrates the dependency graph with other data from the CPAN cloud to produce interesting rankings of CPAN modules.

The most notable change since the last time the Top 100 was working is the immense dependency bloat that seems to have occurred at the top end of the scale.

MojoMojo is now up to 411 dependencies. Catalyst with ExtJS support takes 311 dependencies!

It used to require approximately 140 dependencies to make it onto the Heavy 100 list, now it takes 240 dependencies to make it.

The method used to count dependencies on the current Top 100 website is intentionally crude. But fortunately it doesn't need to be so for long, as the CPANDB graph integration supports the ability to describe dependencies in terms of starting from a modern 5.16 version rather than from 5.005 (the default)

But more on the new version of the Top 100 website later...

Since I've been largely incommunicado over this period and have only just started to get in control of these changes, I thought I should take the time to explain my new situation and the impact on my Perl projects.

Firstly, my employment situation has changed dramatically.

For the last 3-4 years I've been at Corporate Express Australia (now Staples Australia) working full time on a large 250k line Perl code base for their main sales channel, and I'd like to take a moment to thank them for their support of Open Source Perl over that time.

The position provided me with the opportunity to legitimately hack on some very significant Perl modules on work time, most notably the complete rewrite of the Perl Aspect Oriented Programming framework, creation of my POE::Declare concept for complex POE applications, project managing DBD::SQLite and Strawberry Perl, fixing parsing bugs in PPI and funding a series of performance and memory leak fixes for the crucially important sapnwrfc Perl interface to SAP.

Using Padre (and being annoyed at it) every day at work also provided the incentive for a ton of the work on the IDE and support modules like ORLite, ORLite::Migrate and Params::Util, and there's no question it would not be as mature as it is today without their support.

In March I left Corporate Express and moved to Kaggle, in the process moving countries from Sydney, Australia to San Francisco, California.

Kaggle is playing a pivotal role in the current Data Science revolution, and in my opinion is one of the most interesting and amazing places in the world to be working right now.

It's the kind of place where it feels like you are changing the world about once a month, and was an opportunity too good to pass up.

Unfortunately, there is a major downside for my Perl work.

Software development at Kaggle is largely based on a pure Microsoft stack, and the job involve no Perl development for the foreseeable future, with the exception of some occasional community outreach work to help improve Perl's machine learning modules.

This will undoubtedly have some impact on my Perl projects, and most notably on my ability to contribute large amounts of time on major improvements to Padre. When it comes to working with Microsoft languages it is simply impossible for Padre to compete with Visual Studio.

Padre should not be too badly impacted by this change in the short term, as I was able to focus a large amount of time on getting the core features polished and making it suitable as an every day editor.

But major features such as server integration, config sync and collaborative editing will take a big hit and may take a lot longer to complete.

Most of my CPAN modules are in a much better situation however, so it's not all doom and gloom.

The majority of my modules are either relatively mature, or I have managed to bring in other people to assist and migrated to more of a project and release manager role.

In particular, Strawberry Perl and DBD::SQLite both have excellent developers working on them and I can comfortably manage my roles in both without any particular trouble (although I apologize for any delays over the last 3 or 4 months as I've moved country).

Strawberry Perl in particular may actually make some big improvements shortly, as the 5th generation dist toolkit (thanks to KMX) and the maturity of Padre mean that the time is ripe for Chocolate Perl aka Strawberry Perl Professional aka Strawberry + Padre.

But that is a discussion for another time.

I also hope you'll forgive me if my blog posts now move a little away from Perl at times (I promise any non-Perl posts will be interesting, and won't be about C# or Python programming or something folks here would find annoying).

Yours American'ly

Adam K

http://search.cpan.org/~adamk/DBD-SQLite-1.36_04/

The new release upgrades SQLite from 3.7.9 to 3.7.12 and the upgrade of DBD::SQLite is in line with SQLite upgrade recommendations, and also driven by the move of Firefox to a newer file format than currently supported.

The new release contains a few changes that may cause trouble for your application and you should test, the biggest is the change in the default file format from version 1 to version 4 that landed in 3.7.10.

This means that SQLite files produced by DBD::SQLite will no longer be readable by older versions of SQLite unless you explicitly enable PRAGMA legacy_file_format=ON.

The second major change is the introduced of FTS4, a new full text search which replaces the older FTS3 (DBD::SQLite will ship with both FTS3 and FTS4 for some time, but you should migrate if possible, as FTS3 will be removed in a later release).

In addition to these two major changes (and a host of smaller improvements inherited from the newer SQLite releases) the new DBD::SQLite also improves support for both 64-bit platforms and for older Mac platforms.

As with all DBD::SQLite public releases in the current series, we are allowing several weeks for people to test the final dev release before doing a production release.

If you encounter any issues with the new version, please file a bug report in RT or contact the DBD::SQLite mailing list.

It takes a whole variety of different data sets from the CPAN group of services, and cooks them down into a single unified SQLite schema that you can access via a convenient ORLite wrapper (or access directly if you wish).

This single database file can then be used both as a convenience for simple tasks, or to build deep and complex analysis metrics of the kind I used in the creation of the CPAN Top 100 website.

The biggest problem with this module has always been the problem of server resources. To generate the database originally required downloading the CPAN Testers database. Even today in it's updated form it needs the CPAN Testers summary database, and that doesn't necessarily calculate it's metrics the way that CPANDB likes them.

To make CPANDB a truly useful tool that other parts of the CPAN ecosystem can rely on it needs to become much more stable and be updated regularly.

So this is a call out for someone to help me with hosting the CPANDB generator module. I suspect that this will ideally be someone in the CPAN Testers community, as testing data is by far the heaviest part and if you already have a copy of the CPAN Testers results database for some other purpose we could leverage it directly without obscene amounts of copying every night.

Aligning so closely with the features of a single database engine keeps the implementation size down to a minimum, at less than 1000 lines of code, and allows ORLite to do things that would be completely impossible in more general ORMs.

This is particularly true in the upcoming 2.0 release, a preview of which is available now.

http://svn.ali.as/cpan/releases/ORLite-1.90.tar.gz

This new major revision embraces SQLite's slightly unique rowid mechanism, allowing it to accurately distinguish between different copies of identical data.

Lets start with the following database in the file adam.sqlite

create table person (
    firstname string not null,
    lastname string not null,
    location string not null
);

insert into person values ( 'Adam', 'Kennedy', 'Sydney' );

insert into person values ( 'Adam', 'Kennedy', 'Sydney' );

insert into person values ( 'Adam', 'Kennedy', 'Los Angeles' );

Now lets say I want to move from Sydney to San Francisco. First I'll create an ORM for this database.

package Adam;

use ORLite 'adam.sqlite';

With my ORM created, I'm going to load the two Adams living in Sydney.

my @sydney = Adam::Person->select('where location = ?', 'Sydney');

Now I want to move one and only one of me to San Francisco. Normally this would involve some fairly annoying database contortions to deal with having two identical records.

But SQLite doesn't actually have identical records internally. It's rowid mechanism acts as an implicitly incrementing primary key for any table that does not have one (rowid is an alias for your primary key if you do have one).

In ORLite 2 these rowids are stored internally in the object, and used for all update and delete calls.

So the following will actually work the way it appears to.

$sydney[0]->update( location => 'San Francisco' );

Even though the table has no primary key and two identical records, ORLite has changed one of the two identical records so now we have three Adams in three different places.

Alternatively, we could have resolved the problem by deleting one of the Adams instead.

$sydney[0]->delete;

The two lines of code above actually produce the following SQL statements (I've inlined the placeholder values for demonstration purposes).

UPDATE "person" SET "location" = 'San Francisco' WHERE "rowid" = 1;

DELETE FROM "person" WHERE "rowid" = 1;

Since the rowid system is exposed in SQLite if you need to do funky trickys, I've also done the same thing in ORLite.

All classes that represent table objects now gain a rowid method, which returns an integer if the object is stored in the database or undef if the object is an anonymous object created via new and has not been inserted into the database yet.

The magic of internal rowid tracking not only makes this possible at all, it also makes the code generation significantly easier and execution potentially much much faster by preventing the database compiling queries with O(n) implementations for operations which are only intended to act on a single row.

It also potentially reduces the number of indexes you will need, reducing database size and making insert and update operations faster.

Improved identification of objects also makes it very tempting to move ORLite towards becoming an object-tracking one-instance-only type ORM such as Entity Framework in .NET.

However, I think this is more appropriate for an add-on class or wrapper over ORLite and isn't appropriate in the core module.

However, as a readability nod in that direction, ORLite now checks for a incrementing integer primary key in the recommended pattern tablename_id and automatically adds a convenience id alias for the normal accessor.

So now the following are all now equivalent.

$thing->thing_id;

$thing->id;

# And since rowid reuses incrementing integer keys this is the same as well
$thing->rowid;

I plan to write some kind of cook book or tutorial on recommended database structure before the final 2.0 release.

And finally, ORLite 2.0 will provide much better support for Unicode.

An initial implementation has been provided by means of an explicit unicode => 1 import parameter, but right now care should be taken if your database has any columns of BLOB data type as generate code probably does not take unicode into account properly when working with BLOB values.

Over the last couple of months there has been a huge focus on the core editor GUI features, and making sure they are all as glitch free as possible and high usable for day to day operation.

This focus on polish is particularly evident for me in the Find and Replace related code, which is smoother and more functional than it has ever been.

I find myself routinely leaving syntax checking and version control markers on now, where before their various glitches would make them too annoying for me to use.

The other exciting improvement for me in this release is that all the parts of Padre needed by the Padre::Plugin::FormBuilder plugin now work properly.

This means that I can finally do a long-awaited "proper" production release of the Form Builder plugin, and finally bring cross platform GUI generation to the masses.

One of the common gotchas with Test::NoWarnings is that the warnings are collected up and displayed in one go at the end of the script.

While this is strictly speaking the correct time to show them and has the least likelihood to result in a collision with some other test module resulting in an explosion, it makes debugging test scripts much more difficult.

Since I took over Test::NoWarnings a number of people have asked me to “fix” this problem.

After much thought, I’ve decided to leave Test::NoWarnings default behaviour the way it is and show everything at the end.

Instead I’ve added a specific debugging aid in the form of an :early pragma.

use Test::NoWarnings 1.04 ':early';

The :early pragma explicitly turns on emitting warnings at the time they occur instead of gathering them until the end.

As this feature is still experimental and I need some time to see any potential fallout, initially I recommend turning it on while you are debugging a test script and then turning it off once the test script passes.

In the future I may switch this to be the default instead. If this happens I’ll add a back-compatibility pragma to provide an easier upgrade path for legacy modules.

But for now, you should have an option to remove the most immediate pain.

http://svn.ali.as/cpan/releases/DBD-SQLite-1.35.tar.gz

Normally the release schedule of DBD::SQLite is tied to that of SQLite update recommendations, as this module is used in an enormous number of places and having relatively large gaps between releases is considered an advantage for downstream distributions and corporate users in particular that have very large testing burdens for each release.

This is the first DBD::SQLite in a long time that was not done as the result of an update recommendation from the SQLite maintainers.

In addition to a number of Perl level bug fixes, this release gains the SQLite 3.7.8 and 3.7.9 updates, the former of which contains a new merge sort for indexing resulting in an order of magnitude performance improvement to indexing and performance improvements to any queries that do index lookups.

It also greatly improves the speed of any sort operations larger than the page cache, and bumps the speed of a few other bits and pieces as well.

Since DBD::SQLite is looking extremely stable at this point, with stable releases about once every 6 months, we might take the opportunity for the next release to tweak the compile options a little more.

Of main interest to me initially would be enabling Full Text Search version 4, turning on histogram-enhanced ANALYSE version 3, and compiling out TCL variable support and deprecated C level interfaces we don't use.

Conceived as the logical extrapolation of Perl's testing framework development into the future, the basic idea is zero conf 100% automatic testing in parallel across arbitrarily many different operating systems using one-time virtual machines.

Achieving that kind of process isolation in a way that doesn't require any manual setup and no human intervention has meant some extremely twisted internals and lots of unusual and complicated problems to solve.

After an initial development rush in 2006, I hit the wall and struggled to make progress in the face of problems like having no version of Perl on Windows with a compiler, the difficulty of embedding custom POE applications into regular applications, and the mind-bendingly awful problem of debugging code being run via a shell command from a different version of perl in the child of a fork spawned from a script called from a boot init script in a headless VM called from system command in the hidden fork child from an async loop spawned in a deep object model in the child fork of a daemon.

About once a year when the pain has faded from the previous attempt, I have a shot at solving the remaining problems again.

This year I seem to have finally nailed the last problem in the core processing loop on Windows after a 9 hour debugging session uncovered a bug in IPC::Run3's handling of STDIN when run recursively inside of itself (or something, I never quite worked out the specific problem).

I've also ripped out LWP for HTTP::Tiny (which has eased some complications caused by dependencies) and fixed a bug in File::Remove relating to END-time functionality running multiple times and deleting directories too early when you fork.

As a result, the test suite for PITA finally passes on both Windows and Linux, which greatly improves my ability to hack on it during idle moments at work.

This means that, after 7 years, the first third of the project might actually be working.

So by that measure, there's only 14 years of head-butting pain left to go!

The release rate and delta of SQLite itself has been fairly tame, and in Perl land we've seen a significant reduction in the severity of bugs compared to 2010.

Because of the significance of DBD::SQLite and the need for extended testing periods, it has been my policy to allow smaller fixes to accumulate without doing a release and to release DBD::SQLite in line with SQLite releases that recommend upgrading.

The recent 3.7.8 release of SQLite does not come with an upgrade recommendation for our current SQLite version, but does suggest upgrading as optional. This release contains some significant index performance improvements (described as "orders of magnitude faster") for large CREATE INDEX commands, and DISTINCT, ORDER BY and GROUP BY
statements are now faster in all cases.

The 3.7.8 release also contains some changes to make SQLite play nicer with Windows anti-virus programs.

I personally have several use cases that would benefit significantly from these changes, and I'm sure there are many other similar cases.

As a result, I would like to do the next production release of DBD::SQLite now with the optional upgrade, rather than waiting for the next official upgrade recommendation.

As the recent changes to binding may result in breakages, I'll be allowing an extended period for testing. This is in line with previous requests from downstream packagers and corporate QA departments to allow for longer testing periods in periods of significant change.

Pending any further bugs which result in significant changes, I'm planning an initial release date of the 22nd of November, some time in Sydney business hours.

If you have significant downstream dependencies, please start testing now with the current 1.34_02 release.

And it's certainly the best and most stable release since late 2010. But looking forward to 1.0 there's one glaring project-level issue left.

Once we do a "stable" release, we should finally be aiming to achieve fairly decent back-compatibility. And Padre has definitely tossed aside back-compat in exchange for faster development at every opportunity so far.

So if we're going to do a 1.0 release, we probably should take one final pass over the major APIs and break them horribly so that we have APIs that we're happy to support for a long time. And this is the major focus of the next 0.92 release.

One of the most important of these is Padre::Task, which is the API we use to run things in the background.

The new third-generation task API doesn't so much replace the second-generation one as rebuild it and complete it to the original concept.

The restoration of slave mastering provided the biggest memory win for 0.90, building a medium-weight threading model on otherwise painfully heavy threading model. It works by spawning one thread as early as possible after interpreter startup, and then having this slave master spawn all subsequent worker threads.

As a bonus, these subsequent threads are also spawned in the background and so they don't block the GUI. Which means we no longer need to pre-spawn any workers to avoid visible blocking, and we can just do all thread spawning on demand, which makes startup even faster.

On Windows, per-thread memory overhead comes down from 35meg to 16meg. In Task 3.0 we now do additional tuning of the thread stack allocation (which is overly generous) to bring the per-thread overheads further down to just 6meg. Cheaper threads means we can afford more of them, and so we can do more types of analysis or backups or indexing in parallel without significant memory cost.

It also opens up the idea of permanently running background "services" for continuous communication or monitoring, all without blocking the foreground.

To this end, Task 3.0 provides a new set of cross-platform functionality which allow background tasks to communicate with the foreground, and allow the foreground "owner" of a task to have more fine-grained awareness of the state of the task, and to communicate
back to the task in response to messages from it.

This has already allowed the experimental Swarm plugin (which enables collaborative development) to move it's communication stack into the background. It should also enable indexers and other analysis to occur incrementally without bothering the front-end, or for continuous integration or continuous execution of your test suite.

It may also mean we can implement concepts such as host services, for example a common POE background thread where many different lightweight IO-bound tasks can share a single background thread instead of needing one of their own.

It would also allow the creation of GUI applications with POE/AnyEvent embedded logic that doesn't require full integration of the runloops, and an entire CPU is available for the POE runloop separate to the CPU for the front-end.

Finally, Task 3.0 does some of the internals of threads more cleanly, join()ing instead of detach()ing, and shutting down background tasks much more correctly than we previously did.

The rewrite isn't quite done yet, but it's starting to look pretty damned sexy. The kind of thing that it might finally be worth spinning out as a standalone CPAN module to be included in any Wx applicaition.

I was distracted with getting wxFormBuilder integration to a working state, Ahmad Zawawi was distracted by his efforts to build our own Scintilla wrapper instead of waiting for Wx to upgrade, and the broken threading had people annoyed at Padre's bugginess (and me) and not wanting to contribute a whole lot.

But with the problems of background threading, rapid GUI development and having an editor widget we can actually control solved, things are starting to move forward again rapidly.

We've also seen a recent boost to volunteer numbers, with some oldies returning (prompted in many cases by Padre's birthday party easter egg) and some newbies arriving to solve specific problem areas like Mac support and packaging.

With the big problems out the way the team is able to start looking at polishing out some of the smaller problems that weren't a priority until now, and we can start to upgrade some of our crude first-generation tools into much nicer versions.

The following screenshot sums up some of the new improvements fairly well.

Firstly, this setup is using the experimental feature_style_gui setting which will cause the colours of a number of tools to match themselves to the colour of the editor window. This is extremely crude at present and is done mainly to allow us to see the visual implications of allowing more control over colours (we need to ensure it works on all platforms, and so on).

Secondly, you can see Ahmad's initial demonstration of "squiggly underlines" for the syntax checker. This is a hallmark of all modern desktop IDEs, and merely having it makes us look more "real" as an IDE.

As a bonus, Padre now does proper dwell updating of tools. Tools sit silently without wasteful polling timers, and then when you stop typing for more than 500ms they all fire off and generate updated contents (in the background).

We also have an upgraded introspection tool (the lower of the two white windows) to let you interactively examine Padre's internals, and a new Parser Tester (inspired by PPI::Tester) so you can type in some content and see the parsed form of the document update in real-time per-keystroke.

Finally, for the resource constrained we've also found even more memory savings. We now delay loading Wx image handling where possible, saving 3meg of RAM in image drivers we will never need.

And a new Padre::Feature module ensures that all those experimental features and unwanted features (like folding or bookmarks) not only don't appear when disabled, but are compiled out of Padre entirely at an opcode level, saving about 2meg of RAM on my install.

The upcoming 0.90 release is looking about as close to a proper "Beta" release as we could want.

After 0.90, we have one final round of "move it or lose it" massive API breakage before we start locking in the various major APIs to allow long term support of plugins, and we should hit the final 1.00 release well before Christmas.

Update: This is not the actual release announcement, just a couple of big changes that I think deserve some coverage in depth.

This is an immense release for the Padre team, the changes file entry alone is 140 lines.

Most importantly, this release completes the refactoring work on a number of internal subsystems.

Padre's threading architecture Padre::Task has been returned to full maturity after a long period of instability following the landing of the second generation Padre::TaskManager implementation.

Fixing the last thread leak bugs allows the reintroduction of our "slave mastering" technique, where we spawn a clean "master" thread as early as possible during startup, and then spawn background worker slave threads off this master thread rather than off the foreground thread. For a typical Padre instance, slave mastering results in a reduction of 15meg of RAM per thread (and there is further improvements to be gained in this area by requiring less of Wx to be loaded at startup).

Being able to trust threads again makes it easier to pay more attention to the features which rely on it, such as the Function List. In Padre 0.88 the Function List will now correctly identify glob assigns as function declarations and correctly jump to them on double click.

This release also sees the final removal of the deprecated Padre::Wx::Dialog dialog toolkit. This dialog generator was introduced way back in the 0.10-0.20 period as a way to produce simple grid-based dialogs. Unfortunately the dialogs it produced were fixed width and did not use sizers properly.

Our second-generation dialog workflow uses the cross-platform wxFormBuilder application to design GUI elements, and Padre::Plugin::FormBuilder to generate complete dialog/frame/panel classes directly from wxFormBuilder's native file format in a manner similar to the original Glade.

This approach decouples the layout of dialogs from their functionality, and will allow people with usability skills to tweak the dialogs without having to go through the steep Wx.pm learning curve first.

We now have 11 dialogs in Padre created using this new workflow (including the main preferences dialog) with other hand-written dialogs to be converted to wxFormBuilder in future.

More importantly, all Padre dialogs should now all scale correctly on all three platforms (Win32, OSX and GTK) which makes us look a LOT less dinky.

With Padre, we've certainly gone a long way towards demonstrating that building large desktop applications in Perl is possible, and the stresses caused by Padre on it's underlying libraries has driven the improvement of Perl support for the dominant cross-platform GUI toolkit wxWidgets.

With library support relatively mature, and a number of people working on improving installers for Padre and Perl desktop applications, the next outstanding problem is the complexity of the Wx.pm API and the fairly steep learning curve when it comes to producing Wx.pm GUI and dialog code.

So it with great pride that I present the first working production release of Padre Form Builder, the first native cross platform GUI design solution for Perl.

http://svn.ali.as/cpan/releases/Padre-Plugin-FormBuilder-0.02.tar.gz

The main challenge when writing any GUI design tool is the sheer amount of code you have to write to get to even a minimally useful product.

First you need a deep understanding of the target API. Next you need some kind of meta-model for representing the design, and a file format to encode it. Then you need to hand-roll a GUI application which can do user-interactive on the fly generative layout. And then finally you need to write all the codegen stuff which turns your meta-model into working code.

Padre Form Builder shortcuts most of this by leveraging the popular existing wxFormBuilder tool.

With wxFormBuilder we have a stable, popular and working design tool capable of spitting out fairly decent C, or relatively ordinary Python code with exactly the same line-by-line structure as the C code. What wxFormBuilder does not do, however, is generate Perl code. And even if it did create Perl code, judging by the Python it produces the Perl code wouldn't be particularly amazing either.

In addition, adding Perl support for wxFormBuilder would violate my rule that good development tools for a language should be written in the same language.

So instead I've taken the alternative approach of parsing wxFormBuilder's native XML save file and generating Perl from that instead.

At the base of this Padre Form Builder implementation sits FBP.pm, a parser and object model for the wxFormBuilder file format. This file format is superior to the native Wx XRC format for several reasons, no least because it has support for specifying event bindings for widgets and codegen properties such as whether a particular widget should have a public accessor or be private and inaccessible from outside of the dialog class.

With a working object model for a wxFormBuilder project, the second layer of functionality is provided by FBP::Perl. FBP::Perl provides the core code generation functionality for producing elegant, readable and scalable Perl code for the different types of widgets supported in wxFormBuilder.

Support for wxFormBuilder elements is as close to complete as possible. In addition to the normal widget and layout generation, FBP::Perl support many of the more fiddly bits of GUI development such as custom colours or fonts, tooltips and localisation of GUI elements via Wx::gettext.

And all of the event binding via Perl Wx::Event::EVT_EVENT_NAME calls are supported as well, with stub event methods added to the generated code.

Finally, on top of this code, is Padre::Plugin::FormBuilder itself.

Padre::Plugin::FormBuilder provides a GUI for selecting a wxFormBuilder save file, choosing elements within it to generate, and setting options on the generated code.

In addition, it provides a custom sub-class of FBP::Perl that can generate Padre-specific GUI code so that for one design you can produce either a standalone dialog, or a dialog tailored for use inside of Padre or a Padre plugin.

Right now, the Padre Form Builder plugin is only capable of relatively straight forward functionality, generating a single dialog at a time into a new document and leaving it up to the user to save it over the top of the old version.

In future releases, however, I plan to expand the functionality of the plugin to generate (or regenerate) multiple dialogs at once, or to allow a wxFormBuilder save file to bootstrap an entire working Perl GUI app distribution (similar to our current Module::Starter integration).