Redesigning Package::Strictures

Package::Strictures on metacpan

Design goals

  1. An infrastructure for having “optional” code blocks that can be eliminated prior to execution.
  2. Ideally, these code blocks can be toggled by calling code and then eliminated from the execution tree at the OP level.
  3. In essence, delegate 100% of the “Speed vs Correctness” concern to the consumer of the code, not the implementer.

Presently implemented using dead-code folding mechanisms.

if( 0 ){ 
   /* code */ 

Which becomes

/* noop */

Additionally, this is implemented with perl constant subs so that the if logic is performed at code body compile time, eliminating any run-time penalties from doing the check:

   if( $ENV{A} ) { 
           eval "sub foo(){ 1 }";
   } else {
           eval "sub foo(){ }";

sub runs_billions_of_times {
  if( foo ){

So that at run time, the sub will either be

sub runs_billions_of_times {


sub runs_billions_of_times {

( With the goal being there is no runtime if test done in each and every loop ).

Musing on Perl::Critic config

I've been exploring the Perl::Critic configuration file somewhat, and something struck me as unusual.

It seems fine for using for the usecase of "inherit some predefined set of rules and apply them selectively", which works fine if you just want to adopt some other standard that is pre-existing, and just make minor adjustments.

However, if you're wanting to create policy sets for others to use, it seems poorly suited.

1. Existing Systems

1.1. Severity level

This feature seems confusing.

It looks simple at first, but its problematic for anyone to utilise this to create a large, custom policy set.

The gist I get of reading it is you specify a severity level in your configuration, and policies that are included with a larger severity number than that are used. ie: Specify severity = 2 and items with severity levels 2,3,4,5, will be applied, while rules with severity level 1 are ignored.

The documentations suggest it might be a good idea to manually override the severity level for a plugin, ie:

YAPC::Europe 2013 in Kiev, week minus 37. More ideas about extra programme

Dear Perl users,

Two weeks ago I mentioned a couple of activities that I found nice to have in the conference. Today I will tell about other things that we already tested during our previous events.

In 2009, at YAPC::Russia in Moscow Alex Kapranov hosted the Game of the Future, where we were trying to predict the future of Perl and related things. There were a few groups that were compiling the future based on probable or improbable events that might happen in a few years, as well as on the known facts. As a result, a mind map was build, which is quite interesting to read today:

What is the future of Perl.pdf

Screen Shot 2012-11-27 at 10.31.56 PM.png

You may find a number of region-specific items there but the funniest thing is that we were considering the YAPC::Europe in Kiev an unlikely event at that time.

Perlybook on

I added to Hopefully we get some pull requests to iron out the issues we have.

Another related project I added is EPublisher-Source-Plugin-PodFromGithub. When we have finished that plugin we would be able to convert stuff like the Perl Advent Calender articles into ebook formats.

Due to private reasons I wasn't able to finish that plugin before December started :-(

Have you added your Perl project to takes the spirit of the Advent coding calendar and puts a new spin on it. Try to send one pull request per day for the next 24 days and will help you track your progress. At the time of writing, 1,224 devs have already signed up.

Some Perl projects are already represented, but there's still room for more. It would be good to see some more Perl projects on the list for participating Perl devs who are looking for something to contribute to.

Recently while developing...

...some new stuff for I got an error message and needed quite long to find the cause. This was so unexpected too, because I have not done much changes.

The error message I got:

Unrecognized character \xCD; marked by <-- HERE after og->debug(<-- HERE near column 26 at script/../lib/ line 43.

Here is the code:


Who finds the error first?
Ps: dusty screens will make it harder!

Boris Däppen

Documentation for Fun and Profit

Last week at the London Perl Workshop, I gave my first ever talk. 20 minutes on the subject of documentation. I'm pleased to say it went very well, and I've had some fantastic feedback from everyone who saw it.

I thought the wider perl community would appreciate having a look at my slides. As always, it would make more sense to hear me talking - but this gives a good idea as to what the talk is about.

If anyone wants to invite me to speak at exotic locations around the world, I am available ;)

Documentation for Fun and Profit

Dancer GitHub repository move

The Dancer repository on GitHub has been moved, from Sukria's own GitHub account to live under the PerlDancer organisation on GitHub.

This has been done to better share administration duties between the core dev team, and enable commit bits to be distributed more easily where needed.

However, this does mean that the old repository URL will no longer work - the repository is now found at:

If you have a checkout of the Dancer repository, you'll need to tell git about the new upstream URL - if you had a commit bit, so had a read+write checkout:

git remote set-url origin

Otherwise, e.g.:

git remote set-url origin git://

If you have a fork of the Dancer repository, similarly you will need to change the upstream location:

git remote set-url upstream git://

The Dancer project website will be updated shortly to link to the new repository.

About is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.