| Subcribe via RSS

Atom Editor Invites

March 20th, 2014 | No Comments | Posted in GitHub, Software

I have two invites for the beta of the Atom editor under development by GitHub. I haven’t played with it enough yet to know whether it is spiffy, or if so how spiffy it indeed is.

Two things to know if you are interested in trying it out:

  • It currently is only available for MacOS. Appears to be compatible with Mountain Lion and Mavericks only, as well.
  • You will have to register via your GitHub account, assuming you have one. Then again, if you are considering test-driving an editor like this then you probably have a GH account…

If you are interested, email me at my primary address (rjray <at> blackperl.com). I will send invites to the first two respondents, using the email address you email from. Do not comment on this post for an invite, as the email notification goes to a different account that I do not check as often.

Tags: ,

Some Modules I’m Looking At Currently

March 16th, 2014 | 1 Comment | Posted in CPAN, Perl

Now that I’m writing (a little) more reliably in this blog, I hope to soon revive my “Module Monday” series. At the time I started doing it, it was fairly easy to come up with new modules to review, as I was the owner/operator of a CPAN-oriented Twitter-bot called “@cpan_linked“. But then Twitter switched over to OAuth-only and I haven’t had the time and energy at the same time, in order to update the bot.

But I still frequently look at new and interesting modules, always looking for new tools with which to fill my Perl toolbox. Here are some that I am currently reading up on and/or playing with:

CPAN::Changes

I learned of this module from this blog post, and am both intrigued and frustrated. Intrigued, because I’ve always felt that changes-files needed to be electronically parseable so that the information could be re-purposed to other uses and formats. But also frustrated, because I wrote something similar to this a while back (App::Changelog2x, which is based on an XML format I designed), which as far as I can tell only I have ever used.

Mind you, I’ve known that ChangeLogML has drawbacks from the very start– for one thing, authoring in XML is a HUGE pain in the ass. I’ve only just recently gotten my emacs set-up to handle ChangeLogML very well, and for that I had to first convert the XML Schema to RelaxNG, then that to the compact format, then hand-edit the resulting RNC file to get around things that hadn’t converted correctly (though one or two of them may have been problems in the original XML Schema, to be fair). Even still, with all that, I’m still editing raw XML. I just have syntax highlighting and validation to help me find errors. And a lot of people just don’t like dealing with XML, let alone editing it by hand.

ChangeLogML keeps more information than the CPAN::Changes::Spec specification does, but mine doesn’t have the concept of groupings, something I may look at trying to add if I ever revisit ChangeLogML and try to make it more useable.

One thing I’ll look at either way, is transforming ChangeLogML to a conforming “Changes” file for my modules. That should be a lot easier than convincing people to hand-edit XML on a regular basis.

Regexp::Debugger

Being easily distracted and fascinated by blinking lights and colors, this tool just amuses me greatly. That is is also incredibly useful is a great bonus.

It’s a module from Damian Conway, and I learned about it recently when he included it in a talk he gave to the London Perl Mongers group. I couldn’t go (the commute from California to London being prohibitive and all), but Damian was helpful in posting a follow-up message to the mailing list with a list of the modules he had discussed. I had already taken some interest based on the “Regexp” in the name, as I’m not the best wielder of regular expressions in the Perl world, so I often need debugger-ish tools to fall back on. But just to make it even better, in response to a comment by someone else, Damian followed up his list of modules with a YouTube link to a demonstration of the module.

Watch the video, and I’m sure you’ll be as interested in this module as I am. Note that this dates to 2012, and there have been several releases and new features since then.

Test::Trap and Test::Effects

I’m grouping these together as one provides a foundation that the second one builds upon.

Test::Trap, by Eirik Berg Hanssen, is an interesting approach to testing code in terms of blocks. You pass “trap” the block to execute, and it handles the eval mechanics for you, with the results and any error information wrapped in an object (called “$trap” by default). There’s a great deal of flexibility and configurability here, as well.

Test::Effects is another module from Damian, one that builds on Test::Trap with an interface that lets you test all the effects of your code-block in one go. Where the former module would have you pass the block to trap, then choose what to test against using $trap, this module gives you a testing routine called “effects_ok” that looks at everything, or alternately just those things you want looked at. It is also extremely configurable, including some options that may make my long-neglected Test::Without module obsolete.

Mojolicious

Lastly (for this listing, at least), is the well-known Mojolicious package. I’m kind of late to the game on this one, as it has been around quite a while. A co-worker of mine has used it some, and convinced me to give it a look for some web-services applications I’ve been tinkering with. What interests me the most about it is the built-in support for WebSockets, something Apache doesn’t have (and doesn’t seem to be planning for any time soon). I’m currently looking at how easily I can use it in different styles of event-loop processing, as the main place I’d like to use it would be an application that has to manage both an HTTP event-loop and a separate client/server socket simultaneously. (At this point, I don’t yet know how the other socket works, or if it will play well with others. So Mojo might end up not being the deciding factor in that after all.)

So, there are five new modules that I’m currently focused on, any of which might end up getting their own post some day. Here’s hoping that one or two might be of interest to other readers.

Tags: ,

Understanding Encoding (Trying To, At Least)

March 3rd, 2014 | 2 Comments | Posted in Perl, XML

Earlier this evening was a presentation at the San Francisco PM group, on “Unicode & Everything”. I wanted to go, but had a conflict so I had to miss it.

Character encoding is an area I’m weak in, and one that I need to be better at. My biggest module, RPC::XML, supposedly supports encodings other than us-ascii but in truth it’s pretty broken. I recently applied a patch that fixes the handling of UTF-8 content, but that’s not what I need. What I need is for it to properly handle content in (theoretically) any encoding. I don’t think that a talk focused on Unicode would have covered that, but I was hoping that I might be able to corner the speaker afterwards to bounce some questions off of him.

What it comes down to, is this: my library creates requests and responses in well-formed XML, complete with an encoding attribute in the declaration line:

<?xml version="1.0" encoding="us-ascii"?>
<methodCall>
    <methodName>someName</methodName>
    <params>
        <param>
            <value><string>Some string data</string></value>
        </param>
        <param>
            <value><int>42</int></value>
        </param>
    </params>
</methodCall>

What matters here is not the structure of XML (in this case)– it’s the encoding="us-ascii" part, and this line:

<value><string>Some string data</string></value>

See, my library generates the XML around the “Some string data“, but the string data itself comes from whatever the user provides, and the user expects that to be in the encoding he or she specified. And here is where I start to get confused: I know that the boilerplate code is US-ASCII (in the range that makes it passable as UTF-8), but I suspect that I can’t just paste in a string encoded in ShiftJIS and slap on encoding="shiftjis" in the XML declaration. Or can I?

XML-RPC has a very limited vocabulary and set of data-types. The character range, funny-encoded-strings notwithstanding, is just basic ASCII. You have the tags, then strings, integers, doubles, date/time values (ISO8601) and base-64 data. Regardless of encoding, all of these except the strings stay in the ASCII range.

So for those reading this that are more adept as working with encodings than I, how to approach this? Is the magic sauce somewhere in Perl’s Encode module? I really want to get this part of the RPC::XML module working right, so I can move on to the next big hassle, data compression…

(I also need to figure out why my code-highlighting plugin isn’t doing its job…)

(I think I got it now. Something was missing from one of the theme files. Gotta love WordPress/PHP…)

Tags: , ,