mpeters's Friends' Journals

Finally, some Test::Builder2 examples!

schwern — 2010-09-09T08:33:42+00:00

For my PDX.pm presentation tonight on Test::Builder2 I threw together some quick examples of some of its killer features, in particular demonstrating changing how Test::Builder2 behaves using method modifiers and applying object roles.

First, demonstrating end-of-assert actions, there's die on fail but even cooler is DEBUG on fail! That's right, run your test in the debugger and have it automatically set a breakpoint on a failure. How cool is that?

I'm sure somebody with better debugger foo than I can make it even cooler and stop at the top of the assert stack rather than inside DebugOnFail.

The second is reimplementing Test::NoWarnings safely. TB2::NoWarnings demonstrates hooking into the start and end of the test as well as safely altering the number of tests planned by trapping the call to set_plan.

You can safely use them all together, though its a crap shoot if DebugOnFail or DieOnFail will trigger first.

While roles and method modifiers are relatively new to the Perl community, using them in lieu of designing my own event system for TB2 has two great advantages. First, I didn't have to design and debug my own event system. :) Second, rather than having to learn the quirks of a one-off system, you learn the quirks of Mo[uo]se and then can apply that knowledge all over the place.

There's a pile of stuff to be done in TB2, a lot of them are fairly small and self contained. Have a look. Patches welcome.

Test::Builder2 at 10k Feet

schwern — 2010-09-09T08:15:22+00:00

Here's a diagram of the "flow" of assert results through Test::Builder version 1.

.-------. | foo.t | '-------' | | .-------------. | .----------------. | Test::More |<--------->| Test::Whatever | '-------------' '----------------' | | | | | | | .---------------. | '---->| Test::Builder |<----' '---------------' | v .-----. | TAP | '-----' | v .---------------. | Test::Harness | '---------------'

You write foo.t using Test::More and Test::Whatever. These both
use the same Test::Builder object. It spits out TAP which
Test::Harness converts into something human readable.

The big problem there is Test::Builder is monolithic. There's no
further breakdown of responsibilities. It only spits out TAP, and
only one version of TAP.

Here's what Test::Builder2 looks like:

.-------. .----------------| foo.t |-------------------. | '-------' | | | | | | | v v v .------------. .----------------. .------------------. | Test::More | | Test::Whatever | | Test::NotUpdated | '------------' '----------------' '------------------' | | | | v v | .----------------. .---------------. '---------->| Test::Builder2 |<------| Test::Builder | '----------------' '---------------' | v .--------------. .-------------. | TB2::History |<---| TB2::Result | '--------------' '-------------' | | .--------------------------. | .---------------------. | TB2::Formatter::TAP::v13 |<-----'------>| TB2::Formatter::GUI | '--------------------------' '---------------------' | | v | .-------------------------------. | | TB2::Formatter::Streamer::TAP | | '-------------------------------' | | | v | .-----. | | TAP | | '-----' | | | v v .---------------. .-----------------. | Test::Harness | | Pretty Pictures | '---------------' '-----------------'

It starts out the same, foo.t uses a bunch of test modules
including Test::More and Test::Whatever using the same Test::Builder2
object, but it also uses Test::NotUpdated which is still using
Test::Builder. That's ok because Test::Builder has been rewritten in
terms of Test::Builder2 (more on that below).

Test::Builder2, rather than being a monolith, produces a
Test::Builder2::Result object for each assert run. This gets stored
in a Test::Builder2::History object for possible later use. It also
gets handed to a Test::Builder2::Formatter object, the default is
Test::Builder2::TAP::v13 which produces TAP version 13. This is fed
to a Streamer that prints it to STDOUT and STDERR which is read by
Test::Harness and made human readable.

Because Test::Builder2 is not monolithic, you can swap out parts. For
example, instead of outputting TAP it could instead hand results to a
formatter that produced a simple GUI representation, maybe a green
bar, or something that hooks into a larger GUI. Or maybe one that
produces JUnit XML.

Here's how Test::Builder and Test::Builder2 Relate.

.-----. .-----. | TB2 | | TB1 | '-----' '-----' | | | | | | | | v v .-------------. .--------------. .-------------. | TB2::Result |------->| TB2::History |<--------| TB2::Result | '-------------' '--------------' '-------------' | | | | | | | .----------------. | '------------->| TB2::Formatter |<--------------' '----------------' | v .--------. | Output | '--------'

Test::Builder and Test::Builder2 coordinate their actions by sharing
the same History and Formatter objects. If you call TB1->ok() it
produces a Result object which it hands to the History singleton and
the Formatter singleton. If you call TB2->ok() it produces a Result
object which it hands to the same History and Formatter objects.

This allows most of the Test::Builder code to remain the same while
still coordinating with Test::Builder2. It also allows radically
different builders to be made without Test::Builder2 dictating how
they're to work.

The downside is that roles applied to Test::Builder2 will not effect
Test::Builder. Because of this, Test::Builder may become more closely
coupled with Test::Builder2 in the future.

Diagrams by App::Asciio.

DBD::SQLite 1.31 releasing next week and may break your code

Alias — 2010-09-09T02:11:54+00:00

After 6 or 7 months (mainly waiting around for the next "recommended upgrade instruction" from the SQLite project) the latest DBD::SQLite release should occur next week.

You can get the 1.30_06 release candidate from the CPAN, or from the following URL if your mirror hasn't synced yet.

http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_06.tar.gz

Apart from the normal batch of SQLite upgrades (from 3.6.22 to 3.7.2), bug fixes, and minor enhancements, this release has two changes that may break your code.

These changes have been in the dev releases for some time, but you may want to take the opportunity to test more intensively if you use either of the following features.

1. BLOB columns with UTF8 content

- Resolved #54271: Inserting a string with utf-8 flag on corrupts BLOB data; now BLOB data is always stored as bytes (without the utf-8 flag) even if it has the flag set (ISHIGAKI)

2. FTS3 queries

- Added support for FTS3 tokenizers written in Perl. Added tests and documentation on how to use FTS3. Changed compilation flag to use the recommanded -DSQLITE_ENABLE_FTS3_PARENTHESIS *** MAY POSSIBLY BREAK OLD APPLICATIONS THAT ALREADY USED FTS3 *** (DAMI)

If you are currently using FTS3, please see DBD::SQLite::FTS3Transitional which contains a helper function for automatically upgrading old FTS3 queries to the new syntax.

The Pugs repository is dead; long live Mu!

masak — 2010-09-06T06:30:29+00:00

This weekend marks the end of a quite astonishing era. The Pugs repo, that hosted all the amazing Perl 6 activity, is no more. At its height, this repository had 242 committers! I just checked.

The Pugs repository has functioned as a common writing area for Perl 6-related things. First Pugs; then a lot of external modules and scripts written in Perl 6; what would eventually morph into the Perl 6 test suite; even the Perl 6 specification and the standard grammar. Commit bits (write access credentials) were handed out liberally, and newcomers were encouraged to help improve things they found amiss. The degree to which this system worked without a hitch has been quite astonishing. There have been no edit wars, no vandalism, no banning. Just the continuing flow of commits. Trust the anarchy.

So why are we killing off the Pugs repository? Well, technologies come and go; not so much because they worsen by each year, but because our expectations rise in a sort of software inflation. The SVN repository became too high-maintenance, and a transition to git was the natural next step. The Pugs repository has been split up into the git repositories linked to in the previous paragraph. Those bits that don't belong in any of the standard bins remain in the Mu repository. (Its name is a reference to the most-general object type in Perl 6, what in other languages is commonly known as 'Object'.)

I for one salute our new git-based overlords! May the commits keep flowing even under this new system. Also, moritz++ for carrying out the move.

Should Module::Install move to explicit plugin declaration?

Alias — 2010-09-06T02:26:06+00:00

Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.

With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.

But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.

I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.

And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.

I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.

use inc::Module::Install qw{ Catalyst XSUtil };

This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).

Thoughts?

Yapsi 2010.09 Released!

masak — 2010-09-01T22:31:48+00:00

It is with a peevish exultation of spirit that I announce on behalf of the Yapsi development team the September 2010 release of Yapsi -- soon to be a major motion picture -- a Perl 6 compiler written in Perl 6.

You can download it here (or, if you happen to be on an avian-carrier-based network, you can "pidgeon" it here).

Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and run. This release of Yapsi has been confirmed to work on both Rakudo Star 2010.08 and Rakudo Star 2010.07.

Yapsi is an "official and complete" implementation of Perl 6. Yapsi's official status has been publicly confirmed by Patrick Michaud, the Rakudo pumking. The claim about Yapsi being complete... well, it might just be what PR people sometimes refer to as "a slight exaggeration". On the bright side, it's becoming less so with each new release.

This month's release brings you unless and until, as well as our-scoped variables:

$ yapsi -e 'my $a = 0; unless $a { say 42 }' 42

$ yapsi -e 'my $a = 0; until $a { say ++$a }' 1

$ yapsi -e 'our $a = 42; { my $a = 5; { say our $a } }' 42

For a complete list of changes, see doc/ChangeLog.

Quite a lot of features are within reach of people who are interested in hacking on Yapsi. See the doc/LOLHALP file for a list of 'em. In fact, that's how isBEKaml++ implemented 'unless' this month. (After which he exclaimed "that was easy!" and tackled 'until'.) If you're wondering whether you're qualified to help with the Yapsi project, that probably means you are.

Yapsi consists of a compiler and a runtime. The compiler generates instruction code which the runtime then interprets. In Yapsi, that instruction code (unfortunately) is called SIC[!]. Until further notice, SIC as a format changes with each monthly release for various, mostly good reasons. However, if you write a downstream tool that makes assumptions about the SIC format, someone might change it just out of spite. SIC is explicitly not compatible with later, earlier, or present versions of itself.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

A time-traveling debugger (tardis), which hooks into the runtime.
A coverage tool (lid), which will also hook into the runtime.
A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes.

Have the appropriate amount of fun!

Rakudo Star 2010.08 released

pmichaud — 2010-09-01T12:36:56+00:00

[This announcement was made last week on rakudo.org -- I'm reposting to use.perl.org so it will show up in the various Perl aggregators. --Pm]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the August 2010 release of "Rakudo Star", a useful and usable distribution of Perl 6. The tarball for the August 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". The August 2010 Star release includes release #32 of the Rakudo Perl 6 compiler [1], version 2.7.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community.

This release of Rakudo Star adds the following features over the previous Star release:
* Nil is now undefined
* Many regex modifiers are now recognized on the outside of regexes
* Mathematic and range operations are now faster (they're still slow, but they're significantly faster than they were in the previous release)
* Initial implementations of .pack and .unpack
* MAIN can parse short arguments
* Removed a significant memory leak for loops and other repeated blocks

This release (temporarily?) omits the Config::INI module that was included in the 2010.07 release, as it no longer builds with the shipped version of Rakudo. We hope to see Config::INI return soon.

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. Some of the not-quite-there features include:
* nested package definitions
* binary objects, native types, pack and unpack
* typed arrays
* macros
* state variables
* threads and concurrency
* Unicode strings at levels other than codepoints
* pre and post constraints, and some other phasers
* interactive readline that understands Unicode
* backslash escapes in regex character classes
* non-blocking I/O
* most of Synopsis 9
* perl6doc or pod manipulation tools

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. An updated draft of a Perl 6 book is available as in the release tarball.

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 channel #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 September 28, 2010.

[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

A month of Test::Builder2

schwern — 2010-08-28T04:08:39+00:00

I've had a grant open for Test::Builder2 for, oh god over two years now. Since I started it, Perl 6 has had a release! I think its the second oldest running dev grant.

I've cleared the decks of other responsibilities and can dedicate September to, if not finishing, then at least releasing something people can poke at. First alpha release was supposed to be "two weeks after the start" ha ha ha! oh god. The design has evolved and simplified greatly in the intervening two years, but its time to get something the hell out the door. At least a Test::Builder2 Star if you will.

There's critical components missing. There's no diagnostics, YAML or otherwise. The issues with nested asserts are still congealing. Plans are not enforced. Result objects are in the middle of being remodeled... again. But Test::Builder is using what parts of Test::Builder2 are usable. Multiple output formats and streams work. Asserts can be nested in the common, simple cases without having to fiddle with $Level. And you can hook into various events.

Step one is I'm going to seal up what's there, write docs where they're missing, and release something.

A release before October or the grant dies.

Idiomatic Perl 6

masak — 2010-08-27T00:22:03+00:00

So, I wrote a program to generate Pascal's triangle. The first ten rows of the triangle, at least. It only used simple features of Perl 6, such as scalars, nested arrays, and for loops.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current; push @current, @last[0]; for 0 .. @last - 2 { push @current, @last[$_] + @last[$_ + 1]; } push @current, @last[ * - 1 ]; push @pascal, [@current]; } say @pascal.perl;

In fact, save for simple mechanically substitutable differences, it could have been a Perl 5 script. In fact, with a bit of manual array allocation, it could have been a C script. That's OK; there's a tolerance in the Perl community of writing code that looks like it was thunk in some other language.

But I've heard that Perl 6 is great at doing things with operators. For example, the Z operator, which interleaves two lists, seems to be able to help me write my push statements more succinctly:

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current; for (0, @last) Z (@last, 0) -> $left, $right { push @current, $left + $right; } push @pascal, [@current]; } say @pascal.perl;

The parentheses before and after the infix:<Z> aren't necessary, because the Z operator has looser precedence than comma. They're just shown here to make your eyes accustomed to reading this construct.

In fact, now that only the addition is performed in the inner loop, I might as well use the Z+ operator, which does this for me.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current = 0, @last Z+ @last, 0; push @pascal, [@current]; } say @pascal.perl;

Now as the remaining loop shrinks to a size I can take in all at once, I see a bit more clearly what I'm doing: I'm building each new list from the previous one. I could feed the previous list into a named function to get the current one:

my $ELEMENTS = 10; my @pascal = [1]; sub next-list(@p) { [0, @p Z+ @p, 0] } for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current = next-list(@last); push @pascal, @current; } say @pascal.perl;

Or I could just feed it into a in-place anonymous sub.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; push @pascal, (sub (@p) { [0, @p Z+ @p, 0] }).(@last); } say @pascal.perl;

But why even a sub? Perl 6 has a lighter construct, namely a "pointy block" (also known as a "closure" or a "lambda"). It doesn't participate in the call stack, and it's slightly easier to write.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; push @pascal, (-> @p { [0, @p Z+ @p, 0] }).(@last); } say @pascal.perl;

Let's look at what the code does. Seed with one element. Calculate the next element based on the previous one. Stop at some point.

But that's exactly what the series operator does. The one that's written with three dots. We have a starting value, a way to get from one value to the next (our code block above), and a stopping value.

Well actually, we don't have the stopping value. But that's OK, since the series operator is lazy. So if we only request the first 10 values, it won't loop forever giving us the rest of the list.

my @pascal := do [1], -> @p { [0, @p Z+ @p, 0] } ... *; say @pascal[^10].perl;

(The extra do required because of a shortcoming in Rakudo.)

Now. Something very much like this code was posted first on Rosetta code and then on Moritz' blog. (TimToady used a sub, but said later that he'd have preferred binding.)

A couple of Perl 5 people's reactions were — somewhat uncharacteristically — of a negative flavour, similar to how people seem to react to the periodic table of operators:

@shadowcat_mst: an excellent example of why I consider camelia perl to be a language research project more than a production language

@pedromelo: I'm seriously considering this post as an example of what I don't want Perl6 to become...

I think these reactions are mainly feature shock. Higher-order operators, pointy blocks, and the series operator... they're all good, well-established features, which find daily use in Perl 6 programs. Maybe using them all together like that flung some people off the deep end. Never mind that the resulting script is all essential complexity, with virtually no boilerplate from the original script left.

This is the first time that's happened. I think it's important to listen to what Perl 5 people think and to try to respond to that. But I also think that this time, it's a case of them seeing some highly idiomatic Perl 6, and freaking out a bit.

And I think that that, in some odd sense, is a good thing. Well, not freaking people out, per se. But the fact that we did shows that there's something forming which might be tentatively called "idiomatic Perl 6": people on the inside can read it quite easily, but those on the outside, even Perl 5 folks looking in, instinctively go "eeeeew!".

That's OK. You're not meant to start with the idiomatic stuff. Language acquisition takes place step by step, and that goes for learning Perl 6 as well. On the way there, just don't confuse distaste with lack of familiarity.

Where in the world is the package lexpad?

masak — 2010-08-22T21:39:58+00:00

(This post isn't very punny. For those of you who need puns to survive, try to figure out why jnthn++ named the IRC logs "the hottest footwear" recently. The answer, as with all good puns, is highly unsatisfying.)

My quest for a Perl 6 implementation takes me ever deeper into the esoterics of lexpads, runtimes, and a far-more-than-everything-you-needed-to-know mindset. Today some random firings in my brain turned into the following conversation on #perl6.

During the conversation, I proposed two theories, both of which turned out to be wrong. (pmichaud++ shone the necessary light both times.) Being wrong felt less important than getting my mental model fixed.

I first thought of presenting the results of the below conversation as a simple tutorial ("How our declarations work. The complete guide."), but now I think that the conversation, minimally edited, manages to be such a tutorial on its own.

Besides, blogging things in their raw and undigested form is a sign of the times. Enjoy!

<masak> I have a question. is there a need for a special "package lexpad" containing 'our'-declared variables, or can the package lexpad simply be equated to the topmost lexpad in the package? <masak> my suspicion is the latter, but I might be missing something. <pmichaud> the package lexpad can't be the same as the top most lexical <pmichaud> module XYZ { my sub abc() { ... } }; # abc should not appear in the package <masak> oh! <masak> right. <masak> so, separate one, then. <jnthn> Additionally, lexpads are meant to be static by the time we hit runtime, and you're allowed to shove stuff into the package dynamically. Not quite sure how those two hold together. <pmichaud> well, module XYZ { ... } creates a lexical XYZ entry that holds the package entries <jnthn> Aha! <pmichaud> and it's just a hash, really. <masak> does inserting the package lexpad below the outside lexpad (and above the topmost lexpad) make sense? that way, Yapsi wouldn't need any special opcodes for doing 'our'-variable lookups. <pmichaud> the package lexpad is an entry in the outside lexpad, yes. <pmichaud> I'm not sure it encapsulates the nested lexpad, though. <masak> hm. <masak> if it doesn't, I don't really see how it's visible from inside the package. <masak> I've more or less convinced myself that sandwiching it between outer and topmost is what I want to do for Yapsi. <pmichaud> our &xyz can make an entry in both the package and in the lexical. <pmichaud> this is what rakudo does now. <pmichaud> we have to do similar things for methods already, too. <masak> sure. it makes entries in both. <pmichaud> by having entries in both, that's how it's visible inside the package <masak> hm, indeed. <masak> no need to have the package lexpad visible from inside. <pmichaud> anyway, sandwiching might work too. haven't quite gotten to that point in Rakudo thinking yet. And it can get a bit tricky with multis. <masak> no need to sandwich it in, either. it can sit in limbo outside the tree of scopes. <pmichaud> oh, I know why it perhaps shouldn't (or should) be visible: <pmichaud> my $x = 'lexical'; module XYZ { say $x; { our $x = 'package'; } } <masak> ...yes? <pmichaud> I'm pretty sure "say $x" needs to grab the 'lexical' $x, not the one that might be "sandwiched" in a package. <masak> of course. <masak> that falls out from ordinary scope nesting and shadowing. <masak> innermost block binds its lexical to the container in the package lexpad. <masak> so, that speaks out against sandwiching. <masak> pmichaud++

So there you go. There's a separate package scope, and it isn't sandwiched.

(Answer: The missing link is the "IR clogs" meme from #parrot. I can hear you groaning... I did warn you.)

Will parrot be the last one standing?

nicholas — 2010-08-20T09:37:19+00:00

I'm a bit behind the times here, but I read today that one of the two remaining developers of IronRuby has left Microsoft:

Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general. At the time of my leaving Tomas and myself were the only Microsoft employees working on IronRuby.

http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.htm l*

So if Microsoft's interest in dynamic languages is wilting, and Oracle's litigation scares everyone away from Java, will that leave Parrot as the last one standing?

* yep, that's a formatting bug. I assume that it's not worth reporting while the site's future is unclear.

Speaking at Microsoft TechEd - Any issues you want raised?

Alias — 2010-08-20T03:20:46+00:00

Next week I will at Microsoft's TechEd Australia event, courtesy of Microsoft Australia and Microsoft Open Source Labs.

More specifically, I'll be attending the Open Source mini-conf and discussion day on Tuesday, and presenting in the Community Presentations to Microsoft session on the current state of Perl and Windows on Wednesday.

Likely topics will include a review of the first year of the CPAN Testing Lab and a second-generation based on their Cloud Services, free code signing certificates for open source developers, and what issues are slowing us down or blocking progress.

So consider this your opportunity to raise any outstanding issues you have with Microsoft and Perl. What problems are you still seeing, what would like fixed or changed, and what is on your want-to-have list?

I'll try to address as many of your issues as possible in the time I have available with them (which is actually pretty substantial).

New WWW::Salesforce release details

Phred — 2010-08-19T17:24:05+00:00

I've taken over the maintainership role for WWW::Salesforce and have pushed out a maintenance release that resolves some long standing issues.

http://search.cpan.org/dist/WWW-Salesforce/

0.12 Tue Aug 17 19:34:00 2010 PST
- New maintainer PHRED
- Thanks to Mark Stosberg for several patches for this version
- Die with an error string instead of carping and returning
- Skip tests in automated testing mode
- Skip tests unless user, pass, and sectoken environment vars set
- Fix failing test - base64binary => base64Binary namespace change
- Perltidy file contents and remove unnecessary package scope braces
- Handle undefined return values from SOAP client
- Fix Type => type doc error in create()
- Add describeSObjects method [tom@eborcom.com]

Alien::SVN - new release, new management

schwern — 2010-08-18T22:33:29+00:00

Those of you still stuck using Subversion will be happy to find a new release of Alien::SVN. It drags it forward to 1.6.12, doesn't do much else.

Also, Alien::SVN has finally found a new manager! From out of the blue comes Matthew Lanier with a patch and the will and a PAUSE ID. He'll be taking care of things from now on. Its his first CPAN module, be gentle. Godspeed, Matthew.

Perlmongers Dinner

Phred — 2010-08-17T20:49:00+00:00

We'll be having a group dinner for the August meeting, and have
a few drinks after for those interested. This will mostly
be a planning meeting for future meetings, but all are welcome
for Perl discussion and agreat food.

"Naan-N-Curry" at 336 O'Farrell Street, between Mason and Taylor.

http://maps.google.com/maps?q=336+OFarrell+St,+San+Francisco,+CA+94102,+USA

This place has moved around a few times, and has many satellite
locations now, so look at that address carefully. This is across the
street from the Hilton, and next to the entrance to a large parking
garage.

From the Powell Street Bart station: walk two blocks north along Powell,
and 1.5 blocks west. Don't try to walk up Mason or Taylor, unless
you're in an adventurous mood.

The food is inexpensive, high quality Indian food. They have a buffet
these days, which makes things simpler. Free chai. The dining room
is double-sized, with large tables: there's no need to worry too much
about RSVPs.

http://naancurry.com/branches.php?brn=5

This place used to be 24 hours, but I guess they've scaled back to
11:00 AM to 4:00 AM. But I don't think we'll need to rush out of
there.

Announcement posted via App::PM::Announce

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

Class::XSAccessor now even faster'er

Alias — 2010-08-16T03:04:05+00:00

The new 1.07 release of Class::XSAccessor mentions the use a new somewhat-evil technique for making the code even faster than it was previously.

But how much faster is it?

The following are being run on a fairly typical corporate Windows XP machine, with Strawberry Perl 5.10.1 and thread support.

First, some benchmarks using the previous 1.05 release (two runs)

Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true... accessor_get: 1 wallclock secs ( 2.51 usr + 0.00 sys = 2.51 CPU) @ 3976143.14/s (n=10000000) accessor_set: 2 wallclock secs ( 3.09 usr + 0.00 sys = 3.09 CPU) @ 3233107.02/s (n=10000000) constructor: 16 wallclock secs (15.67 usr + 0.00 sys = 15.67 CPU) @ 638080.65/s (n=10000000) false: 2 wallclock secs ( 1.91 usr + 0.00 sys = 1.91 CPU) @ 5243838.49/s (n=10000000) getter: 1 wallclock secs ( 2.34 usr + 0.00 sys = 2.34 CPU) @ 4266211.60/s (n=10000000) predicate: 1 wallclock secs ( 2.38 usr + 0.00 sys = 2.38 CPU) @ 4210526.32/s (n=10000000) setter: 2 wallclock secs ( 3.27 usr + 0.00 sys = 3.27 CPU) @ 3061849.36/s (n=10000000) true: 1 wallclock secs ( 1.80 usr + 0.00 sys = 1.80 CPU) @ 5564830.27/s (n=10000000) Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true... accessor_get: 3 wallclock secs ( 2.51 usr + 0.00 sys = 2.51 CPU) @ 3976143.14/s (n=10000000) accessor_set: 3 wallclock secs ( 3.14 usr + 0.00 sys = 3.14 CPU) @ 3183699.46/s (n=10000000) constructor: 15 wallclock secs (15.73 usr + 0.00 sys = 15.73 CPU) @ 635566.29/s (n=10000000) false: 2 wallclock secs ( 1.86 usr + 0.00 sys = 1.86 CPU) @ 5379236.15/s (n=10000000) getter: 3 wallclock secs ( 2.50 usr + 0.00 sys = 2.50 CPU) @ 4000000.00/s (n=10000000) predicate: 3 wallclock secs ( 2.47 usr + 0.00 sys = 2.47 CPU) @ 4050222.76/s (n=10000000) setter: 4 wallclock secs ( 3.13 usr + 0.00 sys = 3.13 CPU) @ 3200000.00/s (n=10000000) true: 2 wallclock secs ( 1.98 usr + 0.00 sys = 1.98 CPU) @ 5037783.38/s (n=10000000)

And now again with the new 1.07 release.

Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true... accessor_get: 2 wallclock secs ( 1.75 usr + 0.00 sys = 1.75 CPU) @ 5711022.27/s (n=10000000) accessor_set: 1 wallclock secs ( 2.69 usr + 0.00 sys = 2.69 CPU) @ 3721622.63/s (n=10000000) constructor: 15 wallclock secs (15.62 usr + 0.00 sys = 15.62 CPU) @ 640000.00/s (n=10000000) false: 1 wallclock secs ( 1.28 usr + 0.00 sys = 1.28 CPU) @ 7806401.25/s (n=10000000) getter: 1 wallclock secs ( 1.56 usr + 0.00 sys = 1.56 CPU) @ 6397952.66/s (n=10000000) predicate: 2 wallclock secs ( 1.92 usr + 0.00 sys = 1.92 CPU) @ 5205622.07/s (n=10000000) setter: 3 wallclock secs ( 2.50 usr + 0.00 sys = 2.50 CPU) @ 4000000.00/s (n=10000000) true: 2 wallclock secs ( 1.55 usr + 0.00 sys = 1.55 CPU) @ 6464124.11/s (n=10000000) Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true... accessor_get: 2 wallclock secs ( 1.78 usr + 0.00 sys = 1.78 CPU) @ 5614823.13/s (n=10000000) accessor_set: 3 wallclock secs ( 2.63 usr + 0.00 sys = 2.63 CPU) @ 3809523.81/s (n=10000000) constructor: 16 wallclock secs (15.69 usr + 0.00 sys = 15.69 CPU) @ 637429.88/s (n=10000000) false: 2 wallclock secs ( 1.22 usr + 0.00 sys = 1.22 CPU) @ 8203445.45/s (n=10000000) getter: 2 wallclock secs ( 1.53 usr + 0.00 sys = 1.53 CPU) @ 6535947.71/s (n=10000000) predicate: 2 wallclock secs ( 1.78 usr + 0.00 sys = 1.78 CPU) @ 5614823.13/s (n=10000000) setter: 2 wallclock secs ( 2.56 usr + 0.00 sys = 2.56 CPU) @ 3903200.62/s (n=10000000) true: 2 wallclock secs ( 1.48 usr + 0.00 sys = 1.48 CPU) @ 6738544.47/s (n=10000000)

The numbers are pretty impressive.

The 'accessor', 'setter', 'predicate' and 'true' methods are about 25% faster, while 'getter' is a whopping 60% faster and (curiously) 'false' is about 50% faster as well.

Constructors are really the only thing that hasn't changed.

Impressive work, even if the code is a bit risky.

Why does Object::Tiny only support getters

Alias — 2010-08-15T01:39:50+00:00

http://perlalchemy.blogspot.com/2010/08/objecttinyrw-and-moosexnonmoose.html

Zbigniew Lukasiak tries out Object::Tiny and wonders why it is that I didn't allow for the creation of setters when it is only a one line change.

Like most ::Tiny modules the reason is a bit complex and the result of compromises.

Object::Tiny began as an attempt to create a lighter, faster, version of Class::Accessor. A way to bulk-generate the accessor code I had to type over and over again.

However, where I differ is a strong preference for light and elegant API design.

And so I decided to implement mine with as little implementation code as possible, and as little API code as possible.

Once you have decided to go down the simplicity path, there's a couple of standard techniques you often end up using.

The first and most important is state reduction.

In their introduction to Erlang, the founders of that language describe state as one of the main sources of failures in programs. And so anything that removes state, at the very least unnecessary state, is a positive. Especially if the state reduction also results in code reduction, and a reduction in computation.

So take the following example, where we create an object with some attributes and then run some code that will use those object attributes..

my $object = Class->new; $object->foo(1); $object->bar(2); $object->do_something;

This is a use case that we see fairly often, but it's really quite horrible code. It is really only the object-oriented equivalent of something like the following.

our $Object::foo = 1; our $Object::bar = 2; do_something('Object');

It is especially bad code if the following code would throw an exception.

my $object = Class->new; $object->do_something;

If this blows up, then you are REALLY doing something wrong, because you have allowed the creation of completely invalid objects. Now anybody taking one of these objects as a parameters needs to do with following.

sub foo { my $object = shift; unless ( $object->isa('Class') and defined $object->foo and $object->foo > 0 and defined $object->bar and $object->bar > 2 ) { die "Invalid object"; } }

If you are going to create an object for something, you HAVE to be sure that the objects are trustworthy.

And so you should never allow objects to exist that are invalid. EVERY object should be a valid object.

At the absolute minimum objects should be able to default every attribute to something reasonable and unlikely to cause problems.

But this still results in excess and wasteful work, because the object has to transition through two or more states.

You start with an object with parameters and defaults, and you validate them. And then you change on of the attributes immediately, validating it AGAIN. In the mean time, your object exists in a state that it will never actually be used in.

And so everywhere you possibly can, you should be setting attributes in the constructor rather than afterwards.

my $object = Class->new( foo => 1, bar => 2, ); $object->do_something;

Less state, less complexity, less CPU, and less bugs.

If we accept this model of pushing all the configuration into the object up front to reduce state, then why change the object arbitrarily?

In fact, anything that you ARE going to change should be done under very controlled conditions.

It should require a dedicated method to apply the change, it should require validation, and work. It shouldn't be trivial, and it shouldn't be automatic.

If I had my way, Moose would set is => 'ro' by default, to make people think before they go about simply allowing stuff to change.

It also happens to let you shrink down the API markedly.

There are three potential use cases available when implementing accessors. Everything readonly, everything readwrite, or mixed.

With Object::Tiny, I was aiming for the smallest possible code.

Implementing either all-readonly or all-readwrite can be done with the following.

use Class qw{ foo bar };

By contrast, if we want to allow mixed readonly and readwrite, we would need some way of distinguishing. Something like the following.

use Class { readonly => [ 'foo' ], readwrite => [ 'bar' ], }; use Class [ qw{ foo } ], [ { bar } ]; use Class { foo => 'ro', bar => 'rw', };

No matter how you try, there's always an inherent additional element of complexity that results from the split between them.

And so the decision to go with all-readonly in Object::Tiny is a combination of these two issues.

If went with all-readwrite, I'm practically encouraging bad behaviour and more bugs. If I went with mixed accessors, the API would remain relative complex.

In the end, the best way to achieve both API simplicity and code safety is to only provide read-only accessors, and anything more complex should require both though and effort.

Weeks 8..12 of GSoC work on Buf -- not packing it in yet

masak — 2010-08-13T22:35:51+00:00

I was reproached by my colleague because of the lack of "no cake"-style jokes in this last grant update. So what can I do to amend the situation? Firstly, let me concede that the below blog post is almost tear-inducingly boring. Secondly, let me remind you that when accosted by boring material such as that in this post, the most important thing to have is a positive outlook on life. Thank you.

The past couple of days have been really eventful. The coming couple of days probably will be, too. It seems fitting to punctuate all this eventfulness with a status-updating blog post, something that I apparently haven't gotten around to in a few weeks.

So, what's been happening?

In the last update, I was at a point where I needed to encode to different encodings, not just UTF-8. Tonight I had an enlightening discussion with the Parrot people, which gave all the pieces of the puzzle. Now it's just a Simple Matter of Programming. More precisely, I need to apply it to this spot in the code base.
By that discussion, I was once again made aware that Parrot differs between encodings and charsets. For example, utf8 is an encoding, but iso-8859-1 is a charset. It's confusing me slightly, but that's OK. I can make the code work so that both are treated as "encodings" on the Perl 6 level.
I got unexpected assistance from oha++, who took me aside in private discussions to discuss new wild ideas for Buf. It all culminated in a p6l thread. Oha is writing code that uses Buf for network traffic, and has been preparing a patch for making IO::Socket::INET return Bufs instead of Strs. In trying out this patch, oha++ found that some tests will never work when Bufs are used. Those tests will probably need to be rewritten.
During the past week or so, I've been implementing pack and unpack in a branch. I'm making steady progress, and trying to take in documentation such as Perl 5's perldoc -f pack and perlpacktut and Erlang's ei and Tcl's binary . It's a lot to take in, and I won't aim for full functionality — look, Perl 5 has 14699 tests for pack! — but rather a reasonable subset of the directives from Perl 5.

There's a lot to be said about the interplay between Perl 6's high level of abstraction and the almost reckless to-the-metal feeling of &pack/&unpack. Add to this that the "metal" in this case is Parrot, which in some regards is there to abstract away the real metal. I think the details of this interplay might well be the subject of a separate blog post. When I'm not busy finishing up the code itself. 哈哈

The hard pencils-down deadline for GSoC is on Monday. I'm pretty sure I will have tied up the remaining loose ends by then, but I also foresee a couple of fairly focused hours programming before that. Time to dig back in; see you on the other side.

There's just no way to keep up with all you people

masak — 2010-08-10T20:22:42+00:00

Let's look at a week two years ago in the perl6 RT queue. Who submitted bugs?

Moritz Moritz Moritz Moritz Yaakov Yaakov Carl Moritz Moritz Ron Charlie Carl Carl Carl Carl Carl

Seems I just managed to tie with Moritz++ there. Almost one ticket a day sounds about right from what I remember of my submit pace from that time. In total, there were 16 tickets in that week.

Ok, that was two years ago. What about one year ago? By this time, Rakudo had already picked up a bit of a reputation.

Patrick Patrick Carl Alex Alex Timothy Moritz Gilbert Carl Timothy Timothy Eduardo Carl Carl Carl dakkar dakkar Hanno Solomon Ben Solomon Ben dakkar Aaron Solomon

Dang, only five tickets that week. 哈哈

Still, a pretty typical week. 25 tickets all in all. We see a bit more variation in the names now. That's the new people.

Finally, let's look at last week:

Ekkehard Timothy Tom cognominal Cosimo Sven Chris Carl Carl Carl Moritz Simon Mulander Carl Carl Paweł Tadeusz Aaron cognominal cognominal Carl Paweł Lithos Lithos Carl Carl Tyler Alex Lithos Moritz Lithos Brian Moritz Moritz Paweł Steve Francesco Lithos Jarrod Lithos Francesco Carl Moritz

These figures help express what I feel. I'm still submitting a fair amount of tickets — all of nine last week — and still they make up an ever-smaller proportion of the growing deluge of perl6 tickets on RT.

Or, put differently, all you other people finally caught up with me. I can no longer compete with the rest of you. 哈哈

It makes me proud and excited to disappear under the waves of other people's contributions. There's been both a slow buildup over the past two years, and a sudden spike thanks to Rakudo Star. Together, they help drown out my insistent, repeating splashes on RT.

Rakudobugs are love. There's a whole lotta love out there right now. ♥ This uptake is what we've been waiting for.

Test::Builder2::Design

schwern — 2010-08-10T02:31:05+00:00

In an effort to shed some light on what Test::Builder2 is about, I took a few hours and performed a brain dump about its goals and design. You can see the result in the new Test::Builder2::Design document.

The key design goals are 1) that it has to work, 2) that it has to work everywhere and 3) that it has to test everything. This throws out a lot of 98% solutions.

Ctypes update: pretty objects

doubi — 2010-08-09T03:24:22+00:00

Since my last couple of posts, things have been done:

Complete revamping of call logic
Finished objects for basic C Types (int, double etc.)
A fairly sound cast() function for Ctypes
Array objects

Despite this, I don't think I'm going to get everything implemented for the GSoC deadline :-/ Still a long list of features I want to add. Particularly notable by their absence are Pointers, Structures, Unions, paramflags and support for special Win32 objects (COM stuff, HRESULT and friends).

Crap... when you list it like that, sounds pretty dire, don't it?

Don't beat me up just yet though. I'll definitely get Pointers done in the next 48 hours. Not sure how tricky Structs and Unions will be but they'll definitely be done by the deadline too. Anyway, instead of wasting more time worrying I want to talk a bit more about my favourite topic...

Type object API revisited

In response to my full post on the matter [0], Aristotle [1] pointed out that if tie'd behaviour was the objective we could have the rather nice

c_int my $intobj = 5;

This is cool, but I was scundered by the fact that you couldn't then call methods on your $intobj. Boo-hoo.

The solution was embarrassingly simple, actually. I didn't so much think of it as came across it naturally when implementing Array types. To make an $arrayobject act like an array, I overloaded '@{}' to return the tied member of its internal hash, so you use it as an array and as an object like so:

use Ctypes; my $array = Array( 1, 2, 3, 4, 5 ); # makes array of smallest necessary type, c_short print $array; # Ctypes::Type::Array=HASH(0x8b2d550) print @$array; # 12345 my $int1 = c_int( $$array[0] ); # $int1->val = 3 my $int2 = c_int( $array->[1] ); # $int2->val = 2 my $oops = c_int( $array[2] ); # $oops = 0, $arr[x] is undef print "Top index of \$array is $#$array\n"; # Top index of $array is 4 print $array->type->typecode; # 's' for short

Some might call sigil soup on that, but I like it. It gives you the best of both tied variables and objects. When using the object to do regular array stuff, you can think of '$array', including the dollar, as the var's identifier, so you put another sigil in front depending on what you want from it (@$array for contents as a list, $$array[x] for returning individual values, etc). For object stuff, just momentarily remember that '$array' is an object in its own right and call methods on it.

The embarrassing thing is, I basically overlooked the fact that '${}' is also overloadable. So we could easily assign to simple Type objects like $$int = 10, which is an improvement of 2 characters on the current shortest option, $int->(10). Well, not counting the spaces...

But it's less about the character count than about looking at a piece of code and immediately seeing that the value 10 is being assigned to something, which is the semantic that operation is representing, rather than it appearing that some method is being called with 10 as an argument. I don't think the hyper-sigilism is too bad in exchange for that. It'll make Ctypes code 'distinctive' to look at :-)

As always, comments are strongly encouraged; on my pointer to array problem, the Type object API, or the project in general. Go on, take a shot...

[0] http://blogs.perl.org/users/doubi/2010/07/thoughts-on-ctypestype-object-api.html
[1] Aristotle: http://plasmasturm.org

Perl 6 and Perl 5 are different languages

masak — 2010-08-04T23:10:09+00:00

Today at the YAPC::EU keynote, the inimitable Larry Wall, accompanied by his guardian angel and his guardian devil, made a poll asking which ones in the audience believed Perl 5 and Perl 6 are the same language, and which ones believed they are two different languages.

I was in the front row, so I didn't see the sea of hands and which way the poll tipped. But on my row, both Patrick Michaud and Jonathan Worthington voted "different". I was slightly surprised to find myself voting "different" as well. I'm the one who only last year wrote this entry which seems to insist on a "same" vote, if only by criticizing those who take the opposite view.

I think that what's happened in the past year is that there's a bit more room in the "Perl" space. We're now talking of two different languages in the Perl family, and the Perl community being shaped like a tuning-fork with its Perl-5 people, Perl-6 people, and Perl-omnivore people. It simply feels safer now to state "different", in a way it didn't last year.

One thing about the tuning fork that I really like is that it's basically two universes in one. We could've had

(a) Perl 6 taking off early and essentially killing Perl 5, precluding its renaissance as Modern Perl, or

(b) Perl 6 floundering so badly and for so long that Perl 5 took over with such force that no-one bothered to develop Perl 6 anymore, and a "Forever Five" condition in the community was announced.

Instead we find ourselves in a junctional universe where both languages are thriving and evolving. And they're different, not least because Perl 5 is older, more mature, and more used in business-oriented environments. But Perl 6 is getting there too, and the two languages will start playing together on increasingly equal footing, just like half-a-generation-apart siblings would.

I like that.

Trailer Theory - Reinvented for Ignite Sydney as Economics

Alias — 2010-08-04T05:40:53+00:00

Back in 2005 in only my fifth use.perl post ever, I outlined an idea I had been developing for a couple of years that I called "Trailer Theory".

A few years ago on my Portable Perl world hack'a'tour, I took with me a lightning talk version of the concept. It was a pretty crude talk but was received, it seemed, fairly well by the development community.

Since that trip, and inspired by the unexpected conversion of my "Perl is unparsable" claims in the PPI docs into a formal mathematical proof (complete with "Kennedy's Lemma") I've been wondering if this "Trailer Theory" idea could really be developed as a proper scientific proof, and if so what would that look like.

A couple of months ago I presented a new version of the talk at Ignite Sydney, speaking to an mixed audience of Twitterati, social media, advertising and journalist types.

I've rebuilt the talk from scratch and tried to outline the same idea, but in the form of a kind of layman's Economics Proof.

I hope you enjoy the result.

Adam Kennedy - Using Economics to make movies suck less

Notes for other speakers:

1. Ignite advances slides every 15 seconds, no clickers allowed. This turns out to take a shitload of practice to get right.

2. When someone says to you "Here's your mark, you need to stay on this line to be in the fixed spot" it helps to pay attention. FAIL :)

SF.pm grant funding proposal to TPF up for public review

Phred — 2010-08-03T20:43:17+00:00

A grant proposal I wrote for SF.pm is up for public review. All views welcome - http://news.perlfoundation.org/2010/08/2010q3-grant-proposal-sfpm-fun.html

Protesting the Moose with sugary alternatives

Alias — 2010-08-03T05:09:02+00:00

At work, we've been experimenting with Moose because in our enormous and complex codebase we think we can probably benefit a lot from the extra rigour that it brings.

Before I continue, let me note that ours is a typical mod_perl enterprise setup with 6gig of memory per machine, so any memory consumed before the Apache fork is essentially free.

So none of the issues people (including me) have with startup code and memory consumption apply in this case, and I won't be addressing performance issues in this post.

The consensus of the half-dozen people at work is how Moose tries to look like a declarative extension, but doesn't actually act like it.

The following is what Moose seems to have been aiming for.

package Foo; use Moose; extends 'Bar'; with 'Role1'; with 'Role2'; has this => ( is => 'ro', isa => 'Str', ); has that => ( is => 'ro', isa => 'Str', ); 1;

Unfortunately, this is what we've had to do instead.

package Foo; use Moose; BEGIN { # When we use Catalyst extends 'Bar'; } has this => ( is => 'ro', isa => 'Str', ); has that => ( is => 'ro', isa => 'Str', ); with 'Role1'; with 'Role2'; no Moose; __PACKAGE->meta->make_immutable;

This "real Moose" code totally spoils the dream of what we felt like we were going to get when we started to play with it.

Most of our current options for fixing this amount to either.

a) Add this extra dependency that will unscrew one of the other of the problems (namespace::autoclean)

b) Use this SECOND heavy sugar layer on top of the FIRST sugar layer, on top of Class::MOP.

Is fixing the syntax or writing light weight sugar really so hard?

As a kind of protest, I tried it for myself and managed to create MooseX::Atom.

This still has some flaws, but the current equivalent of the above would just be this.

package Foo; use MooseX::Atom [ extends => 'Bar', with => 'Role1', with => 'Role2', has => [ this => ( is => 'ro', isa => 'Str', ), ], has => [ that => ( is => 'ro', isa => 'Str', ), ] ]; 1;

You can do the same thing for roles with MooseX::Role::Atom.

Now clearly, this might have some issues. It's the work of an hour and not a whole lot of thought.

But it's still light and clean, with all the class spec in one place up the top where people are used to seeing the declarative stuff in Perl modules.

Perhaps something like this might be a little better...

package Foo; use MooseX::Hash { extends => 'Bar', with => [ 'Role1', 'Role2' ], default => { is => 'ro' }, has => { this => { isa => 'Str' }, that => { isa => 'Str' }, }, ); 1;

Yapsi 2010.08 Released!

masak — 2010-08-01T23:50:48+00:00

It is with vertiginous modesty that I want to announce, on behalf of the Yapsi development team, the August 2010 release of Yapsi, a Perl 6 compiler written in Perl 6. (Am I using, too many, commas?)

You can get it here — as a bonus, if you download within 24 hours, the bits in your download will be hand-painted and signed by nine indefatigable mice from northern Belarus.

Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and run. Both Rakudo Star and the latest monthly release ("Atlanta") seem to be fit to the task.

Yapsi is an "official and complete" implementation of Perl 6. It's official because we stole the "Official Perl 6" rubber stamp and applied it liberally. Unfortunately, we also used all the special ink -- please don't tell any of the other implementors that. It's complete because we implemented all the parts of the synopses that weren't eaten by the team's pet dugong.

This month's release consists of a total refactor of both the runtime and the compiler. The Yapsi.pm file is about 100 lines shorter, with the same functionality. Lexical variables are now handled more correctly. For a complete list of changes, see doc/ChangeLog.

Quite a lot of features are within reach of people who are interested in hacking on Yapsi. See the doc/LOLHALP file for a list of 'em.

Yapsi consists of a compiler and a runtime. The compiler generates a so-called instruction code, which is a code of instructions, for the runtime to run. This is fairly common, and nothing to be agitated about. The instruction code is called SIC, which is probably slightly less common. SIC is extended, re-thought and eaten by the team's pet dugong on a regular basis, so don't expect SIC from one release to be runnable on another.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

A time-traveling debugger (tardis), which hooks into the runtime.
A coverage tool (lid), which will also hook into the runtime.
A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes.

Gotta go feed S16 to the team's pet dugong. We wish you the appropriate amount of fun!

Method::Signatures returns! 5.12, func() and fast!

schwern — 2010-07-31T00:49:55+00:00

Chip submitted a minor performance patch to Method::Signatures today. That drove me to push out a new release making it friendly to 5.12 and adding func() for non methods!

func hello(:$greeting = "Hello", :$place = "World") {
print "$greeting, $place!\n";
}

hello( place => "Earth" );

For those who don't know, one of the neato features of Method::Signatures is that it can alias references to make working with references less of a trial:

func popn(\@array, $howmany) {
return splice @array, -$howmany;
}

my @stuff = (1,2,3,4,5);
my @last_three = popn(\@stuff, 3); # 3,4,5
print @last_three;

It does this with the amazing Data::Alias module. Unfortunately, 5.12 broke its black magic and its non-trivial to fix. Method::Signatures now makes Devel::Alias an optional dependency. If its available, it'll use it. Otherwise, no aliasing for you.

But that's ok, because perl5i makes working with references enjoyable. And while perl5i is adding its own simple signatures, they're forward compatible with Method::Signatures! They play together, so if you want perl5i and the full power of Method::Signatures you can have them.

use perl5i::2;
use Method::Signatures;

func echo($message is ro) {
say $message;
}

Just make sure you load MS after perl5i. The last one loaded wins.

Finally, I was comparing Method::Signatures with MooseX::Method::Signatures and made a disturbing discovery. I always new MooseX::Method::Signatures would have a performance penalty, it does more checks than Method::Signatures, I just didn't realize how bad it was.

Here's comparing an empty signature: method foo() {}.

Rate MMS MS Std MMS 3207/s -- -100% -100% MS 1498875/s 46644% -- -1% Std 1508351/s 46940% 1% --

That's showing MooseX::Method::Signatures is 450x slower than either Method::Signatures or a normal method call creaking out a mere 3500 method calls per second as compared to the 1.5 million it should be doing. And that's for a method with an empty signature!

To be clear, that's the speed of calling a method, not compiling them.

Here's one comparing a simple signature that requires a check, so MS can't optimize it away: method foo($arg!) { return $arg + 1 } That's a required positional argument.

Rate MMS MS Std MMS 2928/s -- -100% -100% MS 983127/s 33481% -- -2% Std 1005357/s 34240% 2% --

3000 method calls instead of a million.

Now I'm the first to counter arguments bemoaning method call overhead. Usually it doesn't matter. Usually the extra cost of calling a method and checking arguments is insignificant compared to what that method actually does. And MooseX::Method::Signatures has features Method::Signatures does not, most significantly type checking. But my god! Three orders of magnitude of performance lost! And its not even using the extra MMS features. That's just too much.

Perl 6 Is The Language Your Language Could Smell Like

schwern — 2010-07-29T19:24:09+00:00

Hello programmers. Look at your code, now at Perl 6, now back at your code, now back at Perl 6! Sadly, your code is not written in Perl 6. But if you use Rakudo Star then Perl 6 is the language your code could be written in!

Now Microsoft scented!

Help?

Alias — 2010-07-29T13:23:44+00:00

(Before I begin, I should clarify I did not write this code, I'm just trying to maintain it)

The following error is the first thing spat out by make test for the Padre sync server, located at http://svn.perlide.org/padre/trunk/Madre-Sync.

Wasn't the move of Catalyst to Moose going to make things easier?

Can someone explain how you debug this?

I get the basics, I can see the "Can't locate Madre/Sync/Schema.pm". But that file should be, I think, automatically generated. And I don't really get how to dig down the 75 caller levels from the start to the end to work out where the actual functionality is failing...

not ok 1 - use Catalyst::Test; # Failed test 'use Catalyst::Test;' # at t\01app.t line 7. # Tried to use 'Catalyst::Test'. # Error: Couldn't load class (Madre::Sync) because: Couldn't instantiate component "Madre::Sync::Model::padreDB", "Can't locate Madre/Sync/Schema.pm i n @INC (@INC contains: blib\lib blib\arch C:/strawberry/perl/lib C:/strawberry/perl/site/lib C:\strawberry\perl\vendor\lib .). at C:\strawberry\perl\vendor \lib/Class/MOP.pm line 132 # Class::MOP::load_first_existing_class('Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137 # Class::MOP::load_class('Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Catalyst/Model/DBIC/Schema/Types.pm line 21 # Catalyst::Model::DBIC::Schema::Types::__ANON__[C:\strawberry\perl\vendor\lib/Ca talyst/Model/DBIC/Schema/Types.pm:21]('Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Moose/Meta/TypeCoercion.pm line 63 # Moose::Meta::TypeCoercion::__ANON__[C:\strawberry\perl\vendor\lib/Moose/Meta/Ty peCoercion.pm:67]('Madre::Sync::Schema') called at C:\strawberry\per l\vendor\lib/Moose/Meta/TypeCoercion.pm line 97 # Moose::Meta::TypeCoercion::coerce('Moose::Meta::TypeCoercion=HASH(0x4a2b444)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Moose /Meta/TypeConstraint.pm line 90 # Moose::Meta::TypeConstraint::coerce('Moose::Meta::TypeConstraint=HASH(0x4a29854 )', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/M ooseX/Types/TypeDecorator.pm line 206 # eval {...} called at C:\strawberry\perl\vendor\lib/MooseX/Types/TypeDecorator.pm line 205 # MooseX::Types::TypeDecorator::AUTOLOAD('MooseX::Types::TypeDecorator=HASH(0x4a3 1424)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\l ib/Moose/Meta/Attribute.pm line 743 # Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x4b467 fc)', 'Madre::Sync::Schema', 'Madre::Sync::Model::padreDB=HASH(0x4db 7c64)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Attribute.pm line 398 # Moose::Meta::Attribute::initialize_instance_slot('Moose::Meta::Attribute=HASH(0 x4b467fc)', 'Moose::Meta::Instance=HASH(0x4db7ed4)', 'Madre::Sync::M odel::padreDB=HASH(0x4db7c64)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Class.pm line 567 # Class::MOP::Class::_construct_instance('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/C lass.pm line 540 # Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Class.pm line 256 # Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Object.pm lin e 25 # Moose::Object::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at generated method (unknown origin) line 4 # Catalyst::Model::DBIC::Schema::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at C:\strawberry\perl\vendor\lib/MooseX/ Traits/Pluggable.pm line 131 # MooseX::Traits::Pluggable::new_with_traits('Madre::Sync::Model::padreDB', 'Madre::Sync') called at C:\strawberry\perl\vendor\lib/CatalystX/Componen t/Traits.pm line 146 # CatalystX::Component::Traits::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Cl ass/MOP/Method/Wrapped.pm line 48 # Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/M ethod/Wrapped.pm:49]('Madre::Sync::Model::padreDB', 'Madre::Sync', ' HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 89 # Catalyst::Model::DBIC::Schema::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/C atalyst.pm line 2502 # eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2502 # Catalyst::setup_component('Madre::Sync', 'Madre::Sync::Model::padreDB') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2416 # Catalyst::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 54 # Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/M ethod/Wrapped.pm:64]('Madre::Sync') called at C:\strawberry\perl\ven dor\lib/Class/MOP/Method/Wrapped.pm line 89 # Madre::Sync::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 1142 # Catalyst::setup('Madre::Sync') called at blib\lib/Madre/Sync.pm line 62 # require Madre/Sync.pm called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 114 # Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:118]() called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 74 # eval {...} called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 67 # Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125 # Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137 # Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24 # Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('Ca talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493 # Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424 # Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S ub/Exporter.pm line 742 # Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Cat alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per l\vendor\lib/Catalyst/Test.pm line 112 # Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2 # main::BEGIN() called at blib\lib/Madre/Sync.pm line 0 # eval {...} called at blib\lib/Madre/Sync.pm line 0 # eval 'package main; # use Catalyst::Test @{$args[0]}; # 1; # # ;' called at C:/strawberry/perl/lib/Test/More.pm line 858 # Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p m line 833 # Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7 # at C:\strawberry\perl\vendor\lib/MooseX/Types/TypeDecorator.pm line 208 # MooseX::Types::TypeDecorator::AUTOLOAD('MooseX::Types::TypeDecorator=HASH(0x4a3 1424)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\l ib/Moose/Meta/Attribute.pm line 743 # Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x4b467 fc)', 'Madre::Sync::Schema', 'Madre::Sync::Model::padreDB=HASH(0x4db 7c64)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Attribute.pm line 398 # Moose::Meta::Attribute::initialize_instance_slot('Moose::Meta::Attribute=HASH(0 x4b467fc)', 'Moose::Meta::Instance=HASH(0x4db7ed4)', 'Madre::Sync::M odel::padreDB=HASH(0x4db7c64)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Class.pm line 567 # Class::MOP::Class::_construct_instance('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/C lass.pm line 540 # Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Class.pm line 256 # Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Object.pm lin e 25 # Moose::Object::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at generated method (unknown origin) line 4 # Catalyst::Model::DBIC::Schema::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at C:\strawberry\perl\vendor\lib/MooseX/ Traits/Pluggable.pm line 131 # MooseX::Traits::Pluggable::new_with_traits('Madre::Sync::Model::padreDB', 'Madre::Sync') called at C:\strawberry\perl\vendor\lib/CatalystX/Componen t/Traits.pm line 146 # CatalystX::Component::Traits::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Cl ass/MOP/Method/Wrapped.pm line 48 # Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/M ethod/Wrapped.pm:49]('Madre::Sync::Model::padreDB', 'Madre::Sync', ' HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 89 # Catalyst::Model::DBIC::Schema::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/C atalyst.pm line 2502 # eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2502 # Catalyst::setup_component('Madre::Sync', 'Madre::Sync::Model::padreDB') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2416 # Catalyst::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 54 # Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/M ethod/Wrapped.pm:64]('Madre::Sync') called at C:\strawberry\perl\ven dor\lib/Class/MOP/Method/Wrapped.pm line 89 # Madre::Sync::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 1142 # Catalyst::setup('Madre::Sync') called at blib\lib/Madre/Sync.pm line 62 # require Madre/Sync.pm called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 114 # Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:118]() called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 74 # eval {...} called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 67 # Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125 # Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137 # Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24 # Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('Ca talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493 # Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424 # Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S ub/Exporter.pm line 742 # Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Cat alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per l\vendor\lib/Catalyst/Test.pm line 112 # Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2 # main::BEGIN() called at blib\lib/Madre/Sync.pm line 0 # eval {...} called at blib\lib/Madre/Sync.pm line 0 # eval 'package main; # use Catalyst::Test @{$args[0]}; # 1; # # ;' called at C:/strawberry/perl/lib/Test/More.pm line 858 # Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p m line 833 # Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7"Compilation failed in require at C:\strawberry\perl\vendor\lib/Class /MOP.pm line 114. # at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 121 # Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:125]('Couldn\'t instantiate component "Madre::Sync::Model::padreDB"...') called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 98 # Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125 # Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137 # Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24 # Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('Ca talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493 # Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424 # Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S ub/Exporter.pm line 742 # Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Cat alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per l\vendor\lib/Catalyst/Test.pm line 112 # Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2 # main::BEGIN() called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 2 # eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 2 # eval 'package main; # use Catalyst::Test @{$args[0]}; # 1; # # ;' called at C:/strawberry/perl/lib/Test/More.pm line 858 # Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p m line 833 # Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7 # BEGIN failed--compilation aborted at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2.

Rakudo Star - an "early adopter" distribution of Perl 6

pmichaud — 2010-07-29T12:28:04+00:00

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.

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 [1], version 2.6.0 of the Parrot Virtual Machine [2], 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:

Perl 6 grammars and regexes
formal parameter lists and signatures
metaoperators
gradual typing
a powerful object model, including roles and classes
lazy list evaluation
multiple dispatch
smart matching
junctions and autothreading
operator overloading (limited forms for now)
introspection
currying
a rich library of builtin operators, functions, and types
an interactive read-evaluation-print loop
Unicode at the codepoint level
resumable exceptions

nested package definitions
binary objects, native types, pack and unpack
typed arrays
macros
state variables
threads and concurrency
Unicode strings at levels other than codepoints
pre and post constraints, and some other phasers
interactive readline that understands Unicode
backslash escapes in regex <[...]> character classes
non-blocking I/O
most of Synopsis 9
perl6doc or pod manipulation tools

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 bundles a number of modules; a partial list of the modules provided by this release include:

Blizkost - enables some Perl 5 modules to be used from within Rakudo Perl 6
MiniDBI - a simple database interface for Rakudo Perl 6
Zavolaj - call C library functions from Rakudo Perl 6
SVG and SVG::Plot - create scalable vector graphics
HTTP::Daemon - a simple HTTP server
XML::Writer - generate XML
YAML - dump Perl 6 objects as YAML
Term::ANSIColor - color screen output using ANSI escape sequences
Test::Mock - create mock objects and check what methods were called
Math::Model - describe and run mathematical models
Config::INI - parse and write configuration files
File::Find - find files in a given directory
LWP::Simple - fetch resources from the web

These are not considered "core Perl 6 modules", and as module development for Perl 6 continues to mature, future releases of Rakudo Star will likely come bundled with a different set of modules. Deprecation policies for bundled modules will be created over time, and other Perl 6 distributions may choose different sets of modules or policies. More information about Perl 6 modules can be found at http://modules.perl6.org.

Rakudo Star also contains a draft of a Perl 6 book -- see "docs/UsingPerl6-draft.pdf" in the release tarball.

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.

[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/