Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of LTjake (4001)

Wednesday April 22, 2009
01:38 PM

Projects Updates and QA Tools

NB: This is my first post in the EPO Iron Man challenge. (Warning: contains some expletives)

First and foremost, the long awaited Catalyst 5.8 is out! My mind-share has primarily been with the 5.7x series so I've been pretty much out of the loop on everything that's going on. Luckily enough, everything is basically backwards compatible (less any necessary module upgrades).

Besides the usual round of bug fixes, this release is built on top of Moose. I'm a big fan of Moose and the ease with which it lets me code, so I'm very excited to see this feature. Be sure to check the Changelog for all of the details.

As far as my personal projects go, I've finally been able to deprecate two of my oldest modules (Image::ANSI and Image::XBin) with the latest release of Image::TextMode. This release now mirrors all features provided by the two before it (and then some). It can now write each format (not 100% complete, but release-worthy) -- I've even included a little bit of naive RLE compression.

Personal projects let me explore some new/different technologies which may not fit in do my daily $work. One of those would be Moose, as mentioned above (which is now part of our standard "toolkit"). Another would be XS. Writing Image::TextMode::Reader::ANSI::XS was very eye opening as far as hooking Perl and C code together and illuminating the Perl internals for me.

Recently, I've been in tune with adding new QA tools to my repertoire, such as: Benchmark (high time I learned more about it), Perl::Critic (again, about time) and Devel::NYTProf.

If I'm going to keep up with this "Iron Man Challenge," then maybe I will save my favorite QA tools for their own post. Stay tuned!

Tuesday March 24, 2009
09:50 AM

github

Like so many before me, I have now joined the github cabal.

Check out my projects.

One of the more interesting parts of github is their breakdown of projects by language. At the time of this post, Perl has 6% of the projects -- tied with C, 1% more than PHP, 3% less than Python and most surprisingly 1% less than "Shell".

Obviously, given the origin of github, Ruby is way in the lead with 30%. But, I have a feeling that as people get more savvy about SCM tools, especially distributed SCM tools, Perl will make a significant dent in that.

Monday January 19, 2009
04:06 PM

Catalyst 5.71000

Like i said back in July, Catalyst 5.71000 would happen before the moose-ified 5.80 gets shipped. That day is here. Here's the basics on what's new since 5.7015:

  • Relatively chained actions   
  • PathPrefix (I only mentioned that, oh, 2 years ago :)   
  • $c->go and $c->visit (they do a full dispatch to the action; this should kill the SubRequest plugin)   
  • Refactored component resolution (which is something else I worked on)   
  • Documentation improvements   
  • Misc bug fixes

There's a full changelog available. You might also browse the search.cpan diff from 5.7015 to 5.7100.

Enjoy!

Thursday January 08, 2009
03:57 PM

Series of articles featuring WebService::Solr

I've had a number of people show interest in WebService::Solr since its release last fall. This is really encouraging.

Especially encouraging is seeing Eric Lease Morgan's first article in a series of three dealing with indexing and searching using WebService::Solr. The initial post deals with some basic definitions, setting up Solr and writing a basic set of indexing and searching scripts.

It'll be great to see how the module gets used in a truly practical way.

Wednesday January 07, 2009
02:55 PM

Joining the Debian Perl group

At $work, we have a number of Ubuntu servers, and all of the developers use Ubuntu for their desktop OS. This has been the case since the 6.04 release of Ubuntu.

I'm the first to admit that I'm not much of a sysadmin. The general advice for installing modules, as I've read, was to install the version from the apt repository when available. No problem there. Other than that, I've always just used the cpan shell to install what I was missing. Apparently, over time, mixing the two methods tends to break down.

Last summer, i finally broke down and got familiar with dh-make-perl. It made creating .deb files for modules criminally easy. I also took this one step further and setup a reprepro-based deb repository on an internal server so all of our machines could benefit from the .deb files I had created.

In the spirit of giving back, I began to wonder how I could help out upstream by injecting some of these missing packages. It turns out that Ubuntu synchronizes its packages from the Debian unstable repository on occasion. So, how does one get things into the debian repository?

Enter the Debian Perl group.

To sum up their announcement, they basically handle all perl module related packaging tasks for Debian. After finding them on IRC and applying to the group I was quickly accepted and thrown into the fray.

I decided that it would be best to install Debian in a VM and do my packaging there instead of trying to hack around Ubuntu-specific issues. The Debian Perl site has a number of good guides to get you moving. I'll try to summarize the basics.

For new packages, one must first create an ITP or Intent To Package report. This comes across the line as a bug report filed against the "wnpp" pseudo-package. The reportbug tool makes this a trivial task.

The group uses an svn repository to keep track of all of their work, so the next step is to inject your initial work into that repository. svn-inject will take care of this for you, as long as you have the .orig.tar.gz, .diff and .dsc files. To get those files, I did the following:

  • use dh-make-perl to intialize the package: dh-make-perl --cpan Foo-Bar --pkg-perl 
  • cd Foo-Bar   
  • use debuild -S to create the source package   
  • finalize the process with the svn-inject helper

Once you've injected the new module, you'll need to massage all of the debian/* files to get them up to spec -- in which there are many nuances that I'm still trying to figure out. The folks on the IRC channel are very knowledgeable and have helped me numerous times there.

If you think your package is ready to go into the repository you can change the release status from UNRELEASED to unstable ("dch -r" helps here) and someone will review it. Hanging out in the IRC channel can speed things along. If all is well, they will take care of the rest from there.

To update an existing package:

  • check out the existing package from svn   
  • use uscan to get the new tarball   
  • use svn-upgrade to inject the new data into the repository

Again you have to massage the debian/ files based on the new tarball data and the same review process applies.

As things are uploaded, you'll get a fancy developer page, like this. Also, the Debian Perl group has a really great status page for the repository that can tell you when new upstream packages are available, or what's been worked on in the repository.

The aforementioned dh-make-perl helper, which is also under maintenance of the Debian Perl team, is undergoing some major refactoring. It is being re-worked in a more modular form down from it's monolithic 2000-line single-file status. At the same time, a test suite is being added so no further regressions will occur. I've tried to help out where I can, but this a huge task with many opportunities to screw things up, so the more eyes on the code, the better!

Monday October 27, 2008
08:35 PM

Solr Power!

I am reminded of the crowds at Canadian national curling events. There's always at least one really loud person in the upper seats that yells out "POLAR POWER!" then pulls a string through a coffee can to imitate the sound of a moose.

I kid you not. God bless this country.

Anyway.

For our latest project at $work, we decided to use Solr for indexing and searching. There is a Solr.pm on search.cpan.org, but I wasn't overly thrilled with the overall design.

So, in TIMTOWTDI style, I've created WebService::Solr. As added bonuses, I've created a model for Catalyst and a hook into DBIx::Class::Indexed.

I'm not 100% sold on the way I have things designed, but I've had some people show some interest in the module, so I hope to get some feedback soon.

Wednesday October 15, 2008
09:08 PM

Retro to the max ... times 2!

Recently, two CPAN releases have brought a certain amount of nostalgia to my mind's eye.

Andy Armstrong contacted me a number of months ago in relation to my 6502 CPU work.  Mostly he was disappointed in the lack of a test suite. I felt much the same way, and had really wanted a test suite for the next release. After numerous hours of searching, I stumbled upon the MoneyNES project.

That particular project has a set of scripts to test all (well, not quite all) of the ops and basic memory functions available to 6502 processors. I was able to write a simple parser to bind Acme::6502 to the test scripts and I instantaneously had a good number of tests for Andy's code.

To this end, for the latest release of Acme::6502 I was able to fix a few bugs including:

  • Fix PLP to clear B flag instead of setting it
  • Fix TSX to set N and Z flag based on the value of X
  • Emulate a page boundary bug in JMP instructions
  • Fix BRK to set B flag

Unfortunately, I was also able to find a few issues with the test suite. These were sometimes hard to spot but Andy is very knowledgeable and I was also able to find a really cool javascript-based 6502 emulator which confirmed our suspicions. I've sent patches to the suite upstream, and the author was very responsive -- though he says the project is dormant for now.

So, apparently Schwern owes me some Euros* ;)

The other bit of nostalgia deals with BBS-era art. I have a couple text mode art modules (1, 2) on CPAN already. In reality there are at least 5 variations on the standard "ansi art" format. I've compiled a fairly detailed set of modules to handle these formats and uploaded it to CPAN in the form of Image-TextMode.

I've uploaded some sample renderings so you can see the variety of formats and options available. Among those options we have:

  • "9th bit" -- the standard font is 8 bits wide, but typical displays used 9 bits (8th bit repeated).
  • "iCEColor" -- basically non-blink mode, last bit of the attribute byte now becomes part of the background color data
  • "ced" -- black-on-gray

The formats vary on 3 different aspects:

  1. Font -- Sometimes it just an 8x8 font instead of 8x16. Sometimes it's the "Amiga" font. Other times it's a completely custom font so artists can have free reign over the blocks
  2. Palette -- Allowing different colors allowed for a more truer representation for meat-space-based drawings (hello skin tones!), but I always found that the palette limitation forced artists to be truly creative. Anyway, the Tundra format actually allows for any number of colors on a 24bit spectrum.
  3. Dimensions -- why be stuck with 80 columns, when you could do 160? or 234? or some other random number?

The sad truth is that by the time most of these advances came along the "scene" was already on its way out, and judging but their usage, people really only believed there was "one true format"  -- the standard 8x16 font on a 16-color, 80 cols display.

This was one of my first experiments with Moose -- which ended up being quite enlightening. I still have some room to grow as far as using Moose to its full potential, but I'm definitely sold.

* Andy tells me he won an auction wherein Schwern was to add a test suite to Acme-6502 :)

Sunday July 27, 2008
09:02 PM

Accouncing: Fredericton.pm

For those of you who don't know, I live in Eastern Canada. Fredericton, specifically -- the capital of the province of New Brunswick. It's a pretty small place, especially as far as capital cities go. I believe we're only the 3rd largest city in the province.

With such a small place, user groups seem to be hit and miss. We used to have a Linux user group: FLUX (Fredericton Linux User eXchange -- cute, eh? :), then there was Linux Fredericton (still active, perhaps?). Most recently has been an Ubuntu specific group -- I might actually go to one of their meetings, should they schedule any more.

I've searched over the last few years for some sort of "scripting" group in town, but have come up with nada. So, last week I finally bit the bullet and opened my own Perl Mongers branch -- Fredericton.pm!

At this point, the group is basically a name and that's all. However, I hope to use that name to improve the visibility of Perl in Fredericton, and the surrounding Atlantic region. Perhaps, if i can get the word out to enough people, I might find a group of folks interested in not just Perl, but languages in the same range (PHP, Python, Ruby, etc) and we can get together and share our thoughts and ideas.

Wish me luck.

Thursday July 17, 2008
08:55 AM

Component resolution in Catalyst 5.7100

One of the things you'll see in the changelog for the next stable release of Catalyst, is a reworked component resolution system. By "component resolution" i mean, fetching components from view()/views(), model()/models(), controller()/controllers() and component().

Back in May I posted a message to the Catalyst-dev list describing some issues with the way it was currently working. Although I painted a slightly convoluted picture of doom and gloom -- it turns out that all is not lost; you were probably relying on an "undefined" behavior to begin with (kind of like assuming "keys %hash" will return things in a particular order).

For example, consider "MyApp" with two views: "Foo" and "Bar." Now, when you call "$c->view()" (i.e. with no arguments) what gets returned? Well, it depends. :) If you have none of the appropriate config (default_view) or stash variables (current_view, current_view_instance) set, then it's pretty much random.

If you write a test for the above, and see that "MyApp::View::Bar" is returned -- don't count on that test working in 5.7100 (the message I posted to the list has the technical details as to why). Though the test *may* continue to work, the above scenario will throw a pretty large warning:

Calling $c->view() will return a random view unless you specify one of:
* $c->config->{default_view} # the name of the default view to use
* $c->stash->{current_view} # the name of the view to use for this request
* $c->stash->{current_view_instance} # the instance of the view to use for this request
NB: in version 5.80, the "random" behavior will not work at all.

(FYI, if your application only has one view, calling "$c->view()" is considered "acceptable" and will spare you the warnings.)

A similar warning is thrown for $c->model(). $c->controller() with no arguments will continue to return the controller for the dispatched action. $c->component (sans args) will also stay the same, returning a sorted list of all component names.

Another issue I discovered while re-working the code was a failed reliance on the "regex" fallback.

Consider another "MyApp" with two views "Foo::Bar" and "Foo::Baz". What does "$c->view('Foo')" return? We've maintained backwards compatibility on this one -- it will return all matching views (order unknown). It is important to note that this returns an array, so list context is important. We've added a warning for this scenario as well:

Relying on the regexp fallback behavior for component resolution is unreliable and unsafe.
If you really want to search, pass in a regexp as the argument.

As noted above, if you truly were just searching for views, pass it a regex ("$c->view(qr{Foo})") and it will act as expected.

So, if you think you might be affected by these particular issues, test out the dev release! Don't say I didn't warn you. :)

Wednesday July 16, 2008
05:16 PM

Please test Catalyst::Runtime 5.7100 RC1 (aka 5.7099_02)

(Crossposted to the Catalyst-dev list)

We're putting out one final development release before we go full bore
with 5.7100.

NB: It is IMPERATIVE that you TEST this release against YOUR code. Quoth
mst: "If you do not test now any bugs we ship with are your fault!" --
so, there you have it :)

Also, we've reworked the authors list to be much like DBIx::Class; in
one spot (Catalyst.pm) with each person's IRC nick, name, and email. In
you can fill in any of the blanks, fire off an email or catch us in
#catalyst-dev and well gladly fix it up.

Whilst the release is making its way to CPAN, you can grab it from here:

http://dev.thefeed.no/stuff/Catalyst-Runtime-5.7099_02.tar.gz

The Changes since the last stable release include:

5.7099_02 2008-07-16 19:10:00
        - Added PathPrefix attribute
        - Removed Catalyst::Build; we've long since moved to
Module::Install
        - Updated Catalyst::Test docs to mention the use of HTTP::Request
          objects (Rafael Kitover)

5.7099_01 2008-06-25 22:36:00
        - Refactored component resolution (component(), models(),
model(), et al). We now
          throw warnings for two reasons:
          1) model() or view() was called with no arguments, and two
results are returned
             -- set default_(model|view), current_(model|view) or
current_(model|view)_instance
             instead
          2) you call a component resolution method with a string, and
it resorts to a regexp
             fallback wherein a result is returned -- if you really
want to search, call the
             method with a regex as the argument
        - remove 0-length query string components so warnings aren't
thrown (RT #36428)
        - Update HTTP::Body dep so that the uploadtmp config value will
work (RT #22540)
        - Fix for LocalRegex when used in the Root controller
        - Get some of the optional_* tests working from dirs with
spaces (RT #26455)
        - Fix Catalyst::Utils::home() when application .pm is in the
current dir (RT #34437)
        - Added the ability to remove parameters in req->uri_with() by
passing in
          an undef value (RT #34782)
        - Added $c->go, to do an internal redispatch to another action,
while retaining the
          contents of the stash