blogs.perl.org

I know why "date" and "time" are in there, but I suspect it's not common for most folks.

~  $ history | awk {'print $2'} | sort | uniq -c | sort -k1 -rn | head
 255 git
 174 fg
 108 vim
  79 prove
  58 ack
  56 cd
  51 ls
  42 time
  41 rm
  31 date

In the I went with the simple solution to the problem of unification. Variables point to other variables, and in the end a variable either points to a term, or nothing. What happens when you unify X with Y, Y with Z, and Z with X should probably not be considered just yet, and will probably have to be fixed at some point. But that should be reasonably simple. Finding cycles in a graph is after all a well-known problem.

This means that the core infrastructure I need should now be in place: unification, backtracking and cuts (a post on those last two is coming up). Now it's time to start looking into writing the grammar, and figuring out how to represent rules and the fact database.

When writing Perl, people often create hybrid interfaces that accept either a reference to an array or hash, a string, or a reference to a string. The Perl code to do appropriate conversion behind the scenes is usually trivial. Some even use this to overload their interface to do something entirely unrelated depending on the type passed in. However much one might loathe such interfaces, when replacing Perl code with XS, one usually has to reproduce the properties of the original. That is what this entry is about.

A rather reasonable example of such a hybrid interface is PPI::Document whose constructor accepts either a string (interpreted as a file name) or a reference to a scalar (interpreted as a reference to a scalar containing the code as a string). While (different) named arguments would have been clearer for a casual reader of the resulting code, this case of an overloaded interface is a generally reasonable optimization.

Last week, Marcel Grünauer (hanekomu) tweeted about his PAUSE deletions possibly triggered by one of the recent discussions about the CPAN ecosystem (and mirroring deficiencies). PAUSE sends deleted files to the BackPAN which has everything released to CPAN. However, selecting the files to delete is not much fun since PAUSE UI is sadly not dynamic and if you have lots of distributions you'll have even more released files on PAUSE.

I constantly see requests from companies to allow non-programmers to write automated tests. I also see products that allow this on various levels of sophistication. Every such tool also requires some programming in a high level language. Sometimes that is VB Script or .NET or Java. It is rarely Perl.

By the time the customer understand that they need a lot of extra programming they have already invested a lot of money and time so they won't switch to another solution even if that saved them a lot of money and time.

So I though I might try to reinvent this wheel. The idea would be to create a GUI where a user can select "tools" (e.g. "web browser", "telnet client", "database client") and add these tools to the test script by clicking on a button. Once a "browser" was added the user can do various things with that browser: fetch a url, check if
content has certain string in it, click on a link defined by the text on the link etc.

I've finally hit the first real roadblock in the development: unification. Instantiating a free variable and unifying that with a term is simple enough (and works). The problem is when you start unifying free variables with each other. For example you have three free variables: X, Y, Z. You unify X with Y, and then Y with Z. Finally, unify Z with a term "foo". The value of X (and Y and Z, for that matter) should now be "foo". What stumps me is how to implement this in a sane way. I've looked at the AI::Logic and "Perl and Prolog and [...]" versions, but I haven't managed to duplicate them in NQP in way that works...

Perl Iron Man has been getting hammered by spam the last couple of days. Any sign of of a let-up?

I've just launched a 'white papers' section on Perl.org:

http://www.perl.org/about/whitepapers/

I've set the following as a rough brief for these documents:

• Corporate technical managers (may not know Perl)
• Coders new to Perl looking for reasons to use Perl
• Existing Perl coders who are not 'enlightened', e.g. not aware of these technologies and how they make coding better.

• Convince someone to try this technology
• Show how many great Perl tools there are for different types of project (breadth not depth)
• Have a location someone advocating Perl can point to, which provides a quick over view of some of the current tools available

• Start with a quick overview of what the technology is, you have to convince people to use this technology in this first paragraph
• Try not to refer to 'your' code, it might be a manager reading this - this is not always possible though!
• Do not try to teach the technology, but offer resources which will (references section at the end)
• Avoid dates / anything which will require updating in the future, if possible

• Article should be as short as possible
• Avoid code where possible.

If you have corrections or are interested in writing one of the outstanding topics do let me know.

I recently asked Adam Kennedy why he went back to blogging on use.perl.org. He replied:

I stopped posting to blogs.perl.org until I can migrate everything from use.perl over to it.

Anyone want to work on a migration script? I'd do it myself were it not for the Veure project I'm on. You just have to look at the gists in this post or the image on this post to see why the communication is so much richer here. Of course, there are plenty of other reasons, but clearly blogs.perl.org is a great, modern platform for the Perl community and I'd love to see more people promoting it.

The inspiration for this project is primarily due to my reading On Lisp by Paul Graham, which talks about implementing non-deterministic search (or backtracking, if you will) with continuations (chapter 2022). Since I know Parrot supports continuations natively, it was an obvious choice. Some googling also revealed a very interesting PerlMonks post, entitled Perl and Prolog and Continuations... oh my!, which it turns out is the inspiration for Ovid's AI::Logic as well (which I discovered a few days ago).

Now, on to the implementation. Most of the documents I've found tell you to start your Parrot HLL project with a script called mk_language_shell.pl, but I found that it doesn't do quite what it say on the tin. Instead I used tools/dev/create_language.pl. This script creates a basic folder hierarchy similar to the one used by Rakudo. A quick tour of the files and folders:

• build/ contains everything that has to do with the build process. Most interesting is PARROT_REVISION which specifies which Parrot is required, and Makefile.in which is where the build process can be extended.
• Configure.pl does what it's called. Call it with --gen-parrot to build the required Parrot version as well.
• t/ and src/ contain the usual bits

EDIT: I lied. Backtracking is chapter 22 of Graham's book. Chapter 20 is continuations.

So it turns out I'm not really good at this blogging thing. It's not that I feel I have nothing worth writing about, but that my time is usually better spent on other things. Instead of pretending to myself that I will eventually write long rants (and then effectively writing nothing), I'll try to post occasional bits of code that I found useful and not particularly obvious. I've been writing a lot of XS lately and the somewhat incomplete or at least inaccessible XS / perl API documentation could do with a little more cookbook style. Furthermore, when writing C/XS code that uses the perl API, I find myself trying to do the same things that are trivial in Perl and taking much, much longer to actually succeed. Thus, I'll start out with a bit of perl API.

Today's Not-So-Frequently-Encountered-XS-Problem:
Which class is this object blessed into?

Jesse Vincent uploaded the perl-5.12.0-RC3 release to the CPAN. It's important that that this release is tested to flag any potential release blockers. If none are found it'll be released as 5.12 on April 9.

Here's how you can do that:

All tests should have been successful. To install it (without touching your existing perl!) do:

Now you have an installed perl-5.12.0-RC3 in ~/perl5-rc3/installed/bin/perl. Now just configure CPAN to install modules without nagging:

And then maybe try installing your favorite CPAN modules, or bundles that suck down a lot of them (using sudo here because my ~/.cpan is owned by root):

Of course the most useful think you can do is test it on your own in-house code. All the code on the CPAN has probably been tested with 5.12 already.

If you encounter any issues first check if they're listed in the errata or mentioned in the perldelta for 5.12.

if you think you've found a new bug please report it with the perlbug tool installed with perl-5.12.0-RC3.

Testing is, in some sense, a mess. Part of the problem is similar to the dynamic/static schism: nobody seems to agree on what those terms mean. Case in point: what's "integration testing"? Here's the definition from the excellent Code Complete 2:

Integration testing is the combined execution of two or more classes, packages, components, or subsystems that have been created by multiple programmers or programming teams. This kind of testing typically starts as soon as there are two classes to test and continues until the entire system is complete.

Read that carefully. Look for a flaw.

A Stackoverflow answer that encourages the questioner to use Moose has a long code example because it has a lot of code and formatting since there is a lot of repeated typing:

As the second talk in a series of talks on form handling, Bryan Beeley will be presenting a talk on the HTML::FormHandler, a Moose based form rendering and validation framework, on April 27th, 2010 at Six Apart World Headquarters.

HTML::FormHandler is an object oriented framework for form-specific data model, HTML rendering and data validation code. Simple forms can be rendered, parameters can be parsed, data can be validated, and validated data can be submitted to your database with a minimal amount of code using built-in input field types. Leveraging the power of Moose, HTML::FormHandler allows more complicated forms to override some or all of the built-in functionality while maintaining a common interface.

This meeting will take place on Tuesday, April 27rd at 7pm at Six Apart World Headquarters.

HTML::FormHandler on CPAN:
http://search.cpan.org/dist/HTML-FormHandler/

RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/13059396/

Announcement posted via App::PM::Announce

Enlightened perl programmers often complain about how outdated most online perl manuals. Truth is, some of the official documentation is quite outdated too. Perl ships with a lot of documentation, some of it is old and badly needing some maintenance.

For example, a quick ack through the documentation showed about 250 cases of open used with a glob as its first argument (e.g. open FOO;), even one in perlstyle! I think everyone agrees that in 2010 that's no longer a good example. I don't think it has a place outside of perlfunc and perlopentut. The same argument goes for two argument open and use vars. I'm sure there are plenty of other issues that I can't think of right now.

That's not hard to fix, in fact you could almost write a program for it. It may be a lot of work though to fix all of them, but not so much to fix them one by one.

CPAN is a very good system to distribute libraries we call packages or modules. What about applications? There is a section on CPAN that was supposed to distribute scripts but it never took off. Is CPAN ready to be used to distribute applications? If not, what is missing?

Padre

system seems like such a simple thing to use. You tell it which command to run, and it runs it. When it's done, you continue with your program, or so you think. I recently ran into a problem with this. I was creating a lot of zombies, but Dread Pirate Fenwick to the rescue (and this is not his first time to rescue me).

As part of my DPAN work, I'm indexing every distribution in BackPAN. I collect loads of data on every distribution so I can make a searchable catalog of it. When you want to use DPAN to create private CPAN repositories, you shouldn't have to re-index distributions where we already know the answer. I can provide most of the answers pre-cataloged so you focus on only the novel distributions in your repository. I have a tarball of sample results for 16,000 distributions.

Adam Kennedy has declared a contest between Dancer and Mojolicious. Seems to me like a great idea. We'll both get a chance to learn from each other, show our strengths and try to work on our exposed weaknesses.

One major issue about Mojolicious is that they decided to do everything in core (at least from perl 5.10.1), without any additional dependencies that aren't in Perl core (while, we at Dancer, try to keep the dependencies to a minimum). This has many disadvantages (reinventing the wheel, handling the same issues over and over, needing a lot of knowledge on how to implement everything) and a lot of advantages (easier deployment, easier packaging for vendors, more control). This post is about one of those advantages.

# http://search.cpan.org/perldoc?DBIx::Class::ResultSet#cache
my $rs = $schema->resultset('Artist')->search(
    {},
    { cache => 1 },
);
my @artists = $rs->all;
pop (@artists);
$rs->set_cache(\@artists);

my $count1 = $rs->count;
my $count2 = scalar $rs->all;
my $count3 = scalar $rs->get_column('id')->all;

Q1: What are the values of $count1, $count2 and $count3?

A1: 9, 9, 10.

Q2: Why?

A2: $rs is a cached result set. Some methods on $rs return the cached results. Some don't and query the underlying db table(s).

Q3: Which ones do & which ones don't?