Padre 0.88 - Internals refactoring completed!
Padre 0.88 has just been released.
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.
I blog about Perl.
You could call the early-spawned thread the zygote thread, in keeping with terminology established in Chromium.
Hi Adam,
I'm glad you finally got Padre::Task 2.0 to do all that my original implementation did and more. And cleaner. But it does fill me with considerable, evil enjoyment that it was hard for you, too, to get it working and non-leaky. It was painful back in the day.
Furthermore, I do kind of like the slavedriver name, even if it's just to poke fun at the oversensitive. ;)
Not that it matters, but I kind of wonder when the term zygote thread was coined. My 3G connection is flaky, so I can't check the Padre SVN logs, but the usage of the "slavedriver thread" goes back a couple of years.
I don’t have any issues with the name, just being pragmatic. If you use the Chromium terminology, quite a lot of people from outside the Padre cadre will immediately understand the concept behind it without having to explain it every time it’s mentioned. Chromium has far more pull than Padre and therefore more leverage to establish new jargon, and they also picked a memorable (by way of novelty) name here. Even so I am just pointing it out for consideration, not arguing for its adoption.