Dave Cross:

I’m not going to object to Module::Build leaving the core. I’m sure there are good reasons, I just wish I knew what they are. I am, however, slightly disappointed to find that Schwern was wrong ten years ago and that ExtUtils::MakeMaker wasn’t doomed.

Schwern wasn’t wrong and MakeMaker remains doomed all these years later. It’s still around only because there hasn’t been anything to take its place. Module::Build looked like it was going to be that usurper – but didn’t work out.

Note that the reason that, between EUMM and M::B, M::B is the one leaving the core, is that EUMM is necessary to build the core and M::B is not. The reason for that is that no one bothered to port the existing MakeMaker-dependent infrastructure to Module::Build. And that never happened because M::B never gained the necessary features (XS support, mainly) fast enough for anyone to want to – because it wasn’t sufficiently much better than EUMM for anyone to want it enough to add the features.

However, EUMM is about as marginally maintained nowadays as M::B. Both are doomed, though their type of doomedness is one that’s accompanied by remarkable staying power. (Break-the-CPAN status tends to have that effect.) RJBS is on record that, should EUMM ever become unnecessary to building the core, it will make its exit stage left much the same as M::B is making now.

So… what happened?

Jonathan Barton made this super cool new client for the Lacuna Expanse, that allows you to automate a lot of functions in the game, to make massive empire management easier. 

I couldn’t agree more with Genehack’s “Stop Talking About Perl” talk at YAPC this past week. We spend so much time venting hot air. That’s not going to attract new users. Instead, we need to build cool stuff. Whether you’re into building cool new ecosystems like Moose, Dist::Zillla, and Plack, or if you’re into building cool new apps like Lacuna and The Game Crafter, building cool stuff and talking about that is the way to get people excited about your language. 

Actions beat words every single time. 

[From my blog.]

You pay a constant price in your app's starting performance for each time you use autodie;.

Here's a quick benchmark:

$ time perl -E 'say "package X$_; use autodie qw(:all);" for 1..100;' | perl

real	0m1.482s
user	0m1.431s
sys	0m0.047s

Compare with Moose:

$ time perl -E 'say "package X$_; use Moose;" for 1..100;' | perl

real	0m0.343s
user	0m0.328s
sys	0m0.016s

It doesn't get much better without qw(:all):

$ time perl -E 'say "package X$_; use autodie;" for 1..100;' | perl

real	0m1.212s
user	0m1.169s
sys	0m0.047s

But it gets significantly better if you import only a small number of functions:

$ time perl -E 'say "package X$_; use autodie qw(open close);" for 1..100;' | perl

real	0m0.175s
user	0m0.166s
sys	0m0.011s

Basically, you pay for each function you import, once per function instance, in each module, again and again. That's different from, for example, Moose, where 99% of importing performance hit is on first use, when perl compiles all the code, and then each subsequent import() is almost free. Due to this, if your app has many modules, autodie can easily become the biggest bottleneck in its starting performance.

So, it's a bad idea to add use autodie qw(:all) thoughtlessly to your boilerplate, in addition to use strict; use warnings; use 5.0xx;. If you do need to use autodie, it might be a good idea to explicitly list all functions you want to replace.

PS: I don't know why it should be that way. I know autodie 2.18 does more caching and is significantly faster than previous versions, but it still doesn't cache much, apparently.

PPS: This post was brought to you by questhub, as usual :)

Fast forward to mid 2013. I last wrote about some checksum one-liner, and it was also pretty much among the last few Perl things I did that year before getting distracted by $WORK (again.)

Now is the time to change that ;)

I'm putting the final touches on UAV::Pilot v0.3, which will have a better event-driven API and support control through Joysticks and (maybe) Wiimotes.

This brings me to the point on the ROADMAP I've been dreading: handling the video stream. The Parrot AR.Drone v2 sends an h.264 stream over the network. I can save this to a file easily enough, I suppose, but decoding and displaying the stream in real-time (probably to an SDL window) seems like an obvious thing to want to do.

However, the only CPAN module I've found for any kind of video encoding is FFmpeg, and it only supports reading from a file or URI, not an open network stream.

Does anybody know of another option out there? I can write the bindings to a C library myself, but I'd prefer to avoid it.

cross-posted from dams blog

New And Improved: Bloomd::Client

thanks to @yenzie for the picture :P

Sir,
In the free document for beginners, http://www.perl.org/books/beginning-perl/.. There is a mistake in chess game program at declaration part (not related to perl but Chess).

i.e in Chapter 7. References ( Page : 233 )

Now it is,
my @back = qw(R N B Q K N B R);
But it has to be,
my @back = qw(R N B Q K B N R);

That is : Chess pieces must be placed like mirror image for pieces R, N and B..

Left side : R N B
Right side: B N R