I like Mustache templates. Unfortunately, the obvious Mustache parser in Perl (Template::Mustache) is under-documented, over-documented, and not worth documenting. It has little example code and doesn’t make it at all clear that you basically have to subclass it for any real use.
Fortunately, this problem has been solved in Text::Caml. My one issue is that it’s too sensitive to whitespace. It’s good to give your eyes a resting place for sections and partials, like this:
{{# section}}
{{> partial}}
{{/ section}}
But Text::Caml will consider the leading whitespace as part of the name. Looking over the main Mustache docs, none of the examples show leading whitespace, and it’s never specified what to do with whitespace. So I guess Text::Caml isn’t technically wrong. I just don’t like it this way.
Other than that, it’s great.
Edit: Turns out the Mustache spec does say that partials and sections should be insensitive to whitespace:
https://github.com/mustache/spec/blob/master/specs/partials.yml (starting line 104) https://github.com/mustache/spec/blob/master/specs/sections.yml (starting line 252)
Edit 2: I reported the whitespace issue to the author’s github issue tracker, expecting it to be a fairly low priority. He ended up fixing it the next day :)
Full Disclosure: I received a free review copy of this book
I’m primarily a backend web programmer. I try to write in an object-oriented way with test-driven development practices, with each object having a well-defined purpose. I do this primarily in Perl, a language that causes many developers to get a twitch. The reason is that Perl has an old reputation as being messy line noise. Part of the reason for that reputation is because of the one-liner obfuscation games that used to be quite popular.
So when I first heard of this book, I was naturally inclined to avoid it. In a way, it’s perpetuating an aspect of Perl that’s best left as part of history. Besides, as a web developer, what did this book have to offer me?
What I found was that one-liners offer a different perspective, and it’s a useful perspective to have. Converting a text document to double-spaced lines isn’t a problem I have every day, but maybe I will at some point. When that or one of the many other problems this book addresses comes up, I’ll have something within easy reach.
Perhaps more importantly than any specific problem is the attitude that programming in this fashion doesn’t have to be inscrutable. Every one-liner here comes with a detailed explanation, and many come with alternative solutions with their own explanations. If we can document our concise solution in less space than a more “well-developed” solution would take, what’s the problem?
Donald Knuth had attempted a system called “Literate Programming”, where documentation and code are carefully interleaved. Jon Bentley, writer of the Programming Pearls column in Communications of the ACM, challenged Knuth to write a Literate Program for the following problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies.
Knuth wrote a 10-page program. Bentley then turned around and wrote a 6-command shell pipeline to do the same thing, which also happened to miss a few bugs that Knuth had stumbled over. The entire shell script and its documentation fit on a post-it note.*
One-liners can look like inscrutable line noise. But if we can otherwise document them in a succinct way, does it really matter?
That’s what this book does: provides solid explanations for extremely concise code. No matter what you do in Perl or your skill level, there’s something in here for everyone.
* See: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/
The main UAV::Pilot distro was getting too big. The WumpusRover server had already been spun off into its own distribution, and now the same is happening for many other portions of the system.
Reasons:
UAV::Pilot itself will contain all the basic roles used to build UAV clients and servers, as well as what video handling we can do in pure Perl.
UAV::Pilot::Video::Ffmpeg will have the non-pure Perl video decoding.
UAV::Pilot::SDL will take the current SDL handling, such as for joysticks and video display.
UAV::Pilot::ARDrone and UAV::Pilot::WumpusRover will take the client end of things for thier respective drones.
I expect the first release to have interdependency issues. I’ve tested things out on a clean install, but I still might have missed something. I’m going to be watching the CPAN smoke test reports closely and filling in fixes as they come.
From the recent blogs.perl.org hacking:
The password is salted and encrypted (with crypt)
This is what I expect out of the PHP community.
Noted: http://perltricks.com/article/61/2014/1/21/Make-your-code-run-faster-with-Perl-s-secret-turbo-module
The original server code for the WumpusRover was bundled up with UAV::Pilot in version 0.8. That meant that the HiPi modules were recommended for UAV::Pilot, even though that doesn’t make sense if you were installing outside of the Raspberry Pi.
So the server modules have been spun off into their own CPAN distro. The modules will be removed from the main UAV::Pilot distro in version 0.9.
At long last, UAV::Pilot v0.8 has been released. This is a big update with lots of API improvements. Most of those improvements were decoupling the code to support my own WumpusRover in addition to the Parrot AR.Drone. That means a big goal has been reached, where UAV::Pilot can support multiple types of automated vehicles. It also means UAV::Pilot is a major component of the code running on board a UAV, in addition to running the client side.
The WumpusRover is a project I’ve been working on for a while. It’s an old RC car I had laying around, retrofitted with a brushless motor controller, an Arduino, and a Raspberry Pi.
Update: Video of the WumpusRover will be up at http://youtu.be/yeDwb-6ASxw. Going to be leaving soon out of town, but wanted to make sure this gets up before I go out the door.
UAV::Pilot runs on the Raspberry Pi as a server, taking packets from the client and passing turning and throttle data to the Arduino. The reason for the split between Rapsberry Pi and Arduino is:
(The camera module is not yet implemented directly with Perl support. This is one of my upcoming projects, which will give the WumpusRover a video stream, among other things.)
As you can see, the two complement each other’s strengths. In the future, we might see cheap boards that can combine these two uses; the recently announced Arduino Tre looks promising.
I’ll be posting more detailed instructions later. If you’d like to get started on your own rover, you can start with the Arduino code here:
https://github.com/frezik/wumpus-rover
There are also some improvements to the older AR.Drone code. While making changes to the joystick API to support the WumpusRover, I found a case in the AR.Drone where its navdata sends a floating point -NaN. (More evidence that they shouldn’t have been using floating point for this purpose, and that the AR.Drone was badly implemented in general). UAV::Pilot was crashing in this case, but now handles it gracefully.
Also, the nav data will now be sent over ol’ fashioned unicast IP by default instead of multicast. This should make Mac users happy, as multicast isn’t setup out of the box on OSX.
State variables work something like C static vars. It’s a forgivable feature in C, because C doesn’t have lexical scoping.
Here’s an example of Perl’s state variables, taken from Learning Perl, 6th Ed.:
use 5.010;
sub running_sum
{
state $sum = 0;
state @numbers;
foreach my $number ( @_ ) {
push @numbers, $number;
$sum += $number;
}
say "The sum of (@numbers) is $sum";
}
running_sum( 5, 6 ); # "The sum of (5 6) is 11"
running_sum( 1..3 ); # "The sum of (5 6 1 2 3) is 17"
running_sum( 4 ); # "The sum of (5 6 1 2 3 4) is 21"
This could be implemented with lexical scoping like this:
use strict;
{
my $sum = 0;
my @numbers;
sub running_sum
{
foreach my $number ( @_ ) {
push @numbers, $number;
$sum += $number;
}
print "The sum of (@numbers) is $sum\n";
}
}
running_sum( 5, 6 ); # "The sum of (5 6) is 11"
running_sum( 1..3 ); # "The sum of (5 6 1 2 3) is 17"
running_sum( 4 ); # "The sum of (5 6 1 2 3 4) is 21"
Is this uglier? Yes, absolutely it is. That extra indent level is not pretty at all. So what’s the advantage?
With lexical variables, you learn a general feature that’s applicable to a wide range of situations. It is something you ought to know in order to program in anything like Modern Perl. State variables, on the other hand, are applicable to a specific case. While I’m sure someone who encounters them regularly would be able to intuitively reason about them, it’s not obvious to the rest of us without sitting down and working it out for a while.
(And if you’re in the position of being able to intuitively reason about complex functions involving state variables, I wonder about the Bus Factor of your code.)
So I got a new laptop (Asus K55N) with one of these newfangled UEFI BIOS-replacement thingys. Took me a few hours to figure out how to boot of the CD. When it’s all locked-down, you can’t hit ‘Del’ or ‘F2’ or anything to get into the BIOS config like the old days. Instead, with Windows 8:
I understand that BIOS was decrepit technology from before the 80286, but was this necessary?
In other rants, why did they (yet again) have to move all the config settings around in Windows 8? I’ve never wanted to remove an OS as fast as this one, and never been prevented from doing so in such a hostile way. Microsoft is fixing stuff that wasn’t broken.
Copyright © 2024 Timm Murray
CC BY-NC
Opinions expressed are solely my own and do not express the views or opinions of my employer.