At the pre-Saint Perl 6 dinner, we were talking about ideas for the hack day. I mentioned something David Farrell and I had talked about a couple of weeks ago.
I'd love to kick off CPAN testers from Github. Instead of uploading a dev version to PAUSE, I'd commit to some special branch, or create a special tag, or something, then get the same results I get now.
I have no idea how this would work or how the CPAN Testers would find out about the new releases. Maybe there's a central point that polls Github repos and acts as the central point for CPAN Testers to poll.
How it works depends on what the testers are willing to do and what's easiest to get going.
About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.
plstrace is a Perl script which can be used to trace your Perl program's execution. There are other"tracing"modulesalready available on CPAN, but I was inspired by the popular and immensely useful Unix utility strace, so the interface and output format of plstrace mimic that of strace.
Under the hood, though, things are different. plstrace currently can only trace user-defined subroutines and not Perl builtins. It is implemented by wrapping Perl subroutines with Perl subroutines during INIT phase. caller() has been adjusted so the wrapped subroutines does not see the trace wrappers (thanks to Hook::LexWrap). O/S system calls or external programs are not traced. And there are a few other technical limitations.
A new version of Dancer2 has been shipped yesterday and is already waiting for you at a mirror nearby!
It has come to our attention that some people don’t follow public announcements made on mailing lists so I will also be releasing a public announcement on this blog when I release a new Dancer2 version (except patch versions).
About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.
No, I'm not tempted to do a pun, despite the aptness of the situation :-)
File::Unsaved is yet another one of my little modules. Its one and only task is to check whether a file is "unsaved", that is, opened in an editor and has unsaved modifications. Currently it has support for several editors: Emacs and joe (on Unix; I haven't checked how it/they work(s) on Windows with regard to signalling unsaved files), and vim.
GraphViz2::Marpa parses DOT files and stores the result in a tree managed by Tree::DAG_Node.
It ships with a default rendering engine which simply re-creates the original DOT file, minus any comments, since comments are discarded by the grammar used to parse the file.
GraphViz2::Marpa ships with 101 standard tests and 269 author tests.
GraphViz2::Marpa::PathUtils (a subclass of GraphViz2::Marpa in a separate distro) processes that tree in 2 ways:
1: It finds clusters of nodes connected to each other but not connected to other clusters, and splits each cluster out into a separate DOT file, maintaining the original DOT file structure. This means node and edge class declarations ensure the look-and-feel of the nodes and edges in these separate files is identical to what it was in the original file.
2: It finds all fixed-length paths starting from a given node.
GraphViz2::Marpa::PathUtils ships with 6 standard tests and 3 author tests.
Dave Cross posted his Perl Recruitment Thoughts, which led to the same tired responses we see every time someone is frustrated enough to bring it up. Again. In the past decade I've written this post about every six months, decided it wasn't worth the shitstorm I'd get for posting it, and let it die. This time, I'll write just the highlights, turn off comments, and let people who care enough rant do it on their own blogs.
First, Dave does quite a bit of work to make new Perl programmers. He teaches accessible and cheap classes in London (and anywhere that will have him). I don't work in UK, so I can't speak to the particular things he sees. I teach all over the US, write the books, and occasionally step into companies to un-screw up whatever they have going on. Here's what I've learned in 20 years of doing this, but, as I said, just the highlights.
About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.
Proc::Find is little module that can help you write this shell idiom in Perl and avoid shelling out:
# check a process by name
ps ax | grep -q mplayer
if [[ $? == 0 ]]; then echo "mplayer process exists"; fi
pgrep mplayer
if [[ $? == 0 ]]; then echo "mplayer process exists"; fi
In Perl:
use Proc::Find qw(proc_exists);
say "mplayer process exists" if proc_exists(name=>'mplayer');
Proc::Find can find/list processes by other criteria other than name: pid, full commandline match, program's binary path, user/UID (other criteria can be added in the future). For example:
use Proc::Find qw(find_proc);
my $pids = find_proc(user => 'ujang'); # find all process owned by ujang
As always, if I make a post about business in general rather than about Perl in particular, I do it on my Other Blog. As I have done this week. Check it out, if you’re interested.
The SQL language is quite big, and consist of approximately ~2500 production rules, and almost as many terminal tokens.
Thanks to Ron's SQL page, the EBNF describing SQL was translated to Marpa::R2's Scanless BNF.
The most interesting things behind this exercice were:
Dealing with known (and native!) SQL grammar ambiguities
Do some semantic actions in the case when the parsing of a terminal depend on a terminal that is after
Provide something useful on the command-line
A note as prolog, one has to eliminate some usual pitfalls with SQL-2003. For instance, it requires a
FROM
after the
SELECT
, column names as well their eventual
AS
alias are
not
single-quoted, and so on.
About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.
I've created a couple of frameworks that make it easy for Perl developers to add tab completion feature to their scripts (and am planning to write another one). One is Perinci::CmdLine, which I recommend and use a lot more myself but requires you to immerse yourself with the concepts Rinci metadata, Riap URLs, and all that. Another is Getopt::Long::Complete which is more suitable to casual Perl programmers familiar with de-facto and builtin module for options parsing in Perl, Getopt::Long. Getopt::Long::Complete allows you to use Getopt::Long interface; you just need to add a subroutine to tell how to complete option values and arguments.
I offered to help Tim Bunce maintain Memcached::libmemcached earlier this year and managed to get a single release out with a few fixes.
I intended a second release to solve some compilation issues, but never got around it, and I'm not sure I ever will - there's still more work to do to there, and my time/interests have moved on.
I'm looking for someone to take over maintainership of this. Bug reports have been fairly minimal so far, most of it coming down to "Please update to latest upstream version" or "allow to link against system version instead of bundled version."
See https://github.com/timbunce/Memcached-libmemcached/issues for more about the above.
If this sounds of interest to you, please let me or Tim know - we'd love to have someone keep this going.
About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.
Some of you might already know that there are some wordlists on CPAN, under the Games::Word::Wordlist:: namespace. These lists can be used for, as the package name suggests, word games like Hangman or Word Search or Scrabble, but can also be used for other purposes, among others: cracking/bruteforce dictionary, password generation, feeding into search engine, or some linguistics tasks like word length/frequency analysis.
The wordlist CLI utility (from App-wordlist distribution) is a small script which I recently wrote to query the contents of the abovementioned modules.
You may recall that my mentioning that my favorite talk at this year’s YAPC was Sawyer X’s “The Joy in What We Do”. If you remember (or click one of these links I keep throwing at you), long about 26:28 Sawyer X makes a radical suggestion: if you want to release an application which uses Perl, maybe you shouldn’t be releasing it via CPAN. I mean, CPAN is awesome for modules, and it’s not too shoddy for Perl apps either. It makes it very easy to install for people who already have Perl, and know how to operate the CPAN shell, or cpanm, and either have root access on their machine or are already using perlbrew or plenv, and ... In other words, other Perl programmers. And, if that’s your audience, then lovely. Although, even then ... what if you need a particular version of Perl, and particular versions of certain modules? It’s all doable, certainly, and even moderately easy for Perl’ers of a certain experience level. But why should we limit ourselves unnecessarily?
During the patch -p2 hackathon, two seasoned Perl programmers told me that
"you can't requires attributes". This sounded weird to me, as attributes are exposed as methods and besides, I'm doing that all the time in my current work project.
