Marpa::R2's
Scanless interface
is not yet two weeks old,
but already there are completed applications.
Significantly, two of them are for work.
A JSON Parser
The non-work-related application is
a JSON parser.
Given what it does,
it easily could have been work-related.
(It's been available for a few days as a gist,
so it may well be in production use somewhere.)
It was written by Peter Stuifzand,
runs 185 lines
and took him less than 30 minutes to write.
Peter reports that it was a matter of
typing in the grammar,
and adding a few Perl functions to provide the semantics.
There are, of course, other JSON parsers out there,
many of which run faster.
These, however, took weeks to write.
If you are, for example,
thinking of
extending JSON,
and development time is a major consideration,
the Marpa-based solution will be attractive.
Quite a few updates for this month's summary. New CPAN distributions, plenty of fixes, some updates, lots of discussion ... and 27 over million reports!
I've used cPanel/WHM for a very long time as a personal server manager, and up until recently it's served my purposes pretty well.
However since getting into the Mojolicious framework and a few other Perl modules that require a Perl version greater than the 5.8 that cPanel is currently tied into, it's become a bit of a nightmare trying to run any Modern Perl apps on it.
While there is some Mojolicious documentation around running an app on Apache, I thought I'd document the exact steps I took to get a non-lite app up & running on my Hostgator server (although I'm sure it would work equally well for Dreamhost etc or other shared hosting solutions):
I am not exactly sure if the difference is between Strawberry Perl and Active Perl, but it looks like it is there and I am stuck like the test of the module.
Version 0.03 of AnyEvent::ForkManager has another minor issue, you need to already have Test::Requires, which is then not used, but once you install that module, here is the main point:
While it would be nice if the test were passing, I think it would be also important to understand why are the tests stuck in some of the cases. Is that really some difference between Strawberry Perl and Active Perl?
ps. No, I don't really need this module, but I was smoking CPAN on Strawberry Perl and Christian Walde (Mithaldu) thinks I am just complaining and not doing anything about it.
During the last leg of my new year's vacation, I started hacking on ZMQ::LibZMQ3 et al again, due to gentle prodding from @melo to include zmq_proxy().
What seemed like a simple API addition in the end turned into myself writing a autoconf like "compile, see if it works, and check if a particular API exists" type of too (is there a CPAN build tool change component that does this kind of stuff?). I'm satisfied by the fact that it actually works, but I must say the Makefile.PL for ZMQ::LibZMQ3 is starting to get pretty darn wacky.
I’m putting this here mostly as future copy-paste fodder:
my %sql_type = do {
my $ti = $dbh->type_info_all;
my $tidx = shift @$ti;
my ( $n, $t ) = @$tidx{qw( TYPE_NAME SQL_DATATYPE )};
map {; uc $_->[$n], $_->[$t] } @$ti;
};
Now you can say things like $dbh->quote( $latitude, $sql_type{'DOUBLE'} ). This is useful in situations where you cannot use placeholders, e.g. when generating some kind of fixture.sql file from CSV data.
Yesterday I have discussed my setup with mst, jnap and joel on irc.perl.org #catalyst
Here is the gist of what mst had to say.
15:50 <@mst> you're using unix sockets
15:50 <@mst> ergo there's no gain to using starman over fastcgi, you're just using a less efficient protocol
15:51 <@mst> the modern ways are starman via http TCP proxy, and fastcgi via unix socket
15:51 <@mst> you're currently using starman to emulate myapp_fastcgi.pl
15:51 <@mst> and I can't see the point
The point of this post is to solicit feedback: If you're interested in these modules, or are worried about the changes, comment below, or email me directly.
Hopefully, however, no-one is using the module, so exactly the same number of people will be affected...
Some details:
Internal changes include:
o Switch from CGI::Application to CGI::Snapp
o Switch from CGI::Session to Data::Session
o Switch from Log::Dispatch to Log::Handler
o Switch from YUI to jQuery
o Restructure the class hierarchy
o For MySQL users, adopt engine=innodb
o Additions to the people table: facebook_id and twitter_id
o Old fields in the people table now ignored: broadcasts, communication_types
External changes:
o The appearance of each input form will be a bit different, mainly due to adopting jQuery
Future changes:
o I am aware the lack of sites/addresses (per org, per person) is a deficiency. That will be rectified shortly.
The companion modules App::Office::Contacts::Donations and App::Office::Contacts::Import::vCards will of course change to match.
Having some free time during the Christmas break, I decided to give a shot at a small project that I had in mind for a while, and that was to develop a PSGI-compliant(-ish) web server with support for the SPDY protocol.
In case you haven’t heard of it, SPDY is a networking protocol developed at Google with a goal of reducing web page load latency. It is currently used by some of Google services (including search and Gmail) and by Twitter, and is supported natively in Firefox, Chrome, and Opera — so if you visited any of those sites with any of those browsers, it’s highly likely that your web content was transmitted by means of SPDY. An official standard for the protocol is in the works.
In a previous post, I described a method of writing
powerful domain-specific languages (DSLs),
one that was simpler and faster
than previous approaches.
This post takes things significantly further.
The approach described in the previous post was not itself directly
DSL-based,
and it required the programmer to write a separate lexer.
This post uses
Marpa::R2's
new Scanless interface.
The Scanless interface
is a DSL for writing DSL's
and it incorporates the specification of the lexer into
the language description.
When it comes to dealing with a programming problem,
no tool is as powerful and flexible as
a custom language targeted to the problem domain.
But writing a domain specific language (DSL) is among the
least used approaches,
and for what has been a very good reason --
in the past,
DSL's have been very difficult to write.
This post takes a tutorial approach.
It does
not
assume knowledge of the previous tutorials
on this blog.
Going over the previous count-ups to 100 CPAN distributions in this
blog, I feel I have been carried away: I tried to release a lot
of new distributions to the CPAN, while neglecting all the existing
distributions I have, and not tending to their pending problems and their
lack of software quality in several aspects (See
an
older essay I have written about it).
I was reminded of it when
working on a few new or existing distributions using
Dist-Zilla. I ran into a few places where some
of its plugins or features were underdocumented, and non-exemplified (in
the SYNOPSIS sections or wherever), which consumed many hours of my time,
sometimes made me need to read or grep the code, and made me frustrated. While
I sent the maintainers some pull requests for better documenting this (and
some of them were applied), I would have prefered for them to be
properly documented and exemplified in the first place.
In the last couple of days we fixed some bugs and added new features to Perlybook:
* You can now send .mobi files to any mail address you want, it's also possible to store the mail address in a cookie...
* We now use the MailException plugin for Mojolicious so we get noticed whenever something goes wrong
* Fixed some decode bugs
When I added mail support, I experienced some problems that didn't occur on my dev machine.
After two hours of debugging I found the difference. On the server I did install Authen::SASL::XS and on my dev machine this module is missing.
Myself and the other author of Hailo just got what looks to be very odd spam asking us whether someone could buy a copy of Hailo.
Here's an E-Mail that was sent to Hinrik:
I want to buy a Marklov pluggable engine, Where can i buy one, i am coming to
Iceland for a visit, can i come to your shop?
And, in another E-Mail sent to me:
Hi,
I would like to buy a Hailo. Where can i get one and how much do they cost?
Thanks Julie
Clearly I should quit my dayjob and start selling copies of Hailo on CD in a dedicated store just for this purpose.
More seriously though, is anyone else getting similar spam these days about their CPAN distros? It seems odd to get a couple of these E-Mails within a few days.
We did have someone contact us a couple of years ago legitimately wanting to buy a license for of Hailo. It took quite a long E-Mail exchange to convince that person that yes, we were in fact giving it away for free.
If you were to read the TAP grammar, you would see the following line:
test ::= status positiveInteger? description? directive?
What that means is that a test line of TAP (if you read the rest of the grammar) must have an "ok" or "not ok" bit, followed by an optional test number (in practice, it's almost always there) and a test description (the directive refers to "skip" or "todo" tests). Sadly, many people don't pay attention to the powerful benefits of the description. A bad description may as well be left off; a good description is the difference between a pile of confusing code and documentation.
My first go at this was with Dr Forr, my long time Perl mentor and friend. While working together we convinced the boss, his brother, to open up our office as a lab for a series of open to the public classes, more or using the same format and overarching plan I've jotted down for this proposed go.
Generally, our focus was Unix and Perl, especially - though not exclusively- for people completely new to programming. Or completely new to computers - it was the '90s. That was a real thing.
Since then, I've resurrected the gist in several forms, to create one-week boot camps for colleagues, for a semester or two with the Minneapolis Community Education program, and so on. Pretty much whenever I can put time, interest and a couple of dozen terminals into the same space I can be counted on to dust off some old example projects for inspiration and dash off a new syllabus.
I often have need to communicate with ISC's BIND programattically and I haven't found any libraries out there to do that.
Often, what you'll see is a wrapper around BIND's rndc utility that forks, execs, passes it arguments, and then parses the output.
This is okay if you're on a box that can fork and has rndc installed, but that's not a safe assumption.
So I spent some time digging through BIND source and deconstructing the RNDC protocol (which was actually quite fun) and came up with
Net::RNDC
:
use Net::RNDC;
my $rndc = Net::RNDC->new(
host => '127.0.0.1',
port => 953, # Defaults to 953
key => 'abcd',
);
if (!$rndc->do('status')) {
die "RNDC failed: " . $rndc->error;
}
print $rndc->response;
The base Net::RNDC interface is synchronous, but you can use Net::RNDC::Session asynchronously, or just use Net::RNDC::Packet itself to generate/parse RNDC packets.
The packet interface isn't yet well defined (just read/write entries in a hashref), but I hope to improve on that soon.
Enjoy,
-- Matthew Horsfall (alh)
PS: Thanks to my employer Dyn for allowing us 2 days a month to hack on projects that we want!
As usual TPF just published another call for grant proposals, ranging from $500 to $2000. The official call for proposals is available here: http://news.perlfoundation.org/2013/01/2013q1-call-for-grant-proposal.html
