David Wheeler has written about running PostgreSQL tests under prove in his blog and I stole from his code shamelessly to create TAP::Parser::SourceHandler::PHP, released to the CPAN this morning.
So now, to run the Perl .t files and the PHP .phpt files all in one swell foop, here's what we do at work:
prove -r \
-I/home/alester/proj/Lib \
--source=Perl --ext=.t \
--source=PHP \
--ext=.phpt \
--php-option=include_path=/home/alester/proj/Class \
--php-option=extension=.phpt
That --source=PHP tells prove to load up TAP::Parser::SourceHandler::PHP. The --php-option tells prove to pass those options through to the SourceHandler. If we had PostgreSQL tests or MySQL tests, we could use the SourceHandlers for those that David Wheeler has written as well.
Now we can test everything all in one run, and we get all the benefits of Test::Harness 3.xx, like parallel tests and TAP archiving and so on.
]]>This is a minor release of Vim. It consists of Vim 7.2 plus all patches, updated runtime files and some more, see below. It has been two years since the 7.2 release, thus it's not that "minor". But not "major" either. Something in between, don't know how to call that.
The most notable additions since 7.2:
- Persistent undo and undo for reload
- Blowfish encryption, encryption of the swap file
- Conceal text
- Lua interface
- Python 3 interface
However, to the Perl programmer, this is a significant upgrade from 7.2, because of updates of all the Perl-related support files. Vim has language specific plugins for syntax highlighting, indenting and other filetype-related behaviors. Every one of these Perl-related support files has been updated. For example, syntax/perl.vim has not been updated since 2006. Now, Perl 5.10 keywords like given, when and state are properly highlighted.
For the Perl 6 hackers out there working with Rakudo Star, Vim now includes support for Perl 6. Until now, if Perl 6 programmers wanted Vim to support Perl 6, they had to use a perl6.vim file that got passed around from person to person. Now, it comes installed automatically as part of Vim 7.3.
Perl 6 detection is primitive, so you may have to explicitly add it to your modeline in your file, such as
# vi: filetype=perl6:
All of these changes are from the vim-perl project hosted on Github. In that project, I've aggregated syntax, indent and filetype plugins for the Perl and Perl 6 support files that get fed back to the Vim project. It's also got support for other filetypes like Template Toolkit that are not part of the vim distribution. I'm not making many changes to the Vim code directly. Like many of my other contributions to open source, my role is one of wrangler and coordinator and less of programmer and technologist.
If you're interested in Vim support for Perl 5 and Perl 6, I encourage you to check out the vim-perl project and join the vim-perl mailing list. Now that Vim 7.3 is out, we have some room to stretch out and make Vim do incredible things for Perl in the next release.
]]>Before the first edition of Programming perl, people commonly referred to the language as "perl", and its name appeared that way in the title because it referred to the interpreter. In the book, Randal Schwartz capitalised the language's name to make it stand out better when typeset. This convention was adopted by the community, and the second edition became Programming Perl, using the capitalized version of the name to refer to the language.
You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look good, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.
Those post-facto expansions are "Practical Expansion and Reporting Language" and "Pathologically Eclectic Rubbish Lister." Both are bacryonms, created after the language was named.
]]>Key points from his article:
And then, down in the comments, Moritz Lenz points out something I'd overlooked:
Yes, people now say "Rakudo is slow as $funny_metaphor", but that's much better than "Rakudo is vapourware". Once we speed up Rakudo, we can simply post benchmarks and say "look, it's now $n times faster than before". "Rakudo is slow" implies "Rakudo is", and that's a big step forward.
Thanks for the reminder, Moritz. Next it will be "Rakudo is faster, but not fast enough." And then maybe "Rakudo doesn't have enough documentation," and then "Rakudo doesn't have all the modules it should." All of it is progress.
]]>I bet none of those cranks remember Perl 4 and the shift to Perl 5.
Even with all those differences, we survived. In fact, we thrived.
The Pink Camel, first edition of Programming Perl, covering Perl 4, was only 450 small pages long, and a third of that was a section called "Real Perl Programs." (Imagine! Actual programs!) The Blue Camel, the 2nd edition, covering Perl 5, was over 600 bigger pages.
You know what I thought when I got my copy of the Blue Camel? It wasn't "Boy, this sure isn't Perl any more." No, I thought "Holy shit, look at all the stuff I can do." I couldn't even read the book straight through, because I kept skipping around, my mind amazed at the possibilities in front of me.
There are those who will read this and say "Yeah, but Perl 5 could still pretty much run any Perl 4 program, but Perl 6 won't be able to run Perl 5." And that's true. And it's irrelevant.
Perl 6 is still Perl, and is still called Perl, for many reasons, but only one that matters.
Larry Wall says that Perl 6 is still Perl.
Larry has his reasons. Some he's mentioned in past State of the Onion addresses. Maybe you don't agree with his reasons, or his decisions. But it doesn't matter one damn bit what you think. It's his decision. All arguments are a waste of time and brain cycles.
So when someone says "Perl 6 should have been named something else," I suggest a response of "OK, whatever you say. Now, isn't it cool that you can use list reduction to say my $sum = [+] @list;?"
]]>use Data::Dumper;
print Dumper( \%hash );
is a godsend to debugging data structures of any complexity.
Perl 6 has this dumping built in.
uniqua:~/rakudo/lab $ cat dumper
#!/usr/local/bin/perl6
use v6;
my %hash = (
'this' => 'that',
'year' => 2112,
'matcher' => regex { ^ M(r|rs|s)\. \s+ (\w+) \s+ Wall $ },
'rational' => 0.5,
'num' => (0.5).Num,
);
say %hash.perl;
# Or %hash.perl.say
uniqua:~/rakudo/lab $ ./dumper
{"num" => 0.5, "this" => "that", "year" => 2112,
"rational" => 1/2, "matcher" => { ... }}
Regex dumping does not display the actual regex yet, but Patrick Michaud says it's coming soon.
]]>I wrote my first real Perl 6 from scratch today. It's a prime number tester, where we test both via checking factors iteratively, and also using the magic prime number tester regular expression. I was inspired by a blog post about how PHP can't always handle regexes with lots of backtracking, and I thought it would make a good stress for Perl 6.
My program as it stands now looks like this:
#!/usr/local/bin/perl6
use v6;
# Perl 5 @ARGV is now @*ARGS
my Int @candidates;
if ( @*ARGS ) {
for @*ARGS -> $n {
push @candidates, $n.Int;
}
}
else {
@candidates = 2 .. 100;
}
for @candidates -> Int $x {
my $via_factors = is_prime_via_factors($x);
my $via_regex = is_prime_via_regex($x);
if $via_factors && $via_regex {
say "$x is prime";
}
elsif $via_factors xor $via_regex {
say "Difference in opinion on $x :",
"factors says $via_factors, regex says $via_regex";
}
}
sub is_prime_via_factors( Int $n ) returns Bool {
my $top = sqrt $n;
for 2..$top -> $i {
return False if $n %% $i;
# %% is the divisible-by operator
}
# Could also use: $n %% none(2 .. $top)
return True;
}
sub is_prime_via_regex( Int $n ) returns Bool {
my $str = 'x' x $n;
# First capture is $0, not $1 or \1 as in Perl 5
return False if $str ~~ regex { ^ x $ | ^ (xx+?) $0+ $ };
return True;
}
I'm sure there are ways that are more Perl 6ish to do what I've done above, but I was glad to learn along the way. Big thanks to the #perl6 IRC channel for help. Some important lessons:
There's a document about the differences between Perl 5 and Perl 6 which I updated based on tonight's fun, and will keep adding to along the way.
My goal is to have all of perl101.org include examples in both Perl 5 and Perl 6, both for people new to Perl and for those moving to Perl 6. If you'd like to help in this effort, let me know or work on the perl101 github project.
]]>On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the July 2010 release of "Rakudo Star", a useful and usable distribution of Perl 6. The tarball for the July 2010 release is available from http://github.com/rakudo/star/downloads.
Rakudo Star is aimed at "early adopters" of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These "Star" releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it.
In the Perl 6 world, we make a distinction between the language ("Perl 6") and specific implementations of the language such as "Rakudo Perl". "Rakudo Star" is a distribution that includes release #31 of the Rakudo Perl 6 "compiler, version 2.6.0 of the Parrot Virtual Machine, and various modules, documentation, and other resources collected from the Perl 6 community. We plan to make Rakudo Star releases on a monthly schedule, with occasional special releases in response to important bugfixes or changes.
Some of the many cool Perl 6 features that are available in this release of Rakudo Star:
There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Thus, we do not consider Rakudo Star to be a "Perl 6.0.0" or "1.0" release.
In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed.
See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. Rakudo Star also contains a draft of a Perl 6 book -- see
The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compiler@perl.org mailing list, or join us on IRC #perl6 on freenode.
Rakudo Star releases are created on a monthly cycle or as needed in response to important bug fixes or improvements. The next planned release of Rakudo Star will be on August 24, 2010.
]]>These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.
A question came up recently on a mailing list. I was talking about how Roles are a awesome win for Perl5 considering how few languages implement the concept1. Someone asked what the win was with Roles. I happen to have been thinking about this recently and dashed off a reply.
When you use Inheritance, especially multiple inheritance, for behavioral re-use you run into several problems quickly.
First Inheritance is an explicit modeling of a relationship that carries semantic meaning. Let's say you're developing a game for Biology students to explain to them taxonomy. In this game a Dog class is a subclass of Animal. That is, the Dog class inherits specific behaviors and attributes from the Animal class. This probably isn't even a direct relationship your Dog class may inherit from a Mammal class which inherits from a Vertebrate class which inherits from Animalia which itself inherits from Life. These kinds of hierarchies are common in Taxonomy as well as in Object Oriented programming. However when you need to express something that may cross cut concerns in, you run into issues.
Say for example your marketing department has had trouble selling this product to schools and is attempting to market to parents directly. They have done studies and kids really like Pets2. So your boss comes to you because the company wants you to add the concept of Pet to your Taxonomy model.
Pets don't fit into a Taxonomy, it's obvious that not all Animalias are Pets3 and some Pets may not be animals at all4. In many languages can use Multiple Inheritance to describe this new "I'm an Animalia and a Pet" relationship but often you run into issues there as well. Is a Pet a Life? That would mean our object model would look like:
Life
Animalia
Vertebrae
Canine Pet
Dog
Pet stands out like a sore thumb. Obviously we've got issues with this new modeling. We talk to our boss and figure out that the rules for Pet are simple. Pet's are always domesticated versions of the Animalia, but not every class in Animalia is a pet. So for example Dogs are always Pets, Wolves are not. We can solve this with multiple inheritance now, but it's really not a clean way to express the relationship and it requires us to document the special relationship the Pet class would have with the rest off the Inheritance tree. Once you get beyond a few "special cases" like this it becomes hard to see the model for the exceptions.
This is why some languages like to disallow multiple inheritance entirely. In Java for example, Pet could become an Interface.
public interface Pet {
Date getYearDomesticated;
}
This however means that every class that we want to be a pet needs to have the exact same piece of boiler plate code added to it.
class Dog implements Pet {
...
private Date yearDomesticated;
public Date getYearDomesticated () { this.yearDomesticated }
...
}
If we instead have the concept of Roles then we can apply the concept of a Pet once at any level of the hierarchy we need. A example using a modern Perl5
package Pet {
use Moose::Role
has year_domesticated => (
is => 'ro',
isa => 'DateTime',
required => 1
);
}
package Dog {
use Moose;
extends qw(Canine);
with qw(Pet);
}
The Pet Role here implements everything we need for a default implementation, and doesn't require more boiler plate to our Dog class, that the bare minimum needed. It also avoids the ugly inheritance issues we saw with multiple inheritance by moving the behavior composition onto different tool. In my opinion, Roles aren't a win for every use of inheritance, nor for every time you want to re-use behavior, but they are an excellent tool to have in the box and one that the Moose crowd knows to reach for quite often.
Off the top of my head I only know about Perl5, Perl6, Scala, Javascript, and Smalltalk. There may be other implementations out there. ↩
The Marketing guy's daughter plays on WebKinz nightly. ↩
Pet Shark's would be dangerous to say the least, and where would you keep a pet Blue Whale? ↩
Who doesn't love their Pet Rock? ↩
We're using the the inline package syntax that will be released in 5.14 ↩
Chris Prather is an Owner at Tamarou LLC, a member of the Moose cabal, and responsible for Task::Kensho.
]]>