blogs.perl.org

I always forget how to do this, so this is just Google fodder.

If I want to checkout a branch from someone else's repository:

git checkout -t -b $local_branch_name $remote_branch_name

The '-t' option says "track the remote branch from my branch". The '-b' option says to actually create the branch with the given name (name will be derived from $remote_branch_name if omitted).

It's so simple that I don't know why I forget this, but I do. Now that I've posted this, I probably won't forget it again :)

This is the video from the morning stand-up on everyone's progress for the first day of the 2010 Vienna Perl QA Workshop.

Backtracking is probably the defining feature of Prolog. Abstractly, the execution of a Prolog program can be seen as traversing a tree, looking for a path that fits certain criteria. Each node represents a choice between several options, and are usually referred to as choice points (for reasons that should be obvious). If at any time the path taken is found to be inconsistent with the constraints, execution goes back to the previous choice point and tries the next option. The search is depth-first, left-to-right.

Now, as I've mentioned before, in Parrotlog this is implemented using continuations, based on example code from Graham's On Lisp book (chapter 22). Simply put, continuations allow you to restore the execution of your program to a previous state. For the C programmers, this is simillar to setjmp(3) and longjmp(3), but returning from the originating function doesn't invalidate the saved state. On Lisp chapter 20 has more about continuations, and so do the Parrot docs.

The following is a brief summary of my Perl introduction/promotion talk at BarCamp Kerala 8, held in March 28th, 2010 at Tiruvalla, Kerala, India.

It was my first BarCamp, and the first other conference/camp that I ever attended apart from last year's YAPC::EU::2009 (which was a great experience, by the way!). I was very interested in having Perl promoted among a community that uses/promotes other programming languages. So, I thought of giving a talk and selected the title 'Y Perl?'. The talk concentrated on why Perl should be considered when there are myriad programming languages. Highlights were on the latest buzzwords in Perl, namely Catalyst, Moose and Padre, the community efforts such as Send-a-Newbie, Perl Monks and Perl Mongers.

Blog posts, pictures and tweets have been made on the session. You can find some at: http://bit.ly/brt0KV.

And, most of all, some people met me, expressing their interest in learning the Perl language. I am glad that I was able to encourage them to start taking up Perl. :-)

I am also intending to attend other camps/conferences (near and far), with the same motto of introducing/promoting Perl.

Hate the Perl debugger? Want it to do more? I do. For example, I hate it when I see this:

  DB<1> x $before                                                                                            
0  HASH(0x100e37fd8)
   'foo' => ARRAY(0x100c5f1d8)
      0  1
      1  2
      2  4
   'guess' => CODE(0x100dc0d78)
      -> &main::__ANON__[run.pl:13] in run.pl:10-13
   'this' => 'that'
   'uno' => HASH(0x100db9000)
      'this' => 'that'
      'what?' => HASH(0x10088dfc0)
         'this' => 'them'

At the end of last week, I sent mail to all CPAN authors letting them know that they could delete older distributions from author directories. CPAN is pretty large: last week it was almost 8 GB, and today it's almost down to 7 GB. That puts the Schwartz Factor at about 1/7th. We can do better.

It's not the size that's the problem so much: disk is cheap (still, no need to waste it). The more distributions CPAN stores, the more the masters need to check when a mirror wants to rsync. For the most part, mirrors only need to delete the files that disappeared and want the ones that appeared. The other files (aside from the PAUSE files such as CHECKSUMS) should not have changed. The rsync program doesn't know anything special about CPAN though, so it still does all its work.

Most aspects of the first round between Dancer and Mojo are covered in Alexis' post - a recommended read. However - with your approval, or not - I'd like to add another side of it, our overall developer understanding of the contest.

While it seems fun to "win" something, what we the developers (and I'm assuming it's pretty much the same for the Mojo people) liked most about the competition was that we'd get a complete understanding of the end-user learning experience.

David N. Welton:

This is actually, in my opinion, an interesting phenomenon in languages: you risk hitting some kind of local maximum when your language is popular enough to have a lot of users who will be angry if things are changed or accidentally broken in the course of big upheavals. So you have to slow down, go carefully, and not rock the boat too much. On the other hand, there is an opportunity cost in that newer languages with less to lose can race ahead of you, adding all kinds of cool and handy new things, or simply fix and remove “broken” features.

Oh brother.

And this bit as well:

The syntax, for your average programmer who doesn’t want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a “human” problem, rather than a technical one. Perhaps, sadly, the message is that you’d better not “scare” people when introducing a new language, by showing people something that [looks] at least a little bit familiar.

Arrived in Vienna last night and walked across the city center to get to the hotel. It's my second time in Vienna and I love how beautiful it is.

Here are the slides I've use while delivering my Fishing for Perl: The Perl New User Experience talk. These are not really slides, in any sense, the Powerpoint one or else, but actually a .pdf file that I generated out of this LaTeX source.

My main work method in creating this talk was two-fold. One, I jotted down ideas I had on the most immediate means, paper or electric (I found Google Wave to be an excellent tool for this, the only actual use I found for it). Two, I edited those ideas to a LaTeX document until they actually formed what seemed (at the time) a sensible narration. I also tend to follow the idea that if you can understand the talk by just reading the slides then the talk has no value. This actually means you may not understand much of what I'm talking about by just reading the slides.
That's OK, because I intend to use that as a base for several posts here.

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.

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

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'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...

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.

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.