|
Apocalypse 12 Unleashed; Perl 5.8.4 Nears Release; The Perl Foundation Awards New Grant; MySQL Issues License Exception
April 01, 2004
URL:http://www.drdobbs.com/web-development/perl-news/184416107
Apocalypse 12, a 20-page essay addressing the Perl 6 object model, is now upon us. This is the latest Apocalypse since Apocalypse 7, which consisted of just two sentences. As Larry explained on the perl6-language list, the Apocalypses are numbered in order of their importance to Perl 5, but they're being written in order of their importance to Perl 6. Therefore, Apocalypses 8 through 11—covering References, Data Structures, Packages, and Modules—have been skipped for the time being.
"What we're proposing," Larry writes, "is to develop a set of conventions for how object orientation ought to work in Perl 6—by default. But there should also be enough hooks to customize things to your heart's content, hopefully without undue impact on the sensibilities of others. And in particular, there's enough flexibility in the new approach that, if you want to, you can still program in a way much like the old Perl 5 approach."
The full text of Apocalypse 12 is at http://www.perl.com/pub/ a/2004/04/16/a12.html.
As of press time, Perl 5.8.4 has made it to Release Candidate 2, as RC1 had unexpected problems installing suidperl. Barring further surprises, the final 5.8.4 release should be out within a few days.
Suidperl had to be changed to fix a security vulnerability. Although backwards compatibility with scripts that invoke #!/usr/bin/suidperl has been preserved, the perldata warns: "For new projects, the core perl team would strongly recommend that you use dedicated, single purpose security tools such as sudo in preference to suidperl." Perl 5.8.4 also fixes another security hole involving attempts to assign unreasonably large amounts of memory, which would previously crash perl, potentially opening up a "stack smashing" vulnerability.
The Perl Foundation has announced a new development grant: Simon Cozens has been awarded $1000 to work on Maypole, a Model-View-Controller (MVC) framework for web applications. Maypole is designed as a Perl equivalent to Jakarta's Struts framework. (See Simon's article on Maypole in this issue.) As Simon writes on http://maypole.simon-cozens.org/, "Many web applications follow the same kind of flow of operation: In response to a request from a user, they mess about with a database, and present the results of that messing about back to the user through some templating system...Maypole provides a generic way of handling that compartmentalisation." Bottom line: "It means you can write fully featured interfaces to a database in less than 20 lines of code."
Maypole is currently in Version 1.4 (available from CPAN); the Perl Foundation grant will go towards developing view and template classes for HTML::Mason and DBIx::SearchBuilder, as well as finishing the Maypole documentation and producing example sites. Existing Maypole users are encouraged to get involved; there's a mailing list accessible at http://lists.netthink.co.uk/ listinfo/maypole/.
MySQL AB has solved a potential problem for DBD::mysql users by issuing a specific exemption to the license under which MySQL client libraries are distributed. As of MySQL 4.0, these client libraries were distributed under the GPL rather than the LGPL, which raised problems for developers who work with Perl, PHP, or other languages distributed under nonGPL licenses. The issue came to a head when the PHP packagers removed the MySQL client libraries from PHP 5.
MySQL AB's exemption, published at http://www.mysql.com/ products/licensing/foss-exception.html, specifies that applications distributed under any one of 18 open-source licenses—including Perl's Artistic license—are free to incorporate MySQL client libraries without changing their own license terms. It's formally termed the MySQL FOSS (Free and Open Source Software) License Exception.
Andy Adler has discovered a problem in the code he presented in his article on Inline::Octave in last month's TPJ. According to Andy:
Mea culpa. I made a mistake in the code presented in 'Perl and Inline Octave Code,' which meant that the 'temp-analyse.pl' code would hang in some situations. The short solution is that I've released a new version (0.21) of Inline::Octave, which fixes the bug.
For those interested in more detail: Since Inline::Octave starts a child (Octave) process, it would like to know if it dies for any reason. Therefore, it sets $SIG{CHLD} and $SIG{PIPE} to handle this event. Unfortunately, the module user may well be starting child processes (such as 'unzip,' in the example given) or setting signal handlers. In the example, the user's child process termination got caught by the wrong handler. In order to solve this problem, Inline::Octave now only sets signal handlers (using local) immediately before any interaction with 'Octave' and allows them to be reset afterwards.
Sorry for any inconvenience. If nothing else, I've managed to point out that this kind of IPC can be tricky.
—Andy Adler
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.