In May and June, I worked on converting the DBIx::Class repository from SVN to Git. I’ve had a number of people ask me to describe the process and show the code I used to do so. I had been somewhat busy with various projects, including working on the web client for The Lacuna Expanse, but I’ve finally had some time to write up a bit about it. The code I used to make the conversion is on my github account, although not in a form meant for reuse.
Marpa
is now at 0.200000.
Following a standard rhetoric of version numbers, this indicates
that it's an official release and a major step forward,
but still alpha.
Marpa is a general BNF parser generator -- it parses from any grammar that
you can write in BNF.
It's based on Earley's algorithm, but incorporates recent advances,
so that it runs in linear time for all those grammars parseable by yacc
or recursive descent.
The big news with Marpa 0.200000 is Marpa's 3rd generation evaluator.
The previous version of Marpa had two evaluators
-- one fast, but only
good for producing a single parse result,
the other capable of dealing with ambiguous grammars, but slower.
The 3rd generation has a single evaluator which combines the best
of both.
Not the least advantage of this change
is that it simplifies the documentation
and the interface.
At Jobindex we use Red Hat Enterprise Linux. The OS is very stable and we feel that Red Hat is doing a lot of good stuff for Linux and OSS in general.
When it comes to perl the current version RHEL ships with version 5.8.8 which causes a bit frustration however. Some CPAN modules won't install and it seems like the people who writes modules for CPAN don't really care about our (good) old perl verison.
At YAPC::EU several of the speakers recommended installing perl ourselves instead relying on the OS version.
We have now decided to follow this recommendation. At the same time we will also start using git to manage perl and the installed modules to keep the versions in testing and production in sync. This way we wil also avoid messing with RPM packages.
So now I am looking forward to getting my hands on perl 5.12.2 :)
We're using RT quite a lot. Today I needed to disable some 'Scrips' in one queue, while keeping the in all other queues. Unfortunatly, RT does not support this out of the box. While there is a plugin that seems to implement that feature (RT-Extension-QueueDeactivatedScrips) I decided to fix this without touching RTs innards.
The trick is to add a 'Custom condition' to the global script, which returns false for the relevant queue:
return $self->TicketObj->QueueObj->Name ne 'babilu::support'
Unfortunantly, this is not enough (and it took me some testing and manic clicking through RT to figure this out). You also need to change the 'Condition' from whatever the Scrip is using to 'User Defined', and then test for the condtion yourself:
For those of you who may notice such things, you might see that Padre's version number has jumped two numbers since the last stable release.
This development cycle we introduced a new versioning system whereby the odd number 0.71 was the development version with 0.72 the stable release version.
The reason we have done this is to accommodate development and changes to the plugin subsystem during the development cycle. We'll track how this goes and make changes where it needs to be made.
For much of this release, and I'll have to admit quite a few before, I've really been off doing other things, but I follow the irc logs for #padre to keep an eye on how things are developing within Padre.
However in saying that I have to say when it came time to roll out this release, the number of fixes and improvements in the Changes file blew me away. Admittedly it was a longer than normal period between releases, but still, there are some serious fixes in 0.72.
Thanks to Shlomi Fish who noticed the slides of the talk weren't imported very well on Slideshare. This is now fixed and you can find the slides at the same location working without a hitch.
I've also been enlightened that Slideshare only allows you to download slides if you're registered so we've added a section to Dancer's website to accommodate for slides of talks given about Dancer.
This is where you'll be able to view it (embedded) or download it in PDF form at your leisure.
SF.pm X-President Quinn Weaver will be speaking at Mother Jones on October 26th for our October SF.pm meeting.
Catalyst is the leading web MVC framework for Perl. Normally, Catalyst apps use an ORM to communicate with the database. While ORMs can be convenient, they can also hurt performance, tie your app to one database schema, and make complex queries difficult.
But this is Perl, and TMTOWTDI applies: There’s More Than One Way To Do It.
In this talk, Quinn take you through the code of a working Catalyst app that uses stored procedures rather than ORM queries as its interface to PostgreSQL. Along the way, Quinn will touch on a number of useful modules and pragmas such as DBIx::Connector, aliased, Template::Declare, and Test::XPath.
Credits: this talk is based on an app Quinn wrote with David Wheeler as a side project at PostgreSQL Experts. Thanks to David for coming up with the methodology, and writing the (IMO) greater share of of the code, including DBIx::Connector and Test::XPath.
An interesting topic came up on #distzilla. Most modules depend on other modules, but some don't depend on an explicit version. So if you use the module with an ancient version of one of its dependencies it'll break, because the author never tested that version.
We've probably all run into problems as a result of this and grudgingly upgraded the dependencies as a result, but could CPAN clients handle this better?
Technically they're doing the right thing already. The CPAN clients are unable to distinguish between "explicit 0", "any version will do" and "author didn't say".
Some don't specify versions at all. I mostly fall into this camp.
Even if you specify a version for every dependency it's really hard to get it right. You might accidentally use some API feature in a dependency that doesn't match the feature set of your declared version.
Even if you get it 100% right it's all for naught if one of your dependencies isn't as careful about its dependencies.
So what would be a better heuristic? Some suggestions:
This series of blog posts on
"Perl and Parsing",
which is evolving
into a mini-history of parsing theory,
started as an offshoot of
my own
attempt at a contribution to parsing.
I wanted to do a couple of blog posts
aimed at those trying to
decide whether it was better
to take a chance with my
new parser
(Marpa),
or to stick with the terrors of the known.
There's a large literature on parsing,
but much of it is difficult or dryasdust,
and I thought I could contribute a helpful overview.
"An informed consumer is our best customer" and all that.
Like other offshoots of the Marpa project before it,
while the "Perl & Parsing" was originally intended to draw
attention to
Marpa,
it's been better at drawing attention to itself.
I've received some positive comments,
and some helpful criticism.
I'm grateful for both,
and I plan to continue the series.
Come and enjoy Damian Conway, Perl luminary and all around great guy, as he presents his seminar, The Missing Link. The topic will be focused on Perl, but should be entertaining to all programmers.
I've done a lot of web scraping with Perl over the years, but I hadn't experienced anything quite like the "Next page" link that ASP.NET threw at me this week. The opposite of REST, ASP.NET's ctlPagePlaceHolder makes the simplest navigation beyond the reach of WWW::Mechanize as far as I can tell. Luckily Selenium came to my rescue.
If you haven't experienced Selenium automation, it's quite impressive. From a normal shell window (OS X Terminal.app in my case) you launch a Java server
and then use WWW::Selenium in your Perl program. As your Perl program runs it launches Firefox on your local workstation and performs whatever commands you issue. In my case this was simply "click 'Next Page'". :)
The Selenium IDE Firefox plugin is great for quickly mocking up what commands you need. Once it's working, drop those commands into your program to get the job done.
Many subtle changes have been happening to the CPAN Testers family of websites. Several have had some slight alterations to allow the additional Metabase link to appear. The website family is growing and I hope to have another added to the list before the end of the year. The codebase behind the scenes has also been upgrade for several sites to the latest version of Labyrinth, which is the version that is currently being managed for Open Source release. Once Labyrinth has been released, the remaining code for the Reports, Blog, Wiki and Preferences sites will also be released. Anyone then wishing to submit patches will be able to do so much more easily.
You might notice the it says "for Python programmers" - that's right. I've made the slides more attractive to Pythoners. This was done by comparison to Flask (the Pythonese Sinatra) and it's interesting to see very clearly that in this case, Python had some really hairy syntax and ugly code to provide something that two lines of Perl provided more clearly.
It was a lot of fun and I enjoyed attending the other lectures (which weren't all about Python). The people were very nice and even though I was ready for snickering and mini-insults on Perl, I didn't get any. Perhaps one or two that were clearly humor and were outdone by the positive energy of people there.
So, I was looking for a Cat model to access REST services the other day. I couldn't find one so I decided to write it. With the latest release it should be pretty usable.
If you need to access a REST service from your Catalyst Application, perhaps you could give Catalyst::Model::REST a try.
It's simple, really, You can specify which server you want to talk to, and which serializer you want to use. for example
<Model Name>
server http://localhost:3000
type application/json
</Model>
UPDATE The type attribute changed to the same as content_type in version 0.08. I updated the example to show the new style.
I have this module that is failing tests on IRIX only. I do not have any knowledge of IRIX, I do not own an IRIX machine, and I do not want to create new releases of the module printing debug information on tests, so that I can analyze what is going on. This would be kind of tiresome. I needed to create a new release, upload to CPAN and wait for it to be picked by those specific CPAN testers that own an IRIX platform.
What I need is one of two things:
Someone that help me testing the module (and hopefully helping me to understand what's wrong on IRIX)
Get some CPAN testers on demand, where I can submit a tarball, choose a specific platform and wait for the test results.
Given that we (Perl community) do not own the later, is anybody willing to help me? :)
There have been a number of blog entries, tweets, reddits, diggs, and everything else in the Perl community over the past couple of days about The Lacuna Expanse. It's super cool to see the excitement level; it wasn't something I expected.
I figured it was about time that I made a bit of a post about it. So here I am, hoping to answer some of the questions I've seen posted, and talk a little bit about how the project came together and what that means for the Perl community. Whew! Seems like a lot for one post. =)
