Ok, I must admit that we havn't posted something for quite some time. We actually held our meetings and everything, but there was nothing of interest so far. But recently at Christmas time we had our special christmas meeting.
Lots of Perl mongers become busy at christmas time. Buying gifts and stuff, you know, the usual pre-Christmas stress. Other mongers are allready traveling throughout the country visiting relatives for christmas. Though not everyone is able to attend to the last meeting of the year. Our last meeting dates were late in December and therefore very close to Christmas eve.
Thats why it has become a habbit to give relatives and friends of our the ability to check what we "weird" guys are doing when we are out for the "Programmers-Meeting".
So we had some attendies at our meeting who are not into programming. Of course talking about Perl and stuff need to set back a bit that evening, we didn't want to scare non-programmers away with techno-babble. But on the other hand someone brought tiny chocolade Santa Clauses to the meeting. And it is quite interessenting getting to know the social surroundings of our fellow members. You know, we are not just programmers trying to help each other, we are also some kind of friends here.
Perl test output (the so-called "Test Anything Protocol" or "TAP") is simple: "1..N" declaring that N tests are planned, then either comments starting with "#", or lines starting with "ok X" or "not ok X" saying whether or not test number X succeeded. Generating it should be simple. Parsing it should be almost as simple.
However, the code to generate and parse test output is a byzantine nightmare: Test::Simple and its dependencies are at least 1345 SLOC, and the various TAP-parsing modules are at least 3918 SLOC (including an IteratorFactory!).
Both generating and parsing the subset of "TAP" used by most programs can take around 50 SLOC. This seems like a perfect opportunity for a ::Tiny module.
Every now and then, I can't remember the exact semantic of a function or module, and every now and then the documentation is not quite clearstraight about it. Then I gotta see the code running to make sure. Eventually my own personal memory stack will overflow and I will need to revisit some of this information. Here it's where:
Perl has so many useful builtins that most people who use the language probably only use a fraction of what's available. Every year or so I like to peruse perlfunc and perlsyn as a refresher. Yet in years and years of hacking Perl code, there are a few in there that I will never use. I surprised myself the other day by reaching for the loop control command redo. It occurred to me that while I use other loop controlling things like next and last constantly, I couldn't remember a single time before when I have ever had to redo an iteration. For the curious, here's the astonishingly simple scenario where it came up.
It's frustrating to me that I have limited bandwidth right now. A new job, a new country, a (soon to be) new baby, and a new blogging venture have all conspired to ensure that I don't have as much time for writing software outside of work. However, I've been working hard on Role::Basic and following a suggestion from Stevan Little, I've started [a branch with Moose::Role tests](
https://github.com/Ovid/Role-Basic/tree/moose_tests) and have started working through them. Some are clearly inapplicable (for example, Role::Basic has no notion of attributes), but a few have given me pause. I wasn't sure if they were supporting original traits behavior or if they were extensions for Moose. Since I've already ready the original traits paper (pdf) several times, I decided to move on to Traits: The Formal Model (pdf) to make sure I hadn't missed anything. There are some interesting bits there.
After half a day of yak-shaving that started with having to port yet another Makefile.PL to the dist.ini format, I am now finally able to post this small snippet of elisp code to blogs.perl.org from within emacs (more on that later):
I don't think this is documented anywhere, so let me blog about it before I forget it. Install the module CPANDB. See if it works by running one sample program, maybe:
use CPANDB;
use YAML::Syck;
print Dump [CPANDB::Distribution->select
("order by volatility desc limit 1")];
It may take a while but you will get something like this:
SslAuth uses the recently added TLS certificate authentication support in Mojolicious 1.01.
The first argument passed to the callback sub is the IO handle, giving you access to whatever IO::Socket::SSL provides. (get_cipher, for example).
ParamsAuth is very basic, its purpose being to keep your params-based authentication uniform with other auth-types.
The arguments passed to the callback are the values from the named form or query parameters.
BasicAuth has been around for a while, and uses a similar interface:
If you're looking to be hip with the latest oauth goodness, Marcus Ramberg recently released Mojolicious::Plugin::OAuth2.
...
On a side note, Вячеслав Тихановский (vti) updated MojoX::Validator only days ago. It is, to date, the only form validation helper that doesn't make me think Amway would have been a better career choice. It can be integrated into Mojolicious or used separately. And, like Mojolicious, the code is easy to understand and contribute to. Join up!
Once in a while I have something to tell about Perl and me. I used my very own server for years and sometimes I even used use.perl. Since the shutdown of the blogging interface at use.perl it seems that most bloggers moved to blogs.perl.
A friend, Ido (ik_5) put up a post (in Hebrew) about the last TA.pm meeting, and although he misspelled my moniker twice, he raises two interesting points.
First of all, he complains about being mocked when everyone introduced themselves and he said he works with Pascal. Secondly, he asks why don't people program in Pascal? What's so bad about it?
So, apologies have to go to people you've offended. Even if you didn't mean to, even if they didn't get a joke you thought you were sharing. When feelings are hurt, it's time to pause and apologize. So, hopefully Ido is reading this and might be less upset now.
Right now, if you get yourself a copy of CPAN (or check out a mirror) you won't find a lot of information about CPAN authors. You'll find name, email, PAUSEID and, in some cases, an URL. It's good, but it's not really comprehensive. It doesn't tell you how to find an author on Twitter, Github, Stackoverflow etc. Sure, you can find that stuff out with some research, but how hard should you really have to work for this information?
An important consequence of the choice of parsing algorithm
is the
handling of parse-time errors.
It's often overlooked.
Perl's use of LALR based parsing puts severe limits on its
ability to locate errors,
limits which the Perl interpreter is sometimes able to overcome.
Consider the following erroneous piece of code.
my $lyric =
'Sloopy wears a red dress, yeah
As old as the hills
but when sloopy wears that red dress, yeah
you know it gives me the chills
Sloopy when I see you walking,
walking down the street
I say don't worry sloopy, girl
You belong to me';
print "$lyric\n";
Some of you may have spotted this as the lost third verse of the
October 1965 US #1 hit, "Hang on Sloopy".
Others may notice that the single quote in "don't"
is going to make things come out pear-shaped.
On this latter point,
the Perl interpreter's performance is uncanny, if a bit noisy:
There have been a few bits of ARM related news which I thought were interesting. We like the ARM architecture (RISC is good) as it is low-powered and yet getting pretty powerful.
The alternative title for this post would be Best Holiday Ever where I got to show my family some of the parts of Indonesia I visited as a child, and where we got to visit a hotel in a national park in Borneo in which my family has a business interest. In case you think this is a shameless plug, the vast majority of the income generated by the hotel goes back to the local people -- the investors are facilitators, for whom there may be a long term return.
First of all: Finally accept that there are two Perls now. 5 and 6. Period. The world needs more Perl - here we have it. :) None of the two will go away. That's a good thing.
None of the following is new, but my suggestion would be to do it more in sync and at the same time and as a group to create a more event-style *cough* collective experience *cough* (think GSoC). It might also bring back people who have abadoned Perl but still keep an eye on the community. Considering how people sometimes talk about Perl on reddit or in Hackernews threads I bet some of them just need a little nudge to come back. (Many have never left in their heart.. *sniff* :)
Traditionally, the humanities journal has relied on Peer Review much like many academic disciplines. I believe firmly that Arxiv.org or something very much like it will replace the humanities journal in the near future, much like it has in the sciences. One of the main objections to this direction in the humanities is “what about peer review?” This is a major sticking point. The other is “will it count on the RAE/whatever management insanity we have to deal with at the moment?” I cannot answer the latter but I will give a vision of a solution for the former.
On my previous post, Ron Savage has commented on the way he uses File::ShareDir with Moose, to be able to use data files in the author's code directory.
While I probably won't use this method since File::ShareDir specifically has the ability to use @INC (which makes my - and kmx's - solution possible), it does raise a very important note. You must make your code testable.
Some of it is done by separating your code into smaller parts that are easily testable and can easily be overridden. Please refer to the Modern Perl Book, and the Modern Perl blog on learning more on this.
However, sometimes it's not enough. In that case, you'll need to assist your tests a bit, from your application code. Let me give you a small example.
On September 9, 2009, WebGUI 8 was announced. Since it was the
first major API change since WebGUI 7, we started planning WebGUI 8
with high expectations. Over the course of the last 16 months:
