There are many things you might do to speed up your Perl code. After profiling and benchmarking, you revise the slow spots, or maybe try a different algorithm. If you still need more speed, you may use Inline::C, or use PDL if you are doing numerics, or even write your own XS code. Reini Urban has even tried to create a Perl Backend that rewrites your Perl code as C code, and has even worked on a port of Perl5 to Potion.
But let's face it. Sometimes it would just be easier if you could write your code in C, and interpolate a string into it. Wouldn't it be nice if there was a C equivalent of Perl's string eval?
Pushed Ouch 0.0404 to CPAN. It turns out I was using some Perl 5.10 and 5.12 features (use parent and use overload respectively) and that was causing some CPAN testers errors, and also problems for folks on old Perls. So I’ve made Ouch explicitly require Perl 5.12 going forward.
The CERT program at Carnegie Mellon University has created secure coding guidelines for several programming languages, including Perl. It is a community effort, and guidelines are written and discussed on a wiki-style platform.
Some of the guidelines are associated with Perl::Critic, so I've given my 2 cents on those. David Svoboda is the lead author for the Perl guidelines, and he has been very responsive to my feedback.
But I'm no authority on Perl security issues. I'm sure David would love to get some input from real experts in the field. So if you'd like to contribute to this important and highly visible resource, then hop over to CERT's Perl page and request an account.
(this is the email sent to the Dancer users mailing list, updating on recent releases)
Hey,
we have just released a new version of Dancer 2: 0.08. While it didn't carry everything we had wanted (one specific change was left for 0.09), we decided it is more important not to delay features and fixes. We can also do another release next week, right?
This was the biggest Perl event I've attended so far.
Also, it was the first one I've attended outside of Brazil.
And I'm happy to see that there is so many people in Ukraine who are passionate about Perl!
So, listing some of my impressions below.
The supporting slides for the YAPC::EU lightning talk that I had in the first day of the conference are here:
Because the slides are just a few and the presentation was in a rush, I wrote a extended blog post regarding what is PRForge and how it can help the Perl community to increase its overall audience on my personal blog.
I've finally realized that instead of people worrying about false, or ever true, reports of Perl's demise, we can generate some factual (nice change!) data about Perl activity.
So, I'd like to see someone analyse the postings to the archive of modules at perl.org. See e.g.:
I've given a couple of presentations recently, and my YAPC::EU talk in particular got some requests for the slides from the audience. I've embedded them below. Enjoy!
MarpaX::Grammar::Parser parses your grammar and outputs a tree managed by Tree::DAG_Node. The real purpose of this module is to provide a compressed version of that tree (unwritten) as input for MarpaX::Grammar::GraphViz2.
MarpaX::Grammar::Parser actually uses Marpa::R2 to parse your grammar, and my module parses the output of that to generate the tree.
After asking around, I gave Giannis "feeder" a second look. Indeed adding the missing features was almost trivial and Gianni was highly responsive about merging my patches.
MarpaX::Demo::JSONParser offers you a choice of grammars to parse JSON. The first was written by Peter Stuifzand, and the second by Jeffrey Kegler. I have just packaged them (with permission of the authors).
After a marathon hacking session yesterday I’ve got a working server up for The Captain Is Dead (TCID). Many video games can be developed by basically creating a state machine, which is essentially what I’ve done for TCID. All you’re doing is tracking the set up of the game map, and what state all of the components attached to the map (including the players) are in.
I’m writing TCID video game in Perl using a toolkit we developed in-house called Wing. Wing is effectively a set of preferences for developing web-service enabled web apps. It glues together all our favorite components such as DBIx::Class, Dancer, Moose, Config::JSON, jQuery, pNotify, Bootstrap, beanstalkd, and a whole lot more. Without it there’s no way I would have been able to build out a working video game server in a day.
Lot’s yet to do, but I’m glad to finally get started on this project.
Or how to execute arbitrary Perl code using Gearman and B::Deparse.
Perl offers us the flexibility that empowers us to clearly separate code that deals with different concerns.
As developers, we should take advantage of it and build reactive, flexible and generic enough business components.
As an infrastructure developer, I don't really know what people are going to do with gearman, nor should I care too much. I'll introduce an approach that lets me concentrate on what is important: the stability, scalability and the security of my gearman workers.
As an application developer, I don't care that I have to encode my functions parameters in a certain way. And I don't want to bother changing code in some obscure gearman module when I make changes to my business code.
What I want is to use gearman as a facility that helps me design the best possible application without getting on my way too much.
Building a complex web app almost never goes without the need to write a handful of command line tools. Whether it's to alter the database schema, convert image files, or move records from one format to another, you know you'll have to create a bin directory and fill it up with CLTs.
The Perl Kelp web framework makes this task easy with its robust and flexible configuration module. The default config file lives in conf/config.pl and contains a Perl hash of configuration options. For example:
Wing has long been able to generate internal object relationships thanks to the goodness that is DBIx::Class, but now it can automatically write the web services for those relationships as well, thanks to two new subs in Wing::Rest:
generate_relationship(object_type, relationship_name) - This writes out a simple web service that will expose a list of “relationship_name” objects that are attached to “object_type”.
generate_all_relationships(object_type) - This interrogates DBIx::Class to find all the relationship objects and then calls generate_relationship() on each of them.
