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?
(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.
I love open source programming. I’m continually humbled to see even the small impacts that my contributions to the Perl community have made for fellow programmers around the world. Mostly my use of Perl has been to write a complex simulation and the tools that it uses to simulate the dynamics of electron bunches in an Ultrafast Electron Microscope column, which is the subject of my recent Ph.D. thesis. So while I have enjoyed sharing my work both here and at the 2012 YAPC::NA I never would have expected that my name would mean too much in the greater Perl world.