MozRepl

One of the recurring problems I have with Mozilla products is that they are essentially unscriptable using technology I know how to use. XPCOM has no Perl support (apparently it started to, at one time, but that module seems to have been dropped along the way), and the only real recourse appears to be embedding of JavaScript through mechanisms I don't really have the time to understand.

Well - no more. I learned of the existence of MozRepl, which is a plugin that provides a local telnet command line that can be used to inject JS into running Mozilla-based applications (Firefox and Thunderbird being the ones I actually care about). And MozRepl does have a Perl module to talk to it.

So that's another option I have for automating my work. I'm not 100% sure yet how best to use it, but at least I know it's there.

docopt

At docopt.org - a specification language for command-line interfaces. Shades of ... that groovy Perl module I can't remember the name of. Right - Getopt::Euclid! I used it for the Marpa tester. Shades of that! Except a general specification language. I think I'll steal this idea eventually.

And speaking of cool C things

Here's a package that brings Lisp macro syntax to C. Do want! (Run C::Blocks through that!)

HabitRPG to gamify your life

Cute concept!

Everything is broken

Good post on security at Medium.

NLP with Prolog

A book!  Online! Suitable for working through.

C::Blocks and Devel::Declare

There are a couple of different ways to hook into the Perl parser and define a keyword that flags your own funky syntax - neither of which I'd heard of until encountering the absolute genius that is C::Blocks.

C::Blocks embeds C code right into your Perl, using a cblock { this is C here } syntax that is just incredibly groovy. It's way more inline than Inline. OK, so it's not production-ready yet, but still - it will be. And I'm going to do that same thing for HBScheme.

So anyway, C::Blocks uses the shiny new pluggable keyword API to do that (introduced in 5.12) - but Devel::Declare lets you do pretty much the same thing, but less elegantly and safely. The difference appears to be that the pluggable keyword is available from XS and expects you to return opcodes (that is, it's a real live hook into the interpreter) while Devel::Declare runs in Perl and returns strings that will then be interpreted by the Perl interpreter. I might be wrong about that, but I haven't really gotten into it yet.

Yet.

Article: Perl and Windows UAC

New article written on the Vivtek site, a little in-depth investigation of Windows UAC and how to manipulate it from Perl, along with the release of a CPAN module.

Marpa stuff

As I get further into Marpa, I'm starting to see there's a whole little world of cool stuff out there based on it. Here are a couple of bookmarks for later.

• A fantastic article on using Marpa to convert Excel spreadsheet formulas into Perl using AST transformations.
• Kegler's "Ruby slippers" parsing technique: essentially ways to trick a simple grammar into functioning within a larger whole by using invisible tokens and wishing the language were easier to parse. Marpa is ... well, it's beyond cool and into virgin territory.
• Another Kegler post on mixing declarative and procedural parsing that should come in handy here and there.
• Here's a gist showing a Marpa parser for CSS that uses a tokenizer external to Marpa - the key technique is in the loop starting on line 187, where we pass each individual token to the recognizer. Only after the token stream is complete do we read the value from the recognizer. (So for a series of sentences, do we have to create a new recognizer for each sentence? I think we actually do. That will be something for experimentation later.)

Using a spreadsheet as data for templating

The Python copytext module takes a spreadsheet and loads it as a data structure for expression in a template; that's kind of a neat ... I'm trying to think of the phrase I want to use ... "dataflow component" seems to be as close as I can come tonight.

Anyway, this is kind of a neat idea and is probably a way forward for the Data::Table::Lazy module. Note also that D::T::L should directly know how to work with Excel and with Google spreadsheets for maximum fun and profit.

CS from the bottom up

This looks like it might be fun to work through.

FreeLing

Another NLP package I'd never heard of. I gotta take another sabbatical week soon and get all this NLP stuff under control. Anyway, I found this one on a more-or-less random sweep through CPAN - I forget what I was searching on, but ran across Lingua::FreeLing2::Bindings. Perl bindings make me happy, so I think I'm going to poke around here as soon as possible.

GNU Cobol

Coool!

Irssi

So Irssi is a text-based IRC client that I believe I love already. I only hit IRC about every five years or so; maybe this time will be the time I stick there. It's very popular for software development groups.

Anyway, Irssi seems to embed some kind of Perl automation. I'm going to figure it out eventually.

Marpa

So I decided to sit down finally and write the line parser for the new Decl, and since it was parsing, I decided not to unearth my old HOP-inspired parsing code but rather take the plunge and try Marpa, to avoid getting bogged down in parser issues.

I am in love.

It basically looks like Marpa can do anything related to parsing. It can even handle ambiguous parses! One of the test cases is literally "time flies like an arrow"!

But what doesn't yet exist (there's a partial beginning) is a tutorial set, a "Gentle Guide to Marpa". I think I'll write one.

Code challenges

A nice article recommending the solution of code challenges against an autojudge to improve programming skill.

Decl and top-heaviness

Man, reading through all the stuff the v0.11 Decl::Node object supports, it's really no wonder I bogged down. It was just doing too much. I really hope that splitting things out into syntactic and semantic poles will make a difference.  (Or really, even more than just the two, given the declarative extraction phase in the middle.)

So yeah, I suppose a post on that is in order.  The new regime is finally getting underway, given that the last update to Decl was in 2011 and it's 2014 now.  I've started coding Decl::Syntax, which is the handling of syntactic nodes.

Note that a syntactic node is used to derive two different sets of semantics. The first is the machine semantics, the second being the human semantics. This is equivalent to the concept of literate programming, except that literate programming also parses the code chunks for indexing, which (initially, and maybe permanently) we will not be doing.

So the surface structure is the indented stuff. To derive the machine semantics, we go through two more phases.  Actually, three.

The first is markup. During markup, a Markdown ruleset is used to convert all Markdown nodes into X-expressions. The ruleset can be specified in the input, or can be one of a few named ones.

After markup comes declarative extraction. Here, we extract a tree of declarative nodes from the syntactic structure. These contain only the "true children" of each tag. X-expressions are converted to tag structures during this phase, and transclusions are resolved. Annotations are inserted into structured parameter values.  Macros might be expressed, I won't know this until I try expressing some things with prototypes.

The result of declarative extraction is a thinner tag structure that contains only machine-meaningful information. Anything explanatory is discarded, although obviously it's still available for examination if there's a need.

After extraction comes semantic mapping. Here, a set of vocabularies map declarative structure onto data structures. A default vocabulary might just map everything into vanilla Perl structures or objects, but more interesting vocabularies will build more interesting objects.

Finally, execution does whatever action is encoded by the semantic structure. This runs code, builds documents, activates the GUI, or whatever.

Keeping these phases strictly separate makes it possible to build all that detailed functionality into this system without losing sight of what's where. Or so I fervently hope.

Reactive programming again

Two little JS frameworks: ripple.js, which aims to be tiny, and "React.js and Bacon", a look at another way to do reactive stuff.

Article: KeePass through SSL with Perl

New article at the Vivtek site on accessing KeePass using the KeePass plugin from Perl. I ran through progressively more elegant prototypes before coming up with a nice wrapper. I released the whole shebang as a CPAN module WWW::KeePassRest, which uses a new JSON API wrapper that is ... minimalistic in its design.

It'd be nice to be nice and principled about API wrappers on something like this basis, but that's definitely way down the priority list.

Code reading (and by extension, code presentation)

Here's an article by Peter Seibel I missed in January: Code is not Literature. Instead of reading code like literature seminars, we should rather consider presentation of code more like what naturalists do: "Look at the antenna on this monster! They look incredibly ungainly but the male of the species can use these to kill small frogs in whose carcass the females lay their eggs."

This really resonates with me, as it's more or less what I've got in mind with exegesis: a list of articles focusing on sections of the code, highlighting interesting techniques and extracting the knowledge embedded in it (and as the technology matures, also extracting some of that knowledge in a reusable form of some kind).

James Hague then weighs in today with "You don't read code, you explore it," saying essentially the same thing, and adding that only by interacting with the code does he feel as though he achieves true understanding (and mentioning Ken Iverson's interactive J presentations, which sound pretty interesting as well).

So there you go. What people are thinking about writing about code.

As practice, I've written two articles on vivtek.com in the past week and am well into a third: one on TRADOS 2007 and its language codes, so far presenting only a prototype script, a list of the codes used in a convenient format, and explaining a little about discoveries I made on the way; and one on Windows UAC and how to use it from Perl, which I backed up by publishing the module Win32::RunAsAdmin to CPAN.

If I can keep up something like this pace, I'll have fifty articles in a year. That's a lot of writing - and honestly, I have a lot of things to write about. I just wish there were more examples of writing about code for me to emulate. I'm still looking for source material.