Without knowing it, both Steffen Mueller and I released modules this morning related to using the Tiny C Compiler for compiling C code at runtime! I have tried to make a fuss about mine (as evidenced by my blog entry this morning), but neither of us were aware of the other. Hopefully we can combine forces. Steffen, of course, knows an aweful lot more about typemaps and the available typemaps module ecosystem than do I. I plan to contribute the energy and enthusiasm! :-)
My Alien module for tcc is on cpan and github, and my Perl bindings for libtcc are also on cpan and github.
There is one other module related to tcc on CPAN, called C::TCC. For better or worse, the module doesn't really provide a means for sending much to it, or getting much back from it, and the module author hasn't replied to my emails. Who would have thought that two folks would publish unlrelated modules on the same fairly unknown piece of software just over four years since the last thing to hit cpan?
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.
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).