After 6 or 7 months (mainly waiting around for the next "recommended upgrade instruction" from the SQLite project) the latest DBD::SQLite release should occur next week.
You can get the 1.30_06 release candidate from the CPAN, or from the following URL if your mirror hasn't synced yet.
Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.
With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.
For example, some random author that is trying to checkout a Catalyst project needs:
1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.
It's been my experience that Microsoft doesn't necessarily work that way, except in a limited fashion.
What they are both interested and capable the most in is in the area of "Interop" as they call it. Contained, concrete steps they can take to remove roadblock from the path of otherwise active technologies, and to make them work better on Windows.
Some of these are financial, like the CPAN Testing Lab and their (rumored) free code signing certs. Some are toolchain related like CoApp.
The issues where they are the only ones that can fix a problem are the ones they are the most interested in. I can bring it up, but I suspect you won't see much interest.
Next week I will at Microsoft's TechEd Australia event, courtesy of Microsoft Australia and Microsoft Open Source Labs.
More specifically, I'll be attending the Open Source mini-conf and discussion day on Tuesday, and presenting in the Community Presentations to Microsoft session on the current state of Perl and Windows on Wednesday.
The new 1.07 release of Class::XSAccessor mentions the use a new somewhat-evil technique for making the code even faster than it was previously.
But how much faster is it?
The following are being run on a fairly typical corporate Windows XP machine, with Strawberry Perl 5.10.1 and thread support.
First, some benchmarks using the previous 1.05 release (two runs)
http://perlalchemy.blogspot.com/2010/08/objecttinyrw-and-moosexnonmoose.html
Zbigniew Lukasiak tries out Object::Tiny and wonders why it is that I didn't allow for the creation of setters when it is only a one line change.
Like most
... or at least give me all MY data in a SQLite database or something, so I can migrate it?
(Assuming the site goes away, of course)
I created ORLite to address precisely the problem you are talking about.
ORLite tries to use as little abstraction as possible, and in particular there is no abstraction of where clauses.
my @objects = ORLite::TableName->select( 'END_SQL', 'Bob' );
where name in (
select name from people where husband in (
select name from people where name like ?
)
)
END_SQL
Back in 2005 in only my fifth use.perl post ever, I outlined an idea I had been developing for a couple of years that I called "Trailer Theory".
A few years ago on my Portable Perl world hack'a'tour, I took with me a lightning talk version of the concept. It was a pretty crude talk but was received, it seemed, fairly well by the development community.
The idea of encapsulation is the very reason that we have most APIs.
The idea that you don't NEED to know how something is implemented is always going to be better, as long as that lack of knowledge does not compromise the integrity of the systems or lead to perverted incentives.
What good is a car that requires an intimate understanding of the underlying engine and brakes and gearbox. It might be handy if you are an enthusiast of a racing car driver or pushing the limits in some other dimension.
What good is a toilet that requires you understand the sewerage system?
But for the masses, encapsulation and the hiding away of knowledge is the primary goal. Encapsulation creates specialisation, which creates productivity, which creates prosperity.
No, this does NOT count as "heavy".
Perl 3,120 K
Perl + Moose 11,840 K
Perl + MooseX::Atom 11,852 K
To further clarify based entirely on memory load overhead (using only require, so without any work done in import methods).
Perl 3.1 meg
Perl + Moose 11.8 meg
Perl + MooseX::Declare 21.6 meg
