pmichaud's Journal pmichaud's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T01:45:49+00:00 pudge Technology hourly 1 1970-01-01T00:00+00:00 pmichaud's Journal Rakudo Star 2010.08 released <p>[This announcement was made last week on -- I'm reposting to so it will show up in the various Perl aggregators. --Pm]</p><p>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 <a href=""></a>.</p><p>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.</p><p>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.</p><p>This release of Rakudo Star adds the following features over the previous Star release:<br>* Nil is now undefined<br>* Many regex modifiers are now recognized on the outside of regexes<br>* Mathematic and range operations are now faster (they're still slow, but they're significantly faster than they were in the previous release)<br>* Initial implementations of<nobr> <wbr></nobr>.pack and<nobr> <wbr></nobr>.unpack<br>* MAIN can parse short arguments<br>* Removed a significant memory leak for loops and other repeated blocks</p><p>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.</p><p>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:<br>* nested package definitions<br>* binary objects, native types, pack and unpack<br>* typed arrays<br>* macros<br>* state variables<br>* threads and concurrency<br>* Unicode strings at levels other than codepoints<br>* pre and post constraints, and some other phasers<br>* interactive readline that understands Unicode<br>* backslash escapes in regex character classes<br>* non-blocking I/O<br>* most of Synopsis 9<br>* perl6doc or pod manipulation tools</p><p>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.</p><p>See <a href=""></a> 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.</p><p>The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see <a href=""></a>, ask on the mailing list, or join us on IRC channel #perl6 on freenode.</p><p>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.</p><p>[1] <a href=""></a><br>[2] <a href=""></a></p> pmichaud 2010-09-01T12:36:56+00:00 perl6 Rakudo Star - an "early adopter" distribution of Perl 6 <p>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 <a href=""></a>.</p><p>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.</p><p>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.</p><p>Some of the many cool Perl 6 features that are available in this release of Rakudo Star:</p><ul> <li>Perl 6 grammars and regexes</li><li>formal parameter lists and signatures</li><li>metaoperators</li><li>gradual typing</li><li>a powerful object model, including roles and classes</li><li>lazy list evaluation</li><li>multiple dispatch</li><li>smart matching</li><li>junctions and autothreading</li><li>operator overloading (limited forms for now)</li><li>introspection</li><li>currying</li><li>a rich library of builtin operators, functions, and types</li><li>an interactive read-evaluation-print loop</li><li>Unicode at the codepoint level</li><li>resumable exceptions</li></ul><p>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:</p><ul> <li>nested package definitions</li><li>binary objects, native types, pack and unpack</li><li>typed arrays</li><li>macros</li><li>state variables</li><li>threads and concurrency</li><li>Unicode strings at levels other than codepoints</li><li>pre and post constraints, and some other phasers</li><li>interactive readline that understands Unicode</li><li>backslash escapes in regex &lt;[...]&gt; character classes</li><li>non-blocking I/O</li><li>most of Synopsis 9</li><li>perl6doc or pod manipulation tools</li></ul><p>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.</p><p>See <a href=""></a> for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources.</p><p>Rakudo Star also bundles a number of modules; a partial list of the modules provided by this release include:</p><ul> <li> Blizkost - enables some Perl 5 modules to be used from within Rakudo Perl 6</li><li> MiniDBI - a simple database interface for Rakudo Perl 6</li><li> Zavolaj - call C library functions from Rakudo Perl 6</li><li> SVG and SVG::Plot - create scalable vector graphics</li><li> HTTP::Daemon - a simple HTTP server</li><li> XML::Writer - generate XML</li><li> YAML - dump Perl 6 objects as YAML</li><li> Term::ANSIColor - color screen output using ANSI escape sequences</li><li> Test::Mock - create mock objects and check what methods were called</li><li> Math::Model - describe and run mathematical models</li><li> Config::INI - parse and write configuration files</li><li> File::Find - find files in a given directory</li><li> LWP::Simple - fetch resources from the web</li></ul><p>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 <a href=""></a>.</p><p>Rakudo Star also contains a draft of a Perl 6 book -- see "docs/UsingPerl6-draft.pdf" in the release tarball.</p><p>The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see <a href=""></a>, ask on the mailing list, or join us on IRC #perl6 on freenode.</p><p>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.</p><p>[1] <a href=""></a> <br>[2] <a href=""></a> </p> pmichaud 2010-07-29T12:28:04+00:00 perl6 Rakudo Star (a "usable Perl 6") to be released by July 29 <p>As many of you know, last summer we announced that we would be releasing a "<a href="">usable release of Rakudo Perl 6</a>" to be called "Rakudo Star" in the second quarter of 2010. We later refined our target release date to be April 2010.</p><p>Until March of this year we were well on track to meet the April 2010 release date, but then I had an <a href="">family medical emergency</a> that took me away from Perl 6 development. As a result of my situation, the Rakudo and Perl 6 team met online in early March and decided that an April release date would be unrealistic, and we instead focused our efforts on trying to make a June release for Rakudo Star, to keep with our original "second quarter 2010" goal.</p><p>Ultimately it ended up being twelve weeks before I was able to return to active Perl 6 development (i.e., late May). During my absence the others on the Rakudo and Perl 6 team made incredible progress on Rakudo Perl 6; I think their progress shows that a truly capable (and growing) team of developers has coalesced around Rakudo Perl. Thanks to their efforts, as of late May the compiler had nearly everything we identified as critical for Rakudo Star in the ROADMAP, with only a few key features blocking on my personal participation. We therefore felt we still had a good likelihood of meeting the June 2010 target, and continued to work with that goal in mind.</p><p>As part of planning this week's Parrot and Rakudo releases, we all met online to solidify our plans for the Rakudo Star release. After much discussion, we decided that although we could likely make some sort of Rakudo Star release in June, there was too much risk that releasing in June would fall well short of our vision of what we want Rakudo Star to be.</p><p>Therefore, we've decided to to let the release date slip one more month and release Rakudo Star not later than July 29, 2010. We are firmly committed to the July 29 date; whatever we have available then, that's what we release. I know that another delay will be frustrating to many (it is very frustrating to me), and that some will undoubtedly cite this delay as yet more "evidence" that there will never be a release of Perl 6. But given the circumstances, I think we feel that we promote Perl 6 better by moving the release date by a month than we would by releasing something less than our vision. </p><p>For those who might claim that we should "release early", we <i>are</i> still continuing to make regular monthly compiler releases. The most recent release (<a href="">#30, "Kiev"</a>) comes with a lot of improvements over previous releases, and I truly expect the next release (#31, "Atlanta") to continue the trend. As always, we continue to invite people to try out the compiler releases and to visit the <a href="">Perl 6 website</a> to see what Perl 6 is already doing today.</p><p>Finally, on a personal note, my wife and I sincerely appreciate the ongoing support, prayers, and understanding we have received from the Perl community (and especially the Rakudo and Perl 6 teams) during these difficult times. While my wife is still not "out of the woods" yet, things are far better now than they were in the Spring, and we continue to work towards and pray for her full recovery.</p><p>More details about the Rakudo Star release will be forthcoming over the next couple of weeks.</p><p>Pm</p> pmichaud 2010-06-19T17:04:21+00:00 perl6 More Perl 6 Anti-FUD <p>More Perl 6 Anti-FUD here:</p><p><a href=""></a></p><p><a href=""></a></p><p>and thoughts on the name "Perl 6"</p><p><a href=""></a></p><p>Pm</p> pmichaud 2010-04-23T23:38:22+00:00 journal A wholly inadequate reply to an Anonymous Monk [Reposted from <a href=""></a>. Normally I wouldn't repost but I'd like it to appear in my normal Perl 6 journal and rss feeds as well as on PerlMonks. --Pm] <p>An Anonymous Monk on recently started a discussion on "<a href="">The current state of Perl 6</a>" in which he (she? they?) offers his views on various aspects of Perl 6 development. Personally, I find nearly all of Anonymous Monk's comments in the thread to be so devoid of logic and so far removed from reality/facts that it's hard to imagine providing an adequate reply to them.</p><p>Beyond that, I have other priorities in my life right now. Uppermost is that my family is going through a very difficult period at present -- I need to take care of them first. Rakudo and Perl 6 come in at a somewhat distant second to that. Responding to garbage being spouted by anonymous person(s) probably ought to not even be anywhere on my radar.</p><p>But at least one post in the thread bugs me sufficiently that I'd like to respond, even if it's an inadequate response. And I don't want my response buried in a thread somewhere, so it gets its own post.</p><p>Anonymous Monk <a href="">writes</a>:</p><blockquote><div><p> <em> Oh I'll tell you how you do that &#91;write a grammar engine capable of supporting Perl 6]. It's very simple. You get people skilled for this exact task ! Those skills are acquired in universities(preferably good ones) where professors teach courses like "Formal Languages and Automata" or "Compiler theory". If you have a bunch of people who are open-source contributors but don't have the knowledge or haven't studied the right things<nobr> <wbr></nobr>... <strong>&#91;t]hey don't know it in theory and they're trying to put it in practice! </strong> </em> (emphasis in original)</p></div></blockquote><p>Who does Anonymous Monk think is working on Perl 6? Personally, I have a Ph.D. in Computer Science and taught university language courses for nearly 14 years. Damian Conway certainly also has a fairly strong university background (Monash University) and understands the theory and practice of language and compiler design. Jonathan Worthington has a degree from the University of Cambridge, where he specialized in compiler construction and formal languages. Larry Wall has a degree in Natural and Artificial Languages with two years of graduate work in Linguistics at U.C. Berkeley. Many of our other key contributors also have degrees and backgrounds in language theory and practice. I'd be willing to compare the academic credentials of this group against any other dynamic language team Anonymous Monk might care to postulate.</p><blockquote><div><p> <em>If you can't get <strong>real</strong> compiler people to use Perl6 and help with it, the average open-source rookie won't be able to deal with this.</em></p></div> </blockquote><p>Somehow I have trouble classifying Larry, Damian, Allison, etc. as being "not real compiler people". And they along with many other Perl 6 contributors have a lot of experience in nurturing open source developers and projects. If you feel Larry et al. are indeed unqualified to be working in the field of programming language design and implementation, you probably don't want to be using Perl at all, much less Perl 6.</p><p>People like Anonymous Monk spew lots of opinions about how long they think Perl 6 development should take, and then speculate on the reasons why it has taken longer than they estimate it should be taking. The speculations that crop up most often are things like "the people involved are clueless about language design/implementation" (see above), "the design process itself is flawed", "they're building on an inadequate toolset like Parrot", etc. For such people it's easy to toss out random thoughts about "the problems with Perl 6" without bothering to look at the obvious evidence to the contrary, as Anonymous Monk does above. Indeed, I'm often amused when people suggest that we should be doing things <em> <a href=";cid=70194">that we're already doing</a><nobr> <wbr></nobr></em>.</p><p>Returning to the topic of developing a grammar engine, which Anonymous Monk claims above as "very simple" and just needing "people skilled for this exact task", it's interesting to contrast his opinions with the actual development of the Perl 6 standard grammar (<a href="">STD.pm6</a>). I think STD.pm6 is also indicative of the challenges confronting all Perl 6 implementors. Consider: </p><ul> <li>Larry is the primary implementor for the standard grammar.</li><li> The standard grammar doesn't need a frozen specification to be implemented, because its implementation is considered part of the spec.</li><li>The implementation is built entirely on top of Perl 5 -- there are no "unproven virtual machines" involved or holding things back.</li></ul><p>I think one could consider this to be an almost perfect situation for developing a new language implementation -- an experienced language designer/implementor working without significant external restrictions on top of an advanced programming platform like Perl 5. Yet it's been three years since Larry started working on this implementation of the standard grammar and parser, and while STD.pm6 is very powerful, it's also certainly not "finished", and has been through a number of significant refactors in its development. This says to me that the amount of time and effort involved is more likely due to the sheer audacity and ambition of what Perl 6 seeks to accomplish.</p><p>(Some will undoubtedly look at the above and knee-jerk respond with something like "If it's taken three years just to create the parser, then finishing a compiler will take far longer still and therefore Perl 6 will never see the light of day." This argument ignores the fact that other pieces are being implemented in parallel with Larry's work, that software development is not a strictly sequential process, and the obvious fact that there are already "working" Perl 6 implementations available.)</p><p>Anyone who thinks that Perl 6 is fundamentally based on traditional compiler construction techniques taught in universities frankly has no clue as to what a fundamental paradigm shift Perl 6 represents to language design and implementation. It's this fundamental change that ultimately gives Perl 6 its power, but it's also why Perl 6 development is not a trivial exercise that can be done by a few dedicated undergraduates. As <a href="">TimToady on #perl6 says</a>, "We already have lots of those kinds of languages." </p><p>Personally, I'm impressed and honored to be associated with the people who are working on Rakudo and Perl 6. I understand that people are frustrated (and even feel burned by) the long wait for something as cool as Perl 6; I share the frustration and like to think that I'm doing something constructive about it. But I also find the vast majority of suggestions, comments, and conclusions coming from Perl 6's anonymous detractors to be (1) things we've already done or are doing, (2) ungrounded in reality, (3) in direct contradiction to reasonably observable facts, or (4) attempts to discredit a product they have little interest in ever using themselves. And far too many of the comments, like the ones I've highlighted in this post, are so easily refuted with just a little bit of fact digging and common sense, it's often hard to believe anyone can be seriously making them in the first place. Yet there they are.</p><p>Returning to my original theme, I think my response here is inadequate because it leaves so many other of Anonymous Monk's claims in the thread unrefuted. I could undoubtedly spend many more hours analyzing and responding to the many fallacies and untruths in the thread, but frankly I don't believe that's the best use of my time. People such as Moritz Lenz, chromatic, Michael Schwern, and others are also writing extremely well-reasoned posts refuting the garbage, for which I'm grateful, but it's far easier for Anonymous Monk and his like to spin garbage than it is for a small number of us to clean up after it. And it does need to be cleaned up, otherwise it festers and results in even more public garbage <a href="">that someone has to clean up</a>.</p><p>I hope that this post will at least encourage more people in the Perl community to critically examine the things they hear and read regarding Perl 6, especially when coming from sources with no apparent standing or reputation within the community. And maybe a few more people will even assist in publicly refuting the garbage ("many hands make light work"), so that the sloppy thinking, analysis, and dialogue that people like Anonymous Monk post doesn't spread to infect all of Perl.</p><p>Pm</p><p>P.S.: Some may reasonably conclude from what I've written above that Perl 6 is somehow "aiming too high", that our goals should be scaled back to make something ready "right now". I have two responses to this: (1) we <em>are</em> making things ready 'right now', just grab any of the available packages and start working and reporting bugs, and (2) there are already 'scaled back' versions of Perl 6 appearing and being used, such as NQP or even the components that execute the standard grammar. Some of these other projects, like NQP, are being used for "real" programs and applications today; they're not simply theoretical exercises or research projects.</p><p>Others often claim that all this effort on Perl 6 would be better spent on improving Perl 5. In my experience, those of us working on Perl 6 have absolutely no qualms with seeing Perl 5 improve and continue to grow -- we welcome it. Indeed, many of the features appearing in Perl 5 today come directly from ideas and things first attempted in Perl 6, and we're genuinely happy to see that. But just because Perl 6 developers also like Perl 5 doesn't mean that doing Perl 5 core development is interesting to us, or that (in my case at least) we'd even be qualified to do Perl 5 core changes. We aren't commodity programmers that are interested in simply being unplugged from one project and into some other project that others think is more worthwhile. Personally, I'd prefer to see people who are really into Perl 5 improvements continue to work to make them happen, and that the surrounding ecosystem continue to evolve to enable that to happen more easily for more people. Indeed, this is my wish for all open-source projects, even the ones I don't find interesting or otherwise disagree with.</p> pmichaud 2010-04-22T21:47:27+00:00 perl6 Bad news, revisited <p>For those of you who are wondering where I've been lately with Perl 6 and Rakudo development, here's the story. As many of you know, my wife was diagnosed in early 2008 with ovarian cancer and remission [1,2]. Over the past few weeks various tests have indicated a probable cancer recurrence; and on March 2nd my wife was diagnosed with a small-bowel obstruction requiring immediate hospitalization. Since then nearly all of my time and energy has been essentially dedicated to caring for her and her needs. As of this writing (Mar 16) we're still in the hospital and hope she will be able to return home in the next couple of days.</p><p>The most obvious question relating to Rakudo development is "How does this affect scheduling of the Rakudo Star release in April?" Unfortunately, I don't have a good answer for this at the moment, as I don't yet have a firm date of when her recovery might be sufficiently far along that I can devote significant time again to Perl 6. I could be available again in just a few days, or it could take many weeks.</p><p>For now I've asked the core Rakudo and Perl 6 developers to work out what they think will be the best course of action for Rakudo Star given my current situation. As far as I'm concerned, all options are on the table (e.g., delaying the release a bit), but I think that whatever is decided needs to be a consensus among the entire development team. I suspect we will collectively announce an updated plan sometime in the next few days.</p><p>As I did in 2008, I'll tend to limit any further public posts about the current medical situation to major developments. But if anyone has any questions, I'll be glad to answer them.</p><p>As always, my wife and I send our thanks to everyone for your prayers, support, and understanding.</p><p>Pm</p><p>1.<br>2.</p> pmichaud 2010-03-17T04:32:16+00:00 journal Hague grant status report, milestones M1/M2 <p>Below is the milestone status report I submitted for my Hague Grant; the original grant description is at .</p><p>----------</p><p>Rakudo Perl and PCT improvements<br>Hague grant status report, milestones M1/M2</p><p>This is a milestone report for the "Rakudo Perl and PCT improvements"<br>Hague Grant. Rakudo Perl [1] is a Perl 6 [2] implementation built on top<br>of the Parrot Virtual Machine [3].</p><p>The overall purpose of this grant is to design and implement the<br>components needed to align Rakudo Perl's parsing parsing more closely<br>with the current Perl 6 specification and to increase the level of<br>Perl 6 code used to implement the compiler itself.</p><p>This report focuses on the completion of the deliverables needed<br>for milestones M1 and M2 in the grant description [4], and marks<br>the "halfway" checkpoint for the grant. Originally this checkpoint<br>was expected to be reached in early 2009, but significant changes<br>to Parrot, Rakudo, and Perl 6 in the months shortly after this<br>grant was awarded delayed progress on some M1 and M2 items until<br>later in 2009. However, progress on many other items in the<br>grant were on time or accelerated, such that even though this<br>is officially the "halfway" checkpoint report, in reality almost<br>all grant deliverables are completed, and the "final" report<br>for this grant can be expected in December 2009.</p><p>A significant event during this grant period has been the planning<br>and announcement of "Rakudo Star", a "usable and useful Perl 6 release"<br>to occur in April 2010 [5]. Rakudo Star is not intended to be a<br>complete implementation of Perl 6, but rather to be an official<br>"interim" release that provides sufficient features to be a viable<br>platform for consideration by application developers. Much of the<br>overall Rakudo project effort, including work to be performed<br>under this grant and other Hague grants, has been prioritized<br>and focused on ensuring the successful release of Rakudo Star<br>in April 2010. Indeed, nearly half of the "critical must-have"<br>features identified in the Rakudo Star ROADMAP [6] depend on<br>the deliverables from this grant; the current state of<br>progress described by this milestone grant report is exactly<br>as planned and required by the Rakudo Star ROADMAP.</p><p>The specific items to be achieved under milestones M1 and M2 are:</p><p> &nbsp; &nbsp; &nbsp; M1-1: PGE internal refactors and initial protoregex implementation<br> &nbsp; &nbsp; &nbsp; M1-2: Selected protoregex constructs added to Rakudo's grammar<br> &nbsp; &nbsp; &nbsp; M1-3: Interface design for pre-compilation and external libraries</p><p> &nbsp; &nbsp; &nbsp; M2-1: Completed protoregex implementation<br> &nbsp; &nbsp; &nbsp; M2-2: Initial implementation of longest token matching in PGE<br> &nbsp; &nbsp; &nbsp; M2-3: Completed Rakudo grammar migration to protoregexes<br> &nbsp; &nbsp; &nbsp; M2-4: Initial implementations of external HLL library support</p><p>Items M1-3 and M2-4 concern handling of library precompilation and<br>external interfaces; these were achieved in late 2008 and early 2009.<br>Rakudo Perl allows library modules to be precompiled to Parrot<nobr> <wbr></nobr>.pir<br>and/or<nobr> <wbr></nobr>.pbc modules for faster loading and execution; indeed, the<br> module is precompiled to substantially reduce the time needed<br>for Rakudo to run the Perl 6 official test suite ("spectests"). Many<br>applications and libraries written for use with Rakudo similarly<br>pre-compile the modules to achieve better load performance.</p><p>An interface for loading external libraries (including those written<br>in other Parrot high level languages) was prototyped and added to<br>Parrot and Rakudo in early 2009; this interface is being continually<br>refined and improved in response to changes in the Perl 6 specification.</p><p>The remaining milestone items concern the implementation of protoregexes<br>and longest token matching (LTM), and the integration of these features<br>into Rakudo. The initial expectation of the grant was that these features<br>would be added to the existing Parrot Grammar Engine (PGE), and<br>subsequently used by Rakudo through PGE. However, as work progressed<br>it became apparent that the changes needed to PGE would significantly<br>impact backwards compatibility and run counter to Parrot's official<br>stability goals. Therefore, instead of modifying PGE I have built<br>a new regex engine essentially from scratch and embedded the engine<br>directly into a new version of NQP (the lightweight Perl6-like<br>language used to build the Rakudo compiler).</p><p>The new engine directly supports protoregexes (M1-1 and M2-1), a<br>limited form of longest token matching (M2-2), and is much more<br>consistent with the Perl 6 specification and implementation [7]<br>as they have evolved over the past couple of years. In addition,<br>instead of compiling regular expressions directly to PIR (as PGE does),<br>the new engine compiles regular expressions to the same abstract<br>syntax tree representation (PAST) used by other HLL compilers in Parrot.<br>This allows better integration of regex support with higher level<br>languages (e.g., HLL closures and variables embedded in regexes).<br>It also may facilitate migrating the regex engine to backends other<br>than Parrot at some point in the future. Another key feature is<br>that the new NQP and regex implementations are largely self-hosted<br>-- that is, the source code is written in NQP itself, further<br>enhancing maintenance and retargetability. The source code repository<br>for this new version of NQP and regular expression support is<br>currently hosted on GitHub at [8].</p><p>Earlier this year Jonathan Worthington and I reviewed the tasks<br>needed for Rakudo to migrate to protoregexes and the standard<br>grammar (, as well as achieve the other critical features<br>needed for Rakudo Star. Because the Perl 6 specification has evolved<br>substantially from when Rakudo's existing grammar and compiler<br>were first started, we decided that we would likely be more<br>successful rebuilding Rakudo from a "fresh grammar" (including<br>protoregexes) rather than try to incrementally refactor the<br>old grammar.</p><p>This rebuilding work has been proceeding in the "ng" ("new grammar")<br>branch of the Rakudo repository, and thus far I am extremely<br>pleased with our progress and results. The new grammar in this<br>branch makes full use of protoregexes (M1-2 and M2-3), and is<br>extremely consistent with the parsing model used by .<br>Furthermore, in the new branch we have already been able to<br>implement critical Perl 6 features (lazy lists, proper lexical<br>handling, lexical subs) that were extremely difficult to achieve<br>in the previous implementation.</p><p>All of the items listed for milestones M1 and M2 of the grant have<br>now been realized. Over the next few weeks I expect to continue<br>work on (re)building the Rakudo-ng branch; when it is passing<br>a comparable percentage of the test suite as the existing Rakudo<br>releases we will officially redesignate Rakudo-ng as the mainline<br>development trunk. (The ng branch is effectively the mainline<br>for development already -- we simply want newcomers to Rakudo to get<br>the "more complete implementation" in the old master branch instead<br>of the "rapidly catching up" version in the ng branch.)</p><p>In the process of completing this migration I also expect to<br>complete the remaining deliverables (D1-D7) for this grant. To<br>briefly review where we are with respect to each grant deliverable:</p><p>D1: (Implementation of protoregexes and longest token matching)<br> &nbsp; &nbsp; &nbsp; &nbsp; Essentially complete, with a few more improvements needed<br> &nbsp; &nbsp; &nbsp; &nbsp; for better longest token matching semantics inside of<br> &nbsp; &nbsp; &nbsp; &nbsp; regular expressions.</p><p>D2: (Alignment of Rakudo's parser and grammar with<br> &nbsp; &nbsp; &nbsp; &nbsp; About 70% complete. Rakudo's grammar in the ng branch<br> &nbsp; &nbsp; &nbsp; &nbsp; is very close to, with only minor additions and updates<br> &nbsp; &nbsp; &nbsp; &nbsp; (and redesignation of the branch as 'master') needed to<br> &nbsp; &nbsp; &nbsp; &nbsp; complete this task. It's worth noting that the goal for D2<br> &nbsp; &nbsp; &nbsp; &nbsp; is "alignment" of the Rakudo and grammars as opposed<br> &nbsp; &nbsp; &nbsp; &nbsp; to "adoption"; indeed, in several areas is changing<br> &nbsp; &nbsp; &nbsp; &nbsp; to reflect some of the ideas being pioneered by the Rakudo<br> &nbsp; &nbsp; &nbsp; &nbsp; grammar implementation.</p><p>D3: (Develop Perl 6 builtins for Rakudo, p6-based "Prelude".)<br> &nbsp; &nbsp; &nbsp; &nbsp; Complete. Perl 6 now uses the term "core setting" instead<br> &nbsp; &nbsp; &nbsp; &nbsp; of "Prelude" for its builtin classes and functions. Since<br> &nbsp; &nbsp; &nbsp; &nbsp; early 2009 Rakudo has increasingly relied on Perl 6-based<br> &nbsp; &nbsp; &nbsp; &nbsp; definitions of its builtin classes. In the Rakudo-ng branch,<br> &nbsp; &nbsp; &nbsp; &nbsp; most of the builtins not already written in Perl 6 are<br> &nbsp; &nbsp; &nbsp; &nbsp; placed in the "src/cheats/" directory in the expectation<br> &nbsp; &nbsp; &nbsp; &nbsp; that they will eventually be rewritten as Perl 6.</p><p>D4: (Develop and improve Rakudo's ability to use external libraries.)<br> &nbsp; &nbsp; &nbsp; &nbsp; Essentially complete, although further work is ongoing to<br> &nbsp; &nbsp; &nbsp; &nbsp; bring Rakudo and the compiler tools up-to-date with recent<br> &nbsp; &nbsp; &nbsp; &nbsp; changes to the Perl 6 specification in this area, and to<br> &nbsp; &nbsp; &nbsp; &nbsp; provide further documentation.</p><p>D5: (Continue developing official Perl 6 test suite.)<br> &nbsp; &nbsp; &nbsp; &nbsp; An ongoing task, but complete for the purposes of the grant.<br> &nbsp; &nbsp; &nbsp; &nbsp; At the time the grant proposal was written (September 2008),<br> &nbsp; &nbsp; &nbsp; &nbsp; the test suite contained approximately 7,000 tests and Rakudo<br> &nbsp; &nbsp; &nbsp; &nbsp; was passing 2,700 of these (38%). As of this writing, the<br> &nbsp; &nbsp; &nbsp; &nbsp; test suite contains over 38,000 tests and Rakudo master<br> &nbsp; &nbsp; &nbsp; &nbsp; passes over 32,000 (85%).</p><p>D6: (Create additional tests for regex engine and library components.)<br> &nbsp; &nbsp; &nbsp; &nbsp; About 50% complete. The NQP repository contains tests for the<br> &nbsp; &nbsp; &nbsp; &nbsp; new regex implementation and protoregexes, some additional tests<br> &nbsp; &nbsp; &nbsp; &nbsp; need to be written for the library interoperability components.</p><p>D7: (Publish weekly reports on Perl 6 implementation progress.)<br> &nbsp; &nbsp; &nbsp; &nbsp; Ongoing and on track. Although reports have not come out weekly,<br> &nbsp; &nbsp; &nbsp; &nbsp; there has been regular communication through our monthly release<br> &nbsp; &nbsp; &nbsp; &nbsp; process, updates to the Rakudo ROADMAP [6], the Rakudo twitter<br> &nbsp; &nbsp; &nbsp; &nbsp; feed [9], regular posts to use.perl and mailing lists, updates<br> &nbsp; &nbsp; &nbsp; &nbsp; to the and websites, and other channels.<br> &nbsp; &nbsp; &nbsp; &nbsp; The goal of D7 has been to ensure increased visibility into<br> &nbsp; &nbsp; &nbsp; &nbsp; Perl 6 and Rakudo progress, this has been largely achieved<br> &nbsp; &nbsp; &nbsp; &nbsp; and will become even more apparent as we near the Rakudo Star<br> &nbsp; &nbsp; &nbsp; &nbsp; release in April 2010.</p><p>Thus the primary tasks remaining for completion of this grant come<br>from deliverables D2, D4, and D6:<br> &nbsp; &nbsp; 1. increased alignment between Rakudo's grammar and,<br> &nbsp; &nbsp; 2. improved longest token matching support, and<br> &nbsp; &nbsp; 3. update HLL library interfaces, documentation, and tests<br> &nbsp; &nbsp; 4. write final grant summary and report</p><p>Of these, only #2 represents any significant or time-consuming<br>effort; the others are likely to be achieved in the normal course of<br>ongoing Rakudo development. The remaining work on longest token<br>matching will be performed with the primary goal of meeting the<br>needs of the Rakudo Star release.</p><p>In summary, all of the items listed for milestones M1 and M2<br>of the grant have now been realized, and many items in the<br>remaining M3 and M4 milestones have also been completed. The<br>few remaining deliverables for this grant are expected to<br>be achieved before the end of 2009.</p><p>[1]<br>[2]<br>[3]<br>[4]<br>[5]<br>[6]<br>[7]<br>[8]<br>[9]</p> pmichaud 2009-11-24T14:49:40+00:00 perl6 The Rakudo-ng branch <p>As I <a href="">wrote a few weeks ago</a>, the period since Rakudo's October release has been one of a lot of refactoring and rebuilding to a new grammar and core implementation. So far everything has gone almost exactly as I outlined at the end of that post, so this is just a status update to let people know where we are. </p><p>The new version of NQP ("<a href="">nqp-rx</a>") has been substantially completed and includes many new features that weren't available in the previous regex engine. In particular, Perl 6 grammars can now support protoregexes, and we also have the ability to execute code blocks, declare variables, and add parameters to regexes. The new version of NQP is also bootstrapped, which means that the code for all of NQP (and its regex engine) is mostly written in NQP. </p><p>On October 30, Jonathan and I started a <a href="">new branch</a> (called "ng" for "new grammar" or "next generation") for refactoring Rakudo to use the new NQP and regex engine implementation. Nearly all of our work since then has been in this new branch, and I think it is going exceedingly well. Today we were able to get the sanity tests and core compiler to where it can again begin compiling and running the test suite. </p><p>Outwardly this probably seems like very slow progress for 10 days of effort, but running the test suite doesn't tell the whole story. In the process of getting to this point, we also knocked off several of the critical features needed for Rakudo Star that weren't possible in the previous version of Rakudo, including lazy lists, proper array element vivification, dynamically generated metaoperators, correct handling of containers and constant values, better dispatch semantics, and a whole host of other features that make the Rakudo core much stronger and easier to work with as we move forward from here. </p><p>Not only that, but we're already at the level where we are implementing builtin classes and methods in Perl 6 (as opposed to PIR). And we're also taking this as an opportunity to rewrite some of the previous PIR-based components into Perl 6. </p><p>So, <em>over the next couple of weeks we will continue to focus on bringing the new "ng" branch up to the same level as the current "master" branch.</em> When we do that, the "ng" branch will likely become the new master branch. I'm still a little reluctant to give a time estimate for when we'll make this switch, but given our current momentum (and the ease in which things are coming together) I suspect it won't be far off -- a few weeks at most. More importantly, unless we hit any major roadblocks, I expect we will have nearly all of the critical components needed for Rakudo Star (and certainly the most challenging ones) implemented by the end of December. We'll then use the remaining months until April to add other important but less-critical features, continue improving performance, and work on packaging and documentation issues. </p><p>Most of the progress reports (and <a href="">Twitter messages</a>) I'll be writing over the next few weeks will be about progress in nqp-rx and in the "ng" branch as opposed to the Rakudo "master" branch. Stay tuned! </p><p>Pm </p> pmichaud 2009-11-11T04:57:29+00:00 perl6 A brief report on progress <p>It's been two weeks since I last did a blog post; and in that couple of weeks there's been an incredible flurry of activity and development. In fact, so productive that I barely have had time to write about it, although that will happen soon.</p><p>As a simple indication of the speed in which things are moving, I thought I would just post a copy of my report to today's #parrotsketch meeting. This represents things that have been achieved since October 27, and what we expect to be doing this upcoming week.</p><p><code><br># parrotsketch report for 2009-11-03:<br>What I did:<br>* NQP stuff:<br>** Added contextual variables, named arguments, modules, class<br> &nbsp; &nbsp; &nbsp; declarations, private class attributes, methods, 'make' statement,<br> &nbsp; &nbsp; &nbsp; pir::op access to PIR opcodes, grammars, tokens, rules, regexes,<br> &nbsp; &nbsp; &nbsp; INIT blocks, unified with , lexical subroutines,<br> &nbsp; &nbsp; &nbsp; parameterized regexes,<nobr> <wbr></nobr>:my declarations in regexes, codeblocks<br> &nbsp; &nbsp; &nbsp; in regexes, code assertions in regexes, \x and \o escapes in<br> &nbsp; &nbsp; &nbsp; regexes and double-quoted strings, variable interpolation in<br> &nbsp; &nbsp; &nbsp; double-quoted strings, a 'make install' target, a --parsetrace<br> &nbsp; &nbsp; &nbsp; option, perl 6 pod comments, warnings for unsupported or NYI features<br>**<nobr> <wbr></nobr>... and made the nqp parser and compiler self-hosting.</code></p><p><code>* Rakudo stuff:<br>** Started the new implementation of Rakudo based on the nqp-rx<br> &nbsp; &nbsp; &nbsp; engine, that is going very well.<br>** Have a new implementation of Lists, Parcels and Arrays,<br> &nbsp; &nbsp; &nbsp; all of which can now have lazy semantics.<br>** Fixed constants and containers handling, Rakudo no longer<br> &nbsp; &nbsp; &nbsp; allows assignment to constant values.<br>** Implemented "real" assignment metaoperator parsing (e.g., &amp;infix:);<br> &nbsp; &nbsp; &nbsp; Rakudo-ng now builds assignment metaoperators only when needed.<br>** Changed subroutines to be stored with the &amp; sigil.<br>** Changed Rakudo operators to be "&amp;infix:&lt;+&gt;" instead of "infix:+".<br>** Have many of the sanity tests running again; compiles<br> &nbsp; &nbsp; &nbsp; but doesn't run completely yet</code></p><p><code>* Plumage:<br>** Updated Plumage Configure and code to work with nqp-rx, passes<br> &nbsp; &nbsp; &nbsp; Plumage's test suite.</code></p><p><code>What I'm doing this week:<br>* Continuing to work on Rakudo-ng, get us running spectests again<br> &nbsp; &nbsp; and compiling setting (now called "CORE")<br>* More minor nqp-rx updates, error message improvements and better<br> &nbsp; &nbsp; syntax checking<br>* Profiling the regex engine to find some speed improvements</code></p><p><code>What I'm blocking on:<br>* Useful programming time<br></code></p><p>As you can see, things are happening quickly, and we're all pleased with the progress. Together with Jonathan's work on dispatch, we appear to have overcome the two major hurdles identified for Rakudo Star. From here on out it's basically just fleshing out the rest of the implementation and adding feature coverage according to the ROADMAP.</p><p>I'll write more details soon; I have to get back to a few other tasks right now. Hope you enjoy reading the above list as much as I enjoyed writing it.</p> pmichaud 2009-11-03T18:25:28+00:00 journal Hague grant work: the new regex engine and NQP <p>It's been quite a while since I've written any articles about Rakudo's progress, but the delay in articles has been because I've been really focused on code development for a number of things we're going to need quickly for <a href="">Rakudo Star</a>. </p><p>At long last I've made the time to make substantial progress on my <a href=""> Hague Grant</a>, which will enable us to bring Rakudo's grammar and parser much more in line with the current <a href=""> grammar</a>. In fact, looking at the <a href=""> Rakudo ROADMAP</a> one can see that a significant number of the critical tasks needed for Rakudo Star are depending on the "PGE refactors" identified in the grant. </p><p>This brings me to one of the major points of this post: In the weeks that follow this month's release we expect that Rakudo will be quite unstable as we undertake some much-needed refactoring and redevelopment of some of Rakudo's core pieces. The biggest change will be a complete replacement of Rakudo's underlying grammar; the grammar we have today is still largely based on the Perl 6 grammar as it existed in January 2008, but and the Perl 6 specification have evolved significantly since then. </p><p>Jonathan and I believe that now's the time to bite the bullet and make another big refactor to bring Rakudo in line with the spec, even though it will likely involve a rework of many features and perhaps a few significant (but temporary) regressions. So, if you see some chaos and upheaval in Rakudo development in the next few weeks, it's a planned and necessary sort of mayhem. </p><p>Many of the needed grammar changes will be possible because of the grant work on protoregexes and a new operator precedence parser. Originally the plan was to build these features into the Parrot Grammar Engine (PGE), but after thinking long and hard about it I concluded that it would be better to redesign and reimplement a new regex engine than to try to fix PGE. For one, I think maintaining backwards compatibility would be a significant challenge (and a drain on my energy and resources). Another reason favoring a rewrite is that we now have better language tools available for Parrot, and a rewrite can take advantage of those tools. </p><p>Thus, instead of compiling directly to PIR, the new regex engine compiles to Parrot's abstract syntax tree representation (PAST). In addition, the source code for the regex engine is written in NQP instead of PIR. </p><p>For those not familiar with NQP, it's a Perl 6-like language I designed for Parrot in conjunction with the Parrot Compiler Toolkit. NQP acts like a "mini Perl 6", it understands a subset of Perl 6 language constructs and can generate Parrot code that doesn't rely on additional runtime libraries. Most of the HLL compiler authors for Parrot have been using NQP to generate PAST, and it's proven to be much easier to write and maintain than PIR. </p><p>Since the regex engine will now be written using NQP, it also seemed fitting that NQP would receive the ability to use Perl 6 regexes and grammars directly. Adding regexes and grammars to the NQP language means that a compiler writer can write nearly all of the components (parser, ast conversion, runtime libraries) using NQP. This is in contrast to the existing setup that requires multiple languages and APIs. </p><p>The new version of NQP is currently called "nqp-rx" ("NQP with regexes"); I may come up with another name for the bundle but I'm somewhat attached to "NQP". This new version also has a new source code repository (separate from Parrot) -- it's hosted on GitHub at <a href=""></a> . </p><p>Since mid-September I've been working on nqp-rx, and I'm very pleased with how it's all coming together. </p><p>For example, late last week I completed most of the work on the new regex engine. This first version includes a very naive implementation of protoregexes, which PGE lacked, and ultimately should perform pattern matching and parsing more efficiently than PGE does. It now compiles to PAST instead of directly to PIR, which means it will fit more cleanly with the rest of Rakudo, especially with being able to handle lexical variables and code blocks in regexes. </p><p>More importantly, the regex compiler is <strong>self-hosted</strong> (or "bootstrapped"). In other words, the regex engine is able to parse and compile the specification that was used to build itself. Stated another way, the regex engine is written using Perl 6 grammars and regular expressions that it knows how to compile. </p><p>Since completing the regex bootstrap I've been working on creating the new version of NQP based on the new regex engine. Over the weekend I created some common rules for parsing number and quoted string tokens, and yesterday and today I completed a new operator precedence parser (all of these based on the equivalents). Now all of the pieces are in place to create a new NQP compiler, which I plan to do over the next couple of days. And, like the regex engine, I'm planning to make this new version of NQP self-hosted as well. </p><p>So, when all of this is completed, NQP will continue to be a "Perl 6 lite" language, but it will also support grammars, regular expressions, protoregexes, longest token matching, a very powerful operator precedence parser, attributes on classes, and a fair bit more. It should also be a bit faster than the previous NQP, and have a few additional optimizations (such as inlining of blocks). </p><p>Thus, here's a quick rundown of the status and plan for the next couple of weeks: </p><ol> <li>Parrot 1.7 was released today (October 20). </li><li>Jonathan has just completed <a href="">a significant refactor of Rakudo's signature binding code</a> and merged it into Rakudo's master. </li><li>Scott Duff ("PerlJam") will be cutting the October Rakudo release on Thursday, based on the Parrot 1.7 release. </li><li>Immediately following the Parrot release, new code for the Parrot Calling Conventions is set to be merged to the Parrot trunk. This is one of the major tasks (B) listed in Rakudo's ROADMAP. </li><li>In the days following the Rakudo release, we'll be working to synchronize the multidispatch and binding algorithms in Rakudo with the new Parrot calling conventions. </li><li>Also in the next few days, we'll complete implementation of nqp-rx, or at least bring it to the point that it can be used instead of the previous compiler tools for building Rakudo. </li><li>When we're comfortable that the Parrot calling conventions work has sufficiently stabilized, we'll start a new branch for the major refactor of Rakudo's internals, switching to the new compiler tools, and updating the grammar to be much closer to </li><li>We don't know how long this last piece will take, but it could easily occupy most of the month before the November Rakudo release. </li><li>During the time that work is taking place in the branch, we don't expect much progress or changes to be made in Rakudo's master branch, so that people can continue to use and test the "more functional" version. </li><li>If work bogs down in the branch, we'll regroup and come up with an alternate plan. But I don't think this likely. </li></ol><p>It looks to be an exciting couple of weeks! I'll be writing more articles with details about the new regex engine, NQP implementation, and Rakudo conversion to the new tools. I hope and expect that by the November release we'll be completely switched over to the new regex engine and have knocked out a large number of the "critical" items on the ROADMAP for Rakudo Star. </p><p>Pm </p> pmichaud 2009-10-21T04:56:04+00:00 perl6 Rakudo day: Rats, contextual variables, and %*ENV fixes <p>As I mentioned in my <a href="">previous post</a>, I'm doing two Rakudo days per week for my grant to make up for some of the weeks I missed during conferences and summer travel. This week I focused on adding a rational (<code>Rat</code>) data type, support for contextual variables, and fixing up the handling of environment variables via <code>%*ENV</code>. </p><p>After the work that was done on operator overloading last week, implementing a basic <code>Rat</code> data type ended up being surprisingly easy. In fact, I just wrote it as a straightforward Perl 6 class and added it to the setting -- you can see the easy-to-read results in <a href="">src/setting/</a>. I did just enough of the implementation to get the basics in place, at which point Solomon Foster, Moritz Lenz, and others started working out a lot of the other details such as conversions to and from <code>Rat</code> and other MMD considerations. As a result we have quite a few clarifications and improvements to the specification, a lot of new tests have been written, and Rakudo passes a lot more tests in the test suite. </p><p>While adding <code>Rat</code> was relatively easy, adding contextual variables to Rakudo was quite a bit more challenging. Contextual variables are similar to lexicals, except that searching for a contextual variable involves looking at a block's callers instead of the block's outer lexical scopes. Contextuals have many similarities to the way that Unix environment variables work, but they also fill many of the niches that would have otherwise been handled by global or environment variables. </p><p>Contextual variables in Perl 6 are denoted using the <code>*</code> twigil. Here's a simple example that uses a contextual: </p><blockquote><div><p> <tt>&nbsp; &nbsp; sub foo() {<br>&nbsp; &nbsp; &nbsp; &nbsp; say $*PHRASE;<br>&nbsp; &nbsp; }<br> <br>&nbsp; &nbsp; sub bar() {<br>&nbsp; &nbsp; &nbsp; &nbsp; my $*PHRASE = 'world';<br>&nbsp; &nbsp; &nbsp; &nbsp; foo();<br>&nbsp; &nbsp; }<br> <br>&nbsp; &nbsp; my $*PHRASE = 'hello';<br>&nbsp; &nbsp; foo();<br>&nbsp; &nbsp; bar();</tt></p></div> </blockquote><p>When run, this outputs "hello\nworld\n". When <code>foo()</code> needs to look up the value of <code>$*PHRASE</code>, it does so by first checking its local lexpad, then checking its caller's lexpad, then its caller's caller's lexpad, and so forth until it finds a declared <code>$*PHRASE</code>. Thus in the first call to <code>foo()</code> above, <code>foo()</code>'s caller is the mainline and so <code>foo()</code> finds the mainline's definition of <code>$*PHRASE</code> ("hello"). The call to <code>bar()</code> declares a new contextual named <code>$*PHRASE</code>, and thus the second call to <code>foo()</code> sees <code>bar()</code>'s value of <code>$*PHRASE</code> ("world"). </p><p>In other words, contextual variable lookups always use the (dynamic) caller chain instead of (static) lexical scoping. </p><p>This turns out to be incredibly useful in a number of situations where we want to provide called functions with an idea of the dynamic context in which they're being called. One of the most common uses for contextuals can be to override the default output for <code>print</code>, <code>say</code>, and other builtin I/O functions. The <code>print</code> and <code>say</code> builtins output to <code>$*OUT</code>, a contextual variable. So, to change the output destination for any calls to <code>say</code> or <code>print</code>, simply declare a new contextual $*OUT: </p><blockquote><div><p> <tt>&nbsp; &nbsp; say "Hello world on standard output";<br> <br>&nbsp; &nbsp; {<br>&nbsp; &nbsp; &nbsp; &nbsp; my $*OUT = open("outfile.txt",<nobr> <wbr></nobr>:w);<br>&nbsp; &nbsp; &nbsp; &nbsp; say "This text is going to outfile.txt";<br>&nbsp; &nbsp; &nbsp; &nbsp; say "Report follows:";<br>&nbsp; &nbsp; &nbsp; &nbsp; print_report();<br>&nbsp; &nbsp; &nbsp; &nbsp; $*OUT.close;<br>&nbsp; &nbsp; }<br> <br>&nbsp; &nbsp; say "...and this also goes to standard output";</tt></p></div> </blockquote><p>So, in the bare block in the above code, the declaration of a new <code>$*OUT</code> contextual causes all of the calls to <code>say</code> and <code>print</code> executed inside of that block to send their output to <em>outfile.txt</em> instead of the default standard output. This behavior holds even for nested function calls such as <code>print_report()</code> -- its calls to <code>say</code> and <code>print</code> also get sent to <em>outfile.txt</em>. </p><p>This ability to establish a dynamic context value that can be quickly looked up from within nested function calls is key to simplifying many compiler implementation details. If you look at <a href=""></a> you'll quickly see how much it relies on contextuals. Indeed, one of my next tasks will be to add contextuals to NQP and PGE so that we can move even closer to the way handles parsing. </p><p>As I alluded above, contextual variables also fill some of the niches held by global and environment variables. If a search for a contextual variable doesn't find it declared in any of the callers' lexpads, we then fall back to looking in the <code>GLOBAL</code> and <code>PROCESS</code> packages. Thus a <code>$GLOBAL::foo</code> variable can be quickly accessed using <code>$*foo</code> if no caller has declared its own <code>$*foo</code>. </p><p>In fact, most of the predefined contextuals such as <code>$*OUT</code>, <code>$*ERR</code>, <code>%*ENV</code>, <code>$*PID</code>, etc., are actually defined in the <code>PROCESS</code> package. This gives us a lot of flexibility in deciding things: </p><blockquote><div><p> <tt>&nbsp; &nbsp; $*OUT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # the standard output of my caller<br>&nbsp; &nbsp; $PROCESS::OUT&nbsp; # the standard output for this process</tt></p></div> </blockquote><p>The implementation for contextual variables in Rakudo required creating new Parrot operations for finding variables in the dynamic caller chain instead of the static outer scope chain, creating a (<code>!find_contextual</code>) sub in Rakudo to handle the contextual lookups, refactoring the compiler to treat the <code>*</code> twigil as a contextual instead of a global variable, and migrating the previous "contextual globals" we had into the <code>PROCESS</code> namespace. These later steps took the longest by far to accomplish. </p><p>Finally for this week's Rakudo days, there have been a number of RT tickets and requests for fixing up the handling of <code>%*ENV</code> -- previously it was based on Parrot's <code>Env</code> PMC and some of the Parrot-isms leaked out (e.g. <a href="">RT #57400</a>). The implementation of contextual variables opened the door to cleaning up <code>%*ENV</code> to work more appropriately, so I went ahead and did that. </p><p>Overall I'm very pleased by the progress made in this week's pair of Rakudo days: we got a good start on rational datatypes and cleaning up the relationships among the built-in scalar types, we now have a working contextual model that we'll need for the next phases of compiler development, and environment variables are now working more like they are supposed to. </p><p>Many thanks to for sponsoring this work. </p><p>Pm </p> pmichaud 2009-09-05T19:56:45+00:00 perl6 Rakudo Day: operator overloading, faster isa, better build <p>July and August have been really busy months with conferences and vacations, so I've fallen a bit behind on Rakudo days for my grant. However, now my travels are largely finished and the kids are back in school again, so I'm hoping I can manage at least two Rakudo days per week until I'm caught up with the original schedule. </p><p>This week's major task did indeed need two days: I've now enabled operator overloading for many of Rakudo's builtin operators. Previously Rakudo has allowed some custom operators to be defined, but overloading the builtin operators (such as infix:&lt;+&gt;) would generally result in "Null PMC in find_method" errors. </p><p>The main approach I ended up taking for this was to re-implement most of the existing operators (previously written in PIR) as Perl 6 multisub definitions with inline PIR. This ended up being somewhat more difficult than it might sound or appear from simply reading the patch -- part of the challenge is that if any variant of an operator is written using Perl 6 multisubs, then all of them must be written that way. But since we had been generating PIR for the Whatever and Junction variants of some builtins, that meant rewriting those versions as well (and figuring out a way to get Rakudo to create WhateverCode objects from the setting). </p><p>Anyway, the hardest pieces are now done, so that many of the built-in operators can be overloaded with custom variants. I'm sure a lot of people will start taking advantage of those; for example, I'm hoping that <a href="">SF</a> will be able to update his <a href="">Vector class</a> to overload the builtin operators now. </p><p>There are still some operators that need to be moved to the setting; although I've been able to migrate prefix:&lt;-&gt; and prefix:&lt;~&gt;, attempting to do the same with prefix:&lt;+&gt; causes a failure in one of the spectests. We'll keep plugging away at it until we figure it out. </p><p>I"m also seeking clarification about the definitions of some of the relational ops; for example, infix:&lt;==&gt; and infix:&lt;eq&gt; are defined in terms of the infix:&lt;===&gt; operator, but I'm curious about the definitions of the other relational ops. </p><p>One item that greatly concerned me about moving the operators into the settings was the possibility that it would significantly slow down Rakudo, because subs compiled from Perl 6 result in a lot more code than hand-written PIR subs do. I even explored some ways to be able to automatically rebless PIR multisubs into Rakudo equivalents. However, I decided to just try the Perl 6 approach (we'll ultimately need to do that anyway), and I was pleasantly surprised that the changes didn't result in significant speed hit to the spectests. Indeed, my timings show that the use of the Perl 6 versions may in fact be slightly faster. I'm not sure how this can be possible, but my best guess at this point is that Rakudo's custom multisub dispatcher (which Jonathan wrote as part of his <a href="">Hague Grant</a>) is somehow significantly faster than Parrot's default multi-dispatch. But that's just a guess on my part... </p><p>Speaking of speed, yesterday I also finished and committed another significant change to Parrot's "isa" functions for testing if a PMC is an instance of a given type. For a long time Parrot has used type name (string) comparisons to check isa membership; this is not only a bit slow, but it can also result in unwanted type name collisions. Ideally the comparison should test the identities of the class objects; but getting this to work required cleaning a few other pieces of Parrot's object and class handling. When it was all finished we obtained a ~4.5% overall speed improvement in Rakudo's spectests. </p><p>Lastly, I've done some more work on improving Rakudo's build and install environment. We now have Rakudo building from an installed Parrot, and yesterday I improved Rakudo's <code></code> so that it warns with a more useful error message if the files needed from a Parrot devel installation aren't present. </p><p>Next I'll need to review the ticket queue again to see how many tickets have been resolved by the above changes. I'll also want to see about adding the tighter/looser/equiv traits to user-defined operators. But mainly I'm glad that we can now start to do some more advanced operator handling and overloading in Rakudo. </p><p>Thanks as always to for sponsoring this work. </p><p>Pm </p> pmichaud 2009-08-28T05:37:11+00:00 perl6 "Perl 6 'finished'" isn't the story I want to tell <p>In a comment to my post <a href="">announcing Rakudo Star</a>, <a href="">gdonald</a> <a href=";cid=69909">writes</a>:</p><blockquote><div><p> <i>Here, I'll explain since you don't seem to get it. When people ask "When will Perl6 be finished?", they want to know when there will be a Perl 6.0 release.</i></p></div> </blockquote><p>Actually, I really think I do "get it", although I admit I may not be clearly expressing that. Later in the same comment thread gdonald <a href=";cid=69916">follows up</a> with:</p><blockquote><div><p> <i>Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee? </i></p></div> </blockquote><p>To me, that sounds an awful lot like a variation of "When will Perl 6 be finished?", especially the "What is the hold-up..." part. In short, the thread quickly went from "you don't seem to get it" to ultimately saying something very like the question I used to start my original post.</p><p>Neither this reply nor my original article are intended to imply that people shouldn't be asking such questions or that they're wrong for doing so. I call out gdonald's messages not because I wish to ridicule him or prove him wrong, but simply because I think they illustrate well the "disconnect" that exists in discussions about Perl 6, and why I'm hoping to change the discussions to something more useful than "finished" and "not finished". Because the end result of the "finished/not finished" discussion is often:</p><blockquote><div><p> <i>Seems like Perl6 might be going the way of GNU/Hurd, eternally under development, and never to land.</i></p></div> </blockquote><p>I don't believe that Perl 6 will be eternally under development -- but I am concerned that the perception of "eternally under development" is potentially a significant blocker to continued progress on Rakudo and Perl 6. That's one of the major issues that Rakudo Star is intended to address.</p><p>I also completely "get it" that for most people the real thing they want to know is "When can I start using Perl 6?" in the sense of "apt-get install perl6". But I think even that question has many hidden assumptions that must be exposed before there can be any sort of useful answer. Indeed, the answer changes depending on who is asking the question and what they want to do. So another purpose for Rakudo Star is to illuminate the development process and our ongoing status so that people can begin answering that question for themselves.</p><p>As the quotes above illustrate, somewhere there's an implicit assumption that the specification should be finished already. When we then say that the spec isn't finished (and it isn't), people often conclude that Perl 6 is suffering from a "design by committee process flaw" that is preventing the specification from being finished, and in turn that's what is blocking "apt-get install perl6". I think these misconceptions arise from assuming a "waterfall" development model where it's a one-way path from specification to implementation. But just because (unlike Perl 5) Perl 6 has a spec that is separate from its implementations doesn't mean the specification comes first.</p><p>Looking back, it's not too surprising to me that people have assumed a waterfall model of development -- those of us working on Perl 6 haven't given a good public picture of the true story. The various development roadmaps we've provided have been accurate as far as they went, but they didn't really give insight into the underlying processes. And for many of us, myself included, we're only now learning how to put words to parts of the process to be able to tell others about them. Here's my version...</p><p>For the past few years, changes to the specification have been made almost exclusively in response to the concerns and issues that have come about from compiler implementations and application programs written in Perl 6. For example, while implementing a feature in Rakudo we often discover a place where the specification is self-contradictory, so the specification is changed to resolve the contradiction. Or, someone will be using Perl 6 to write an application, and as a result we find places where the specification is deeply sub-optimal and needs to be cleaned up. These days it's very rare that the design team says "wouldn't it be nice/better if Perl 6 changed to do X" on its own initiative; our discussions are nearly always "implementations are having trouble with this part of the specification, what do we need to change to improve that?"</p><p>So the specification isn't finished, but that's mainly because it's evolving in response to implementations and applications, and not due to a tendency to over-design it. Because the specification is evolving based on implementation issues, simply freezing what exists now as "6.0.0" will make things harder on implementors, not easier. In other words, freezing the existing spec will paradoxically delay implementations of Perl 6, not expedite them.</p><p>We are rapidly entering a phase where what we will need most is for more people to be creating real use cases in Perl 6, testing the soundness of the design and implementation. That is, we need to see more applications to be written in Perl 6 so we can harden the specification even further. For many people and applications Rakudo is ready for use today, but there are still enough issues that I'm hesitant to call it anything other than a "development release" for a more general audience. The problem then is that many people rightly take "development release" to mean "not ready to use yet", and that's also counterproductive to what we need.</p><p>This is where Rakudo Star comes in, and this is what I mean by "a useful implementation of Perl 6". It's intended to recognize that a Perl 6 release can be useful to many even though it may be incomplete. It's intended to provide a bright line where we can say "here's what is working now" and "here's what is not working yet". It's intended to help people determine when Perl 6 has been sufficiently realized to be ready for their needs. And it's intended to make it possible for more people to start writing programs in Perl 6, because one of the things we are needing is real-world use cases to test, refine, and extend the existing design.</p><p>At the same time, we need to be very careful about using the label "finished" or "1.0" for anything that isn't all of what has been promised for Perl 6.0. (See KDE 4 development for why this is a bad thing.) In fact, I'd like us avoid the notion of "finished" altogether. Instead, I want us to regularly deliver something that is useful and usable, make it clear what we are delivering, make it clear what we're not delivering, and enable people to see when Perl 6 is likely be ready for them (as opposed to "ready for all").</p><p>Ultimately Rakudo Star is intended to give some justifiable support and clarity to phrases like "Perl 6 exists" and "you can now write usable applications in Perl 6", without the distractions that arise from the "When will [Perl 6 | Rakudo] be finished?" sorts of questions. It's not that I think people are somehow wrong for asking these questions -- I think I do very much understand what leads people to ask them -- it's just that I'd like us to start finding ways to move our discussions beyond the "finished / not finished" trap that we seem to have fallen into. I'd like to help us all escape this trap because (1) I don't think it reflects reality, and (2) if "Perl 6 is finished" remains the primary criteria that most people use to decide whether or not to write applications in Perl 6 (and the criteria that we hold ourselves to), then we'll never get there.</p><p>Pm</p> pmichaud 2009-08-09T02:26:14+00:00 perl6 Building a "useful release of Perl 6" <p>The most common question I get from people who aren't generally involved with Perl 6 development is: </p><blockquote><div><p> <em>"When will Perl 6 be finished?"</em></p></div> </blockquote><p>In some ways the wording of this question bugs me a bit, because the word "finished" implies there's a point at which we all say "We're done" and development ceases (or at least moves to some other phase). But there really isn't a "finish line" for Perl 6, there are just stages of development at which more and more people are able to make use of whatever is currently available. </p><p>So, once we eliminate the notion of "finished", the wording is often changed to try to make it more tractable, often by asking when there will be a "stable release", or when the specification will be frozen so an implementation can be completed, or many other variations on the theme. I understand the assumptions behind questions like these, but at the same time part of me thinks "Huh? Those questions don't really fit with the way things really happen in language development..." </p><p>The truth is that language design is an evolutionary process, with the design and implementation efforts serving to influence and guide further progress in the other. (See "whirlpool model".) </p><p>But there's another important input to the process: "real-world" application programs. We need to know how Perl 6 is actually being used in order to finish parts of the specification and implementation. Indeed, there are parts of Perl 6 (e.g., concurrency) where the specification is incomplete or underspecified precisely because we need input from people writing Perl 6 applications. </p><p>But this poses a problem of sorts, because if programmers are waiting for Perl 6 to "finish" before they start using it to write programs, and if Perl 6 is blocking on feedback from applications and implementations before it can progress, then we have a deadlock of sorts. </p><p>So, we need a way to break the deadlock. To me, one good answer is to start making releases of Perl 6 that may not implement the entire Perl 6 specification, but that application writers will feel comfortable enough to start using in their projects. I've started to call these "useful releases" or "usable releases". While it might not have every feature described in the Perl 6 synopses, enough features will be present that can make it a reasonable choice for application programs. </p><p>In doing this, I'd like to also refocus conversations to avoid words like "finished" and "stable", because they have such varied and strong meanings in this context. </p><p>So, here's what the Rakudo Perl project is going to do: </p><blockquote><div><p>We will make an "official", intermediate, <em>useful</em> and <em>usable</em> release of Perl 6 (an appropriate subset) by Spring 2010.</p></div> </blockquote><p>Of course, we have to decide what will will be included (and <em>excluded</em>) in this intermediate "official release". At the Rakudo BOF on Monday we held a lively discussion about what the release could look like, what needed to be present, and how it could be packaged. During the hackathons and days following YAPC::EU we'll be drafting and publishing the more detailed blueprint for the release. But one of our guiding principles will be to "under-promise and over-deliver", to make it clear what <em>can</em> be done with the release, and to make it very clear which parts of Perl 6 are not yet supported in the release. </p><p>A short list of things we <em>know</em> will be in the release (that Rakudo doesn't already have): use of the grammar for parsing, laziness, better support for modules, fewer bugs, better error messages, better speed. Again, our goal is to make something that is reasonable for people to start using, even if it doesn't meet all of the requirements for Perl 6.0.0. </p><p>We've also had discussions about what to call the intermediate release. We've considered tagging it as "Rakudo 1.0", but some of us think that the "1.0" name might tend towards "overpromise". We also considered things like "0.5" or "0.9", but these come with the message of "not ready for use", and that's not what the impression we want to make either. </p><p>So, yesterday morning I finally got around to thinking about it as "Rakudo 'whatever'". In Perl 6 the <code>*</code> term is used to signify "whatever", so that leads to a working name of "Rakudo *" (or "Rakudo Star"). </p><p>So, the focus of the Rakudo project is to release "Rakudo Star" in Spring 2010 as a <em>useful</em> (but incomplete) implementation of Perl 6. More details about the features, milestones, and roadmap for this release will be forthcoming over the next few days. </p><p>Pm </p><p>P.S.: Several of our "down-under" community members have pointed out that "Spring 2010" can be a bit ambiguous. I'm using a season (instead of a month) to leave a month or two of wiggle room, but my intention is April 2010. As we get a bit more detail into the plan, we'll identify a specific month.</p> pmichaud 2009-08-05T18:42:56+00:00 perl6 Lightning advertisements <p><b>YAPC::EU Day 1</b></p><p>During <a href="">today's lightning talks</a>, Geoffrey Avery added a new "lightning advertisements" feature to the session. Lightning advertisements are 30-second "promotional spots" that occur between each pair of talks; these help to fill the "dead air time" that typically occurs between each talk as the next lightning talk speaker works to get his or her presentation synced with the projector.</p><p>The purpose of a lightning advertisement is to simply create awareness or buzz about something happening at the conference. For example, I used my lightning advertisement to remind people of the <a href="">Rakudo BOF</a> taking place immediately after the lightning talk session. I'm certain that this directly increased the number of people who made it to the BOF, so I'm very pleased that Geoffrey added this feature to the session.</p><p>Others used the 30-second lightning advertisement slots to make announcements about other BOFs taking place and items being put for sale at the auction.</p><p>In order for things to run smoothly, it's important that there be a second microphone available for advertisers to use while the next lightning talk speaker is setting up. Also, the advertisers need to be at the front "ready to go" when one talk finishes and the next begins. With only 30 seconds available, there's not really time for slides or any visuals -- it's just the person making whatever announcement there is to be made.</p><p>In today's session several advertisers had difficulty finding the "on/off" switch on the microphone (it was <i>really tiny</i>); I suspect things can go a bit smoother if there's someone selected as the "microphone manager" to make sure it's correctly configured for each advertiser.</p><p>With eight lightning talk speakers, there are seven slots for lightning advertisements. When the session began there were only three "advertisers" at the front of the room, but as the lightning talks progressed (and people discovered how advertisements worked) the remaining four slots were quickly filled. I suspect it would be no problem for some slots to remain empty if there aren't sufficient advertisers, but I also suspect that as the idea catches on there will be no lack of advertisers. It also didn't seem to require much formal organization; the advertisers simply designated themselves by sitting at the front of the room, and we JIT-ted the ordering of advertisers as the session progressed.</p><p>I found the lightning advertisements to be an incredibly useful addition to the lightning talks session; kudos to Geoffrey Avery for adding them. I hope they become a regular feature of future lightning talk sessions.</p><p>[ironman perl]</p> pmichaud 2009-08-04T04:53:28+00:00 events Rakudo Day: install, quoting, and string operators <p>Since I was busy at <a href="">OSCON</a> all this week, it was difficult to find a single day to dedicate to my grant. But I did manage to get several major tasks done from my hotel room, so I'm going to bundle those together and count them as my "Rakudo day" for the week. </p><p>The biggest accomplishment was to finally get Rakudo so that it can build from an installed Parrot. Prior to Parrot 1.4.0 this has been exceedingly difficult, as an installed copy of Parrot did not provide all of the tools needed to compile dynamic PMCs and dynamic opcodes on our target platforms. But over the past few weeks Allison Randal and Will Coleda have gotten it to work for <a href="">ParTcl</a>, and now I've been able to adapt those techniques to work with Rakudo. The current state of building Rakudo from an installed Parrot is in the "ins2" branch of the github repository, if you wish to give it a try. (See below for instructions.) Note that some of the spectests will fail if you try "make spectest"; because the "ins2" branch is using an older version of Rakudo and some spectests have been added to the test suite since then. Since we're really just testing build/install, "make test" is sufficient here (and I'll clean up any spectest issues when I merge it back to the master branch). </p><p>Some may ask why we don't simply merge it back to master now; I haven't wanted to merge the ins2 branch back into trunk until we have verification that it builds properly on a variety of platforms. So far I've only had it fully tested on a couple of versions of Linux; I don't want to end up cutting out other operating systems from playing with Rakudo. </p><p>One of the downsides of building Rakudo from an installed Parrot is that we effectively lose the ability to easily build Rakudo from a build-tree copy of Parrot (like we do now). Part of the problem is that the filesystem layout of a build-tree copy of Parrot is very different from the filesystem layout of an installed Parrot. So at a minimum we would need a lot of code that says "if installed Parrot use this path, if Parrot build use this other path". This is true not only for file locations, but also for the tools used to build dynamically loaded PMCs and opcodes. Instead of trying to support both layouts, I'd prefer to just stick with using an installed Parrot for now. </p><p>(Note that it doesn't have to be a system-installed Parrot, the <code>--gen-parrot</code> option to Rakudo's <code></code> will make a local install of Parrot and then build Rakudo from that.) </p><p>We're not abandoning the ability to build Rakudo from a build-copy of Parrot, we're just switching gears for a while. Based on conversations with other Parrot team members at YAPC::NA Pittsburgh and online, we've decided that of building (but not installing) Parrot should result in something that directly mimics the filesystem layout of an installed Parrot. When this is done, it will be easier for HLL languages and other tools built on Parrot to work from either a build tree or install tree version of Parrot. </p><p>In other areas, during Monday's OSCON tutorial sessions I sat in on Damian Conway's "<a href="">Perl 6: Why? What? How?</a>" tutorial. I wanted to see the tutorial itself, but I was also curious to know what problems would arise during the tutorial so that I could work on fixing them quickly. One of the problems that was quickly identified was that the <code>&lt;&lt;<nobr> <wbr></nobr>... &gt;&gt;</code> quoting operator wasn't handling comments properly. In other words, the following code </p><blockquote><div><p> <tt>&nbsp; &nbsp; my $a = &lt;&lt;<br>&nbsp; &nbsp; &nbsp; &nbsp; do&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# a deer<br>&nbsp; &nbsp; &nbsp; &nbsp; re&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# a drop of golden sun<br>&nbsp; &nbsp; &nbsp; &nbsp; mi&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# a name I call myself<br>&nbsp; &nbsp; &gt;&gt;;</tt></p></div> </blockquote><p>would act like a list of eighteen words instead of three. To be honest, I had overlooked that comments were allowed here, so that evening I quickly updated the parser to skip over comments as well as whitespace, and now the above works the way it is supposed to. Note that it even skips embedded and pod comments: </p><blockquote><div><p> <tt>&nbsp; &nbsp; my $a = &lt;&lt; do #(a deer) re #(a drop of golden sun) &gt;&gt;;&nbsp; # ("do", "re")</tt></p></div> </blockquote><p>We had quite a few tickets dealing with places where operations end up returning Parrot <code>String</code> objects instead of Perl 6 <code>Str</code> objects. The easiest way to detect when this happens is to attempt to perform<nobr> <wbr></nobr><code>.trans</code> on the string -- the<nobr> <wbr></nobr><code>.trans</code> method for Parrot strings doesn't work the same as Rakudo's<nobr> <wbr></nobr><code>.trans</code> method. So I converted a few settings functions (e.g.,<nobr> <wbr></nobr><code>.uc</code>,<nobr> <wbr></nobr><code>.flip</code>,<nobr> <wbr></nobr><code>.lc</code>, etc.) to explicitly call <code>prefix:&lt;~&gt;</code> on the result value; this guarantees that we end up with a Perl 6 <code>Str</code> object. </p><p>When we ultimately switch Rakudo to use HLL mapping of Parrot types, these explicit coercions won't be needed. However, at the moment using HLL mapping imposes a significant speed penalty on Rakudo (we're working on this), and given that things are on the slow side already I'd rather keep the speed and maintain workarounds for the time being. </p><p>I also fixed up stringification of several of the builtin types, especially <code>Int</code>, <code>Num</code>, and <code>Junction</code>. Previously printing a Junction object would produce a string like <code>"Junction()&lt;0x7fb898cb42b0&gt;"</code>, which is almost certainly not what is wanted. So I updated <code>Junction.Str</code> to simply return its<nobr> <wbr></nobr><code>.perl</code> representation. </p><p>Finally, Rakudo had been misparsing function names that began with a keyword followed by an apostrophe or hyphen. For example: </p><blockquote><div><p> <tt>&nbsp; &nbsp; sub do-something() { say 'hello'; }<br> <br>&nbsp; &nbsp; do-something();</tt></p></div> </blockquote><p>Because <code>do</code> is a keyword, Rakudo would often end up parsing the above as <code>do -something()</code>, which of course wouldn't work properly. Similar issues existed with other keywords such as <code>if</code>, <code>for</code>, <code>while</code>, etc. </p><p>Having a longest-token matcher in the parser can avoid a lot of these misparses, but it's not always a complete solution. The STD grammar (as well as Rakudo's grammar) has a special <code>&lt;.nofun&gt;</code> lookahed subrule that can be used to verify that the keyword we just scanned is actually a keyword and not simply the lead-in to a function call. I went ahead and added a few &lt;.nofun&gt; calls to Rakudo's grammar, and now subroutine names that begin with keywords work like they're supposed to. (Thus making them a lot more fun.<nobr> <wbr></nobr>:-) </p><p>There were other fixes here and there throughout the week, and of course Moritz Lenz did the Rakudo #19 release on Thursday (which I describe in <a href="">another post</a>. I also worked with Jonathan on improving our internal object metamodel and introspection capabilities, and he and I worked out some ideas for refactoring our handling of lexicals. And all of this took place while I was attending OSCON, giving various presentations, and engaging in useful hallway discussions with other Perl folks. So it's been a busy and good week. </p><p>As always, my thanks go to for sponsoring the work I did on the above tasks. Because of all of the travel and conferences I'm a bit behind on Rakudo days, so I will likely try to double-up on them for a few weeks until I'm caught up. </p><p>Pm </p><p>To test the ins2 branch: </p><blockquote><div><p> <tt>&nbsp; &nbsp; $ git clone git://<br>&nbsp; &nbsp; $ git branch ins2 origin/ins2<br>&nbsp; &nbsp; $ git checkout ins2<br>&nbsp; &nbsp; $ perl --gen-parrot<br>&nbsp; &nbsp; $ make test</tt></p></div> </blockquote> pmichaud 2009-07-27T04:47:27+00:00 perl6 Behind the scenes of the Chicago Release <p>This week I learned just how well Rakudo development is able to continue even when I'm preoccupied with things not directly related to making commits to the Rakudo repository. </p><p>As you probably know, I spent this past week in San Jose at <a href="">OSCON</a>, which was as usual was a fantastic conference. I was able to give some presentations about Rakudo and Parrot (recruiting!), meet lots of new people, visit and make plans with others working on Perl 6, and otherwise just have a good time. </p><p>Prior to coming to San Jose I had been planning that I would have some time in the evenings to work directly on Rakudo and prepare for its #19 release on Thursday (Jul 23). In past years at OSCON I've been able to get a fair amount of hacking done in the evenings... but that didn't happen this year. </p><p>First of all, I found myself having far more hallway discussions and other sorts of meetings with folks than I have in past OSCONs. Then, on Tuesday night I decided that I really wanted to do a significant refactor of the "<a href="">Hacking Rakudo Perl</a>" talk that I would be giving on Wednesday. I knew this would take away from my tuits for preparing the Thursday Rakudo release, but I felt the benefit of having a better talk (which I will also be giving at <a href="">YAPC::EU in Lisbon</a>) was worth the risk of having trouble getting the release out on Thursday. </p><p>Fortunately I never had to run that risk. A couple of weeks ago I posted an article about <a href="">getting release managers for Rakudo</a>. On Tuesday (while I was busy at OSCON), Moritz Lenz was able to use the <a href="">release guide</a> to produce a "practice release" as described in the article. </p><p>As a result, on early Wednesday morning I was able to see that Moritz had produced a practice release, and knowing that I wanted to focus on my presentation I immediately asked him if he would like to do the official release on Thursday. (I also asked Jonathan if he could work on eliminating a Null PMC error that was showing up in backtraces and didn't look good for the release, which he of course took care of very quickly.) </p><p>Moritz accepted the release task, and I am <em>extremely</em> pleased with how everything turned out. First of course is the release itself, which is equal or better to anything I would've produced. Moritz, along with help from others on IRC #perl6, assembled the ChangeLog, drafted the release announcement (adding a new section for deprecations), and as far as I can tell executed the release flawlessly. As it turns out, my role in the release consisted only of reviewing the release announcement on Wednesday night, adding a couple of statistics to the announcement, and telling Moritz that he could issue the release whenever he felt it was ready. I didn't have any further involvement after that -- the next I heard about it was someone coming up to me at OSCON on Thursday afternoon to congratulate me on the <a href="">Chicago release</a>. </p><p>This past week saw more than just the release; during the course of the week several people added new features and bugfixes to Rakudo (with Moritz and others applying contributed patches). Rakudo's passing spectest count increased by over 100 during the course of the week. </p><p>So, my thanks go out to Moritz, Jonathan, Carl, Kyle, Scott, and everyone else who worked on the release and Rakudo this week. You all did a fantastic job, and tremendously simplified my life while I was at OSCON. </p><p>Of equal importance, we've now demonstrated that others besides myself can do Rakudo releases (although I had little doubt of this). As a result, I'm now issuing an <em>official</em> "call for release managers" for the remaining Rakudo releases in 2009. Ideally I'd like to see that the release responsibility is regularly rotated across multiple managers (as Parrot does), so that no single person ends up being burdened with producing releases. I'm also planning that I personally won't do any more Rakudo releases myself in 2009, unless we're completely unable to find release managers. </p><p>If you're interested in becoming a Rakudo release manager -- take a look at the <a href="">release guide</a>, make sure you've filed a <a href="">Contributor License Agreement</a>, and we'll put together a schedule for the 2009 releases. </p><p>Pm </p> pmichaud 2009-07-26T02:24:53+00:00 perl6 improving "Hacking Rakudo Perl" <p>In about a week or so I'll be at <a href="">OSCON 2009</a>, giving a presentation on <a href="">Hacking Rakudo Perl</a>. I'll also be giving the talk at <a href="">YAPC::EU</a>. </p><p>I've given versions of this talk twice before -- once at the Nordic Perl Workshop and again at YAPC|10 in Pittsburgh; I think they went well, but the talk is probably due for an update. In particular, at OSCON and YAPC::EU I'll have less time than in the previous talks, so I'd like the talks to more directly focus on the items that will be of most use to the audience. </p><p>So, what are your ideas about what information attendees would like to know for "Hacking Rakudo Perl"? What should I definitely include in the updated versions of the talk? </p><p>For those who are interested, the slides from my previous talks are available at <a href=""></a> . </p><p>Thanks! </p><p>Pm </p> pmichaud 2009-07-14T05:12:21+00:00 perl6 Seeking future Rakudo release managers <p>Over the next couple of weeks I'm working on fleshing out "job openings" and descriptions for people who want to help advance Rakudo Perl 6. I'll write more about this in a later post, and they're likely to appear in my <a href="">OSCON</a> and <a href="">YAPC::EU</a> talks. </p><p>One of the jobs we've already identified is "Release Managers", following closely on the Parrot model. Release managers are people that are responsible for executing Rakudo releases according to the release schedule. And like Parrot, we want this responsibility to be widely spread among a team of managers, and not always fall to the same person for every release. So, over the next month or so I'll be recruiting people to be release managers, starting with the August 2009 release. (The July 2009 release is likely to have a few significant changes -- most notably a "make install" target -- so I think it's better for me to do that one last release myself. Also I may want to coordinate the release with my talk.) </p><p>However, yesterday it occurred to me that thanks to github, it's entirely possible <em>today</em> for people to independently go through all of the steps of cutting and publishing a Rakudo release. So now I'm eager to have others try it and see what happens. At present the release steps are targeted to work primarily from Unix environments -- I haven't tested or attempted to cut a release from other operating systems. (I'll accept patches and suggestions for doing so, though!<nobr> <wbr></nobr>:-) </p><p>For those who want to try it, here are the basic steps for creating a Rakudo "practice release": </p><ul> <li>Fork the <a href="">Rakudo master repository</a> on github. </li><li>Follow the steps in the <a href="">docs/release-guide.pod</a> file, substituting your own github repo clone for the Rakudo master. </li><li>Let us know "Hey, I just made a Rakudo release!" and point to your forked copy github repo. Or tell us where you ran into problems, so we can improve the process. </li><li>Profit. </li></ul><p>Some notes about creating "practice releases": </p><ul> <li>It's okay to skip steps 1-3 of the release guide for practice releases </li><li>You can also safely skip any steps that involve communicating with others, such as posting messages to the mailing lists or updating the wiki </li><li>If you don't want to wait the 30+ minutes for a spectest run to complete, "make test" is sufficient for a practice release. </li><li>Yes, it's even possible for you to test uploading the tarball to github -- just make sure to put it in your own repository and not in Rakudo's master.<nobr> <wbr></nobr>:-) </li></ul><p>So, anyone want to give it a try? If you do, please let us know how it works out, and places where you think things can improve. I know that we'll be updating the release guide in response to feedback from others, as well as adding things like testing of "make install" and the like. </p><p>Thanks! </p><p>Pm </p> pmichaud 2009-07-08T01:19:08+00:00 perl6 Rakudo day: operators in setting and lots of RT bugfixes <p>At the beginning of June the organization generously committed to funding me for 1-day-per-week of Rakudo effort, but because of the Rakudo release, Parrot Virtual Machine Workshop, YAPC::NA, and a short vacation, today is the first day that I had available to really dedicate to the task. In fact, to catch things up a bit I plan to do another Rakudo day tomorrow or Thursday. </p><p>Here's what I accomplished for today's Rakudo day. </p><p>The biggest task I tackled for the Rakudo day was to be able to write operators in the setting (Perl 6) instead of PIR (RT #66826). In fact, I had actually done most of this last week during the YAPC::NA hackathon day, but interruptions then and a few annoying Parrot bugs kept me from marking the task as completely accomplished then. What this means is that we can now begin defining operators directly in Perl 6 code (perhaps with some inlined PIR), which moritz++ has already been exercising for infix:&lt;...&gt;, infix:&lt;eqv&gt;, and a few other operators. Over the next few weeks I expect we'll move even more operators out of PIR and into the setting. </p><p>The rest of today's Rakudo day was spent reviewing and cleaning up the RT queue; it had grown to over 400 tickets but by the end of the day Jonathan and I have shrunk it back down to 387. I think we collectively closed about 16 tickets today, and I responded with requests for clarification or updates on several more. Here are some of the highlights: </p><p>RT #66060 noted a problem that the<nobr> <wbr></nobr>.uc method would fail on some strings where<nobr> <wbr></nobr>.lc worked. I tracked this down to a Parrot issue in its handling of Unicode strings when ICU wasn't present, and refactored the code to be a bit more robust there. </p><p>RT #66640 noted that the minmax operator wasn't implemented, so after some discussion about what it should do I added it to the setting (using the operator features mentioned above). </p><p>In RT #66624, the exception message coming back from not finding a substring within a string was particularly misleading; I adjusted<nobr> <wbr></nobr>.substr to provide a more useful error message. </p><p>For RT #66928<nobr> <wbr></nobr>.WHAT would not work on some subs like &amp;infix:&lt;+&gt;; this was because some of the builtin operators are still using Parrot's MultiSub PMC instead of the Perl6MultiSub PMC, and those didn't have a mapping to the type object. Eventually all of the operators will become Perl6MultiSub; in the meantime I set Parrot MultiSub PMCs to map to the Multi() type objects in the same manner that other Parrot PMC classes are mapped to Perl 6 types. </p><p>RT #66818 noted a problem with unwanted flattening of %*VM in a for statement; this was because the contents of %*VM were incorrectly bound to the Hash directly instead of going through a non-flattening reference (Perl6Scalar). Eventually I expect %*VM to be initialized in the setting, though, which will provide a more robust and direct solution to this problem. </p><p>In RT #66840 it was discovered that precedence errors in the ternary operator would cause Rakudo to issue an error message and exit completely, instead of throwing a catchable exception. I tracked this down to PGE's OPTable handling of the ternary operator, it was actually using "exit" when the error occurred (probably because it came from before Parrot's exception model was firmly in place). This was changed to throw an exception instead; the actual exception message needs a bit of work but I expect that will come from the much larger PGE refactoring that will be done as part of the Hague grant. </p><p>Lastly, today I spent a good bit of time discussing Rakudo and Parrot build/install issues with Allison, and I think we have basic agreement on the changes we'll be making in order to get those working. Hopefully we can get all of that done in time for the July release. </p><p>So, that's my first Rakudo day -- lots of little pestering bug fixes, and a key bit of infrastructure to fully enable writing the builtin operators in Perl 6. Later this week I plan to do a long-needed refactor of container handling in Rakudo, and maybe to get a more complete implementation of BEGIN blocks (which we massively cheat on at the moment). </p><p>Thanks again to for sponsoring this work. </p><p>Pm </p> pmichaud 2009-07-01T04:08:20+00:00 perl6 Rakudo Perl 6 development release #18 ("Pittsburgh") <p>On behalf of the Rakudo development team, I'm pleased to announce the June 2009 development release of Rakudo Perl #18 "Pittsburgh". Rakudo is an implementation of Perl 6 on the <a href="">Parrot Virtual Machine</a>. The tarball for the June 2009 release is available from <a href=""></a> . </p><p>Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at <a href=""></a> . </p><p>Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Pittsburgh", which is the host for <a href="">YAPC|10</a> (YAPC::NA 2009) and the <a href="">Parrot Virtual Machine Workshop</a>. has also sponsored hackathons for Rakudo Perl as part of the <a href="">2008 Pittsburgh Perl Workshop</a>. </p><p>In this release of Rakudo Perl, we've focused our efforts on refactoring many of Rakudo's internals; these refactors improve performance, bring us closer to the Perl 6 specification, operate more cleanly with Parrot, and provide a stronger foundation for features to be implemented in the near future. Some of the specific major changes and improvements in this release include: </p><ul> <li>Rakudo is now passing 11,536 spectests, an increase of 194 passing tests since the May 2009 release. With this release Rakudo is now passing 68% of the available spectest suite. </li><li>Method dispatch has been substantially refactored; the new dispatcher is significantly faster and follows the Perl 6 specification more closely. </li><li>Object initialization via the BUILD and CREATE (sub)methods is substantially improved. </li><li>All return values are now type checked (previously only explicit 'return' statements would perform type checking). </li><li>String handling is significantly improved: fewer Unicode-related bugs exist, and parsing speed is greatly improved for some programs containing characters in the Latin-1 set. </li><li>The IO<nobr> <wbr></nobr>.lines and<nobr> <wbr></nobr>.get methods now follow the specification more closely. </li><li>User-defined operators now also receive some of their associated meta variants. </li><li>The 'is export' trait has been improved; more builtin functions and methods can be written in Perl 6 instead of PIR. </li><li>Many Parrot changes have improved performance and reduced overall memory leaks (although there's still much more improvement needed). </li></ul><p>The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see <a href=""></a> , ask on the mailing list, or ask on IRC #perl6 on freenode. </p><p>The next release of Rakudo (#19) is scheduled for July 23, 2009. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. </p><p>Have fun! </p><p>References: <br>[1] Parrot, <a href=""></a> <br>[2] YAPC|10 <a href=""></a> <br>[3] Parrot Virtual Machine Workshop, <a href=""></a> <br>[4] Pittsburgh Perl Workshop, <a href=""></a> </p> pmichaud 2009-06-19T05:17:59+00:00 perl6 Rakudo Perl 6 development release #17 ("Stockholm") <p>On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm". Rakudo is an implementation of Perl 6 on the <a href="">Parrot Virtual Machine</a> [1]. The tarball for the May 2009 release is available from <a href=""></a> . </p><p>Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at <a href=""></a> . </p><p>Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Stockholm"; Stockholm Perl Mongers will be holding a <a href="">Perl 6 hackathon on May 29</a> [3]. Perl 6 developer Carl M&auml;sak is a member of Stockholm Perl Mongers and a main author of <a href="">November</a> [4], <a href="">Druid</a> [5], <a href="">proto</a> [6], and other Perl 6-based packages. Carl also contributes patches to Rakudo, and has been stress-testing Rakudo over the past year, submitting nearly 400 bug reports. </p><p>In this release of Rakudo Perl, we've made the following major changes and improvements: </p><ul> <li>Rakudo is now passing 11,342 spectests, an increase of 875 passing tests since the April 2009 release. With this release Rakudo is now passing 68% of the available spectest suite. </li><li>We now have an updated docs/ROADMAP . </li><li>Errors and stack traces now report the file name and line number in the original source code. </li><li>Some custom operators can be defined, and it's possible to refer to operators using &amp;infix:&lt;op&gt; syntax. </li><li>We can start to load libraries written in other Parrot languages. </li><li>Regexes now produce a Regex sub. </li><li>More builtin functions and methods have been rewritten in Perl 6 and placed as part of the setting. </li><li>There are many additional improvements and features in this release, see docs/ChangeLog for a more complete list. </li></ul><p>The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see <a href=""></a> , ask on the mailing list, or ask on IRC #perl6 on freenode. </p><p>The next release of Rakudo (#18) is scheduled for June 18, 2009. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. </p><p>Have fun! </p><p>References: <br>[1] Parrot, <a href=""></a> <br>[2], <a href=""></a> <br>[3] Stockholm Perl 6 hackathon, <a href=""></a> <br>[4] November wiki engine, <a href=""></a> <br>[5] Druid, <a href=""></a> <br>[6] Proto, <a href=""></a> </p> pmichaud 2009-05-21T16:46:31+00:00 perl6 Rakudo Perl 6 development release #16 ("Bratislava") <p>On behalf of the Rakudo development team, I'm pleased to announce the April 2009 development release of Rakudo Perl #16 "Bratislava". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the April 2009 release is available from <a href=""></a> . </p><p>Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at <a href=""></a> . </p><p>Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Bratislava", home to Jonathan Worthington and reportedly an excellent place to obtain beer (a key component of Jonathan's contributions to Perl). The group is quite active [2], with regular technical presentations and social gatherings. </p><p>In this release of Rakudo Perl, we've made the following major changes and improvements: </p><ul> <li>Rakudo is now passing 10,467 spectests, an increase of 3,194 passing tests since the March 2009 release. With this release Rakudo is now passing approximately 65% of the available spectest suite. </li><li>About 2/3 of the increase in passing tests is due to improved Unicode support in Rakudo; constructs such as "\c[LATIN CAPITAL LETTER A]" and Unicode character properties in regexes are now supported. </li><li>The prefix:&lt;=&gt; operator is now gone from the Perl 6 specification (and thus from Rakudo). Use<nobr> <wbr></nobr>.get for reading individual items from iterators. </li><li>Rakudo now supports typed arrays and hashes (my Int @array), as well as parametric versions of the Associative, Positional, and Callable roles, and parametric role subtyping. </li><li>Rakudo now has sockets support (IO::Socket). </li><li>Subroutine return types are now enforced in some cases. </li><li>Rakudo now supports lexical sub declarations. </li><li>Rakudo now supports some P5-style regexes. </li><li>The "quantify-by-separator" feature has been added, so that one can write / [\w+] ** ',' / to get a comma-separated list of words. </li><li>More builtin functions and methods have been rewritten in Perl 6 and placed as part of the setting. </li><li>Release tar files now contain local copies of the appropriate spectests, instead of obtaining checkout copies via Subversion. </li><li>There are additional improvements and features in this release, see docs/ChangeLog for a more complete list. </li></ul><p>The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see <a href=""></a> , ask on the mailing list, or ask on IRC #perl6 on freenode. </p><p>The next release of Rakudo (#17) is scheduled for May 21, 2009. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. </p><p>Have fun! </p><p>References: <br>[1] Parrot, <a href=""></a> <br>[2], <a href=""></a> </p> pmichaud 2009-04-23T05:10:43+00:00 perl6 Rakudo release on Thursday <p>This week I've been at the <a href="">Nordic Perl Workshop 2009</a>; both the conference and hackathon have been outstanding. The NPW organizers and other Oslo hosts have been fantastic. Things have been happening so quickly that there's been little time to report on them. We'll be having a "wrap-up meeting" shortly, and after that I'll make a longer post summarizing the many things that have been accomplished with Perl 6 and Rakudo. </p><p>Thursday is Rakudo's next planned release; over the next couple of days we'll be cleaning up loose ends and making sure things are stable for the release. Updates to the ChangeLog and build test reports are greatly appreciated. </p><p>We haven't finalized a Perl Mongers group to use for the name of this release (February was "Vienna", March was "Oslo"), so we're still taking suggestions there. If you have any to suggest <a href="">drop me an email</a> with the name of the group and why you think they'd be a good choice to highlight. </p><p>More soon, </p><p>Pm </p> pmichaud 2009-04-20T14:10:44+00:00 perl6 Oslo Perl 6 Hackathon Notes <p>As some of you are aware, this week is the <a href="">Nordic Perl Workshop</a>, and in the days immediately following the workshop we will have the <a href="">Oslo Perl 6 Hackathon</a>. During the first day of the hackathon Gabor Szabo will be doing a <a href="">"Hands-on Perl 6 training" course</a>, the other two days will be for various hacking tasks (both Perl 6 and Perl 5). </p><p>I personally have three goals for my participation at the workshop and hackathon: </p><ul> <li> Attend Gabor's course and take careful note of where issues arise with using Rakudo Perl and/or Perl 6 (including filing bug reports and/or answering questions as needed). </li><li> Recruit and encourage people to write Perl 6 programs and otherwise start hacking on/with Rakudo Perl. </li><li> Meet with other principal Rakudo and Perl 6 designers and implementors to plan the next phases of work and address any significant obstacles currently before us. </li></ul><p>For now I've started a page at <a href=""></a> that lists a variety of specific ideas for things to work on or address at the hackathon. I'm sure more ideas will arise at NPW itself, and I invite others to add more items to the list as well. Feel free to add things even if you won't be making it to NPW or the hackathon itself; you may think of something that we've overlooked, and there are other hackathons planned later in the summer that will benefit from having the ideas. </p><p>Thanks! </p><p>Pm </p> pmichaud 2009-04-13T22:11:15+00:00 perl6 Rakudo Perl development release #15 ("Oslo") <p>On behalf of the Rakudo development team, I'm pleased to announce the March 2009 development release of Rakudo Perl #15 "Oslo". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the March 2009 release is available from <a href=""></a> </p><p>However, because of the rapid pace of Rakudo development and addition of new features, we still recommend that people wanting to use or work with Rakudo obtain the latest version directly from the main repository at github -- more on this in a bit. </p><p>Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Oslo" in honor of the organizers of the <a href="">2009 Nordic Perl Workshop</a> [2], April 16-17, 2009. The 2009 Nordic Perl Workshop will have a special focus on Perl 6, Rakudo Perl, and Parrot, including Perl 6 tutorials and hackathons after the conference itself. </p><p>A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. </p><p>Rakudo Perl now uses git [3] for its version control system, hosted at <a href=""></a> . The README file there is kept up-to-date with the latest instructions for obtaining and building Rakudo Perl. </p><p>In this release of Rakudo Perl, we've made the following major changes and improvements: </p><ul> <li>Rakudo is now passing 7273 spectests. This is an increase of 197 passing tests since the February 2009 release. </li><li>The eval() construct now understands lexical variables from an outer scope. </li><li>More of the builtin functions ("settings") are being written in Perl 6. </li><li>Rakudo supports the "R" (reverse) metaoperator. </li><li>Parsing of if, unless, while, until, etc. statements after blocks now works correctly. </li><li>The Q quote operator is now implemented, along with several adverbial forms. In particular, the Q:PIR form allows inline PIR to be included in Perl 6 code. </li><li>Multi-method dispatch now works with inheritance also. </li></ul><p>The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. The next release of Rakudo (#16) is scheduled for April 23, 2009. </p><p>References: <br>[1] Parrot, <a href=""></a> <br>[2] Nordic Perl Workshop 2009, <a href=""></a> <br>[3] Git version control system, <a href=""></a> </p> pmichaud 2009-03-20T17:23:56+00:00 perl6 a(nother) Reverse Polish Notation Calculator <p>In <a href="">a Reverse Polish Notation Calculator</a>, fREW Schmidt takes the RPN calculator example from <a href="">Higher Order Perl</a> and converts it over to Perl 6.</p><p>Very cool.</p><p>But as usual, I visually look at the Perl 6 version compared to the Perl 5 version and think "Can't we do better?" In this case, we can. Here's my version of the same code:</p><blockquote><div><p> <tt>&nbsp; &nbsp; my %op_dispatch_table = {<br>&nbsp; &nbsp; &nbsp; &nbsp; '+'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop +<nobr> <wbr></nobr>.pop) },<br>&nbsp; &nbsp; &nbsp; &nbsp; '-'&nbsp; &nbsp; =&gt; { my $s =<nobr> <wbr></nobr>.pop;<nobr> <wbr></nobr>.push(.pop - $s) },<br>&nbsp; &nbsp; &nbsp; &nbsp; '*'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop *<nobr> <wbr></nobr>.pop) },<br>&nbsp; &nbsp; &nbsp; &nbsp; '/'&nbsp; &nbsp; =&gt; { my $s =<nobr> <wbr></nobr>.pop;<nobr> <wbr></nobr>.push(.pop / $s) },<br>&nbsp; &nbsp; &nbsp; &nbsp; 'sqrt' =&gt; {<nobr> <wbr></nobr>.push(.pop.sqrt) },<br>&nbsp; &nbsp; };<br> &nbsp; <br>&nbsp; &nbsp; sub evaluate (%odt, $expr) {<br>&nbsp; &nbsp; &nbsp; &nbsp; my @stack;<br>&nbsp; &nbsp; &nbsp; &nbsp; my @tokens = $expr.split(/\s+/);<br>&nbsp; &nbsp; &nbsp; &nbsp; for @tokens {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when<nobr> <wbr></nobr>/\d+/&nbsp; &nbsp; &nbsp;{ @stack.push($_); }<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when ?%odt{$_} { %odt{$_}(@stack); }<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; default&nbsp; &nbsp; &nbsp; &nbsp; { die "Unrecognized token '$_'; aborting"; }<br>&nbsp; &nbsp; &nbsp; &nbsp; }<br>&nbsp; &nbsp; &nbsp; &nbsp; @stack.pop;<br>&nbsp; &nbsp; }<br> &nbsp; <br>&nbsp; &nbsp; say "Result: { evaluate(%op_dispatch_table, @*ARGS[0]) }";</tt></p></div> </blockquote><p>The result:</p><blockquote><div><p> <tt>$<nobr> <wbr></nobr>./perl6 '5 6 +'<br>Result: 11</tt></p></div> </blockquote><p>The major changes I made to fREW's code:</p><p>1. Convert the explicit subs into simple closures, assuming that the stack is the implicit topic.<br>2. Use 'when' statements instead of if/elsif/else in the body of the 'evaluate' sub.</p><p>And yes, as frew points out -- when we get the 'R' metaoperator in place we can get rid of the 'my $s =<nobr> <wbr></nobr>...' parts of subtraction and division. Maybe I'll implement meta-R now...<nobr> <wbr></nobr>:-)</p><p>Thanks fREW for the very interesting example!</p><p>Pm</p><p><b>Update:</b> I went ahead and implemented the R metaoperator. For those who aren't familiar with meta-R, it reverses the order of the operands to an operator. So, (5 R- 4) is the same as (4 - 5), and (2 R/ 10) is the same as (10 / 2). With this change, the RPN calculator becomes:</p><blockquote><div><p> <tt>&nbsp; &nbsp; my %op_dispatch_table = {<br>&nbsp; &nbsp; &nbsp; &nbsp; '+'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop +<nobr> <wbr></nobr>.pop)&nbsp; },<br>&nbsp; &nbsp; &nbsp; &nbsp; '-'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop R-<nobr> <wbr></nobr>.pop) },<br>&nbsp; &nbsp; &nbsp; &nbsp; '*'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop *<nobr> <wbr></nobr>.pop)&nbsp; },<br>&nbsp; &nbsp; &nbsp; &nbsp; '/'&nbsp; &nbsp; =&gt; {<nobr> <wbr></nobr>.push(.pop R/<nobr> <wbr></nobr>.pop) },<br>&nbsp; &nbsp; &nbsp; &nbsp; 'sqrt' =&gt; {<nobr> <wbr></nobr>.push(.pop.sqrt)&nbsp; &nbsp; },<br>&nbsp; &nbsp; };<br> &nbsp; <br>&nbsp; &nbsp; sub evaluate (%odt, $expr) {<br>&nbsp; &nbsp; &nbsp; &nbsp; my @stack;<br>&nbsp; &nbsp; &nbsp; &nbsp; my @tokens = $expr.split(/\s+/);<br>&nbsp; &nbsp; &nbsp; &nbsp; for @tokens {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when<nobr> <wbr></nobr>/\d+/&nbsp; &nbsp; &nbsp;{ @stack.push($_); }<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when ?%odt{$_} { %odt{$_}(@stack); }<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; default&nbsp; &nbsp; &nbsp; &nbsp; { die "Unrecognized token '$_'; aborting"; }<br>&nbsp; &nbsp; &nbsp; &nbsp; }<br>&nbsp; &nbsp; &nbsp; &nbsp; @stack.pop;<br>&nbsp; &nbsp; }<br> &nbsp; <br>&nbsp; &nbsp; say "Result: { evaluate(%op_dispatch_table, @*ARGS[0]) }";</tt></p></div> </blockquote> pmichaud 2009-03-02T19:41:55+00:00 perl6 Rakudo Perl development release #14 ("Vienna") <p>On behalf of the Rakudo development team, I'm pleased to announce the February 2009 development release of Rakudo Perl #14 "Vienna". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the February 2009 release is available from <a href=""></a> </p><p>However, because of the rapid pace of Rakudo development and addition of new features, we still recommend that people wanting to use or work with Rakudo obtain the latest version directly from the main repository at github -- more on this in a bit. </p><p>This is the fourteenth development release of Rakudo Perl, but it's the first release independent from Parrot releases. We will continue to follow a monthly release cycle, with each release to be code named after a Perl Mongers group. This release is named for (<a href=""></a>), who have been sponsoring Jonathan Worthington's work on Rakudo since April 2008. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. </p><p>Rakudo Perl now uses git [2] for its version control system, hosted at <a href=""></a> . The README file there is kept up-to-date with the latest instructions for obtaining and building Rakudo Perl. </p><p>In this release of Rakudo Perl, we've made the following major changes and improvements: </p><ul> <li>Rakudo is now passing 7076 spectests. This is an increase of 796 passing tests since the January 2009 release. </li><li>The script supports a "--gen-parrot" option to automatically fetch and build the appropriate version of Parrot. </li><li>The default make target now builds a binary executable directly, either perl6 or perl6.exe. It's still a Parrot "fakecutable", but we think we've made it more reliable so that it doesn't generate segmentation faults on exits. (If you don't know what a "fakecutable" is you can safely ignore this.) </li><li>Many builtins are beginning to be written in pure Perl 6, or Perl 6 functions with inline PIR. These builtins are part of the core "setting" for Perl 6, and appear in the src/setting/ directory. Previously this was known as the "prelude". </li><li>Improved diagnostic output. </li></ul><p>Also, Rakudo now implements the following Perl 6 features: </p><ul> <li>Anonymous classes may be specified using<nobr> <wbr></nobr>:: </li><li>Existing parameterized roles are now reused instead of creating new ones. </li><li>Roles pun a class when<nobr> <wbr></nobr>.new is invoked on them. </li><li>"proto" now marks all same-named routines as "multi". </li><li>"XopX" is now "Xop". </li><li>&lt;-&gt; (rw) pointy blocks. </li><li>min= and max= metaoperators. </li><li>Many many bugfixes and documentation improvements. </li></ul><p>The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. The next release of Rakudo (#15) is scheduled for March 19, 2009. </p><p>References: <br> [1] Parrot, <a href=""></a> <br> [2] Git version control system, <a href=""></a> </p> pmichaud 2009-02-27T06:02:51+00:00 perl6 Leaving the Parrot nest <p>As many of you will have gathered from discussions on other mailing lists and IRC, it's time for Rakudo Perl to "leave the Parrot nest" and move to its own repository. I think we should also take this opportunity to re-evaluate the entire Rakudo Perl infrastructure and decide what will be most productive for the community for the upcoming year. Indeed, as part of any move we need to communicate the details of the changes to others, which brings to the surface some of the shortcomings of what we have now. </p><p>By "infrastructure" I'm primarily referring to the following items: </p><ul> <li>source code repositories (note: plural) </li><li>web sites </li><li>blog / news </li><li>wiki </li><li>issue tracking </li><li>mailing lists </li></ul><p>Currently these things are spread in many different locations with different tools, and while I don't believe it's necessary for them completely unified, we should at least aim to reduce the overall complexity of what we do have so that we can better serve those who are interested (or are yet to become interested) in Rakudo Perl. In fact, it may be that in many cases we'll keep what we have now, but at least it'll be a confirmed decision instead of simply going along with what we've had in the past. </p><p>Also, I'm sure it will be easy and tempting to address larger issues about Perl 6 as a whole (as opposed to just "Rakudo"). I'm not at all opposed to seeing that larger discussion take place, but for my purposes I'll be tending to focus on Rakudo's immediate needs. </p><p>Here's my off-the-cuff inventory of where things are in Rakudo today and where things might head. It's entirely possible that my description below misunderstands or misrepresents reality in some areas -- but I'm dedicating this week to resolving that. Indeed, that's the primary purpose of this message, to help us all clear up confusion surrounding Rakudo (and Perl 6). </p><p> <strong>Source code repository</strong> </p><p>This is the immediate issue at hand, because we need to move Rakudo out of the Parrot repository so that it can cleanly move to its new home at Currently Rakudo Perl lives at <a href=""></a> , while the spectest suite (on which development/testing depends) lives at <a href=""></a> . </p><p>Many people have strongly suggested that we switch to using "git" as our version control system. At the moment I'm neither strongly in favor of nor strongly opposed to switching version control systems, but we have to recognize that at least two of Rakudo's "dependencies" (Parrot and the spectest suite) are using Subversion and are likely to remain that way for a while. We don't want to require non-developers to install a lot of different source code control systems simply to run and test the latest incarnation of Rakudo Perl. </p><p>I have a lot more comments on source code management for Rakudo Perl, but to keep to the "overview" nature of this post I'll save the rest for a longer post. Feel free to start submitting your opinions, however! </p><p> <strong>Web site / blog / wiki</strong> </p><p>Currently Rakudo really does not have a dedicated website providing basic information about it. There is the <a href=""></a> site, but it's currently more of a blog than a true web site. For example, someone visiting would not be able to easily find out how to download and run Rakudo Perl. </p><p>Here's what we <em>do</em> have at the moment (as best as I can recall): </p><ul> <li> is run by Andy Lester and currently provides a "blog" for Rakudo Perl. Andy has mused about switching to Drupal instead of Movable Type, which could enable us to more easily have "introductory content" information instead of just blog-type entries. </li><li>Of course, many of us regularly post to journals at <a href=""></a> . This is good for keeping in touch with the wider Perl community and provides a good blog-like interface, but again isn't useful at basic Rakudo information and orientation. </li><li>The Perl Foundation hosts a "Perl 6 wiki" at <a href=""></a> , and Rakudo has a few pages there. Currently I find the wiki to be not very well organized, and it's difficult to find Rakudo out of the many other items that appear there. Beyond that, I'm not impressed with the wiki engine the site uses, but if a sizable group of people think that's where Rakudo information should be centered then I can live with it. </li><li>TPF also hosts the "Perl 6" website at <a href=""></a> , but "Rakudo Perl" isn't even mentioned there, and I don't even really know the correct procedure for getting updates or modifications to those pages. My impression is that this site isn't really conducive to frequent updates or lots of contributors (but perhaps I'm incorrect about that). </li><li>Planet Perl 6 (<a href="">(approve links)</a>) is an excellent aggregator of Perl 6 related posts, including those involving Rakudo Perl. </li></ul><p>Also, for the record, I currently own the "" and "" domains, so if we want to do something somehow separate from any of the existing domains cited above, we can use those domains, and I may have (or be able to acquire) additional server resources to support it. </p><p> <strong>Issue tracking</strong> </p><p>Currently issue tracking for Rakudo is being done using RT at <a href=""></a> (the same RT instance that does Perl 5 bug tracking). In the past I've stated that Rakudo bugs will continue to use this tracker, and I'm still planning for that to be the case, but in recent weeks I've encountered a number of times were was too slow/unreachable to be an effective tool. I'm not (yet?) advocating that we switch to a different issue tracker, but since we're looking at the whole of infrastructure items I did want to leave the possibility open for discussion. </p><p> <strong>Mailing list</strong> </p><p>Currently Rakudo's primary mailing list is &lt;;. I see no major reason to change anything here, as it works well and is a good companion to the other "official" Perl 6 mailing lists. </p><p>---------- </p><p>Throughout all of this, I'm looking at things from a very practical perspective -- i.e., what can we achieve with the resources currently at our disposal. It's also important to consider the needs of the various audiences -- not only the Rakudo developers, but also people who want to experiment with Rakudo and those who want to start building applications for it. So, we need to keep in mind the many perspectives on the issue as we go through the discussion. </p><p>Also, I'm expecting that some of the decisions I eventually make may disappoint some; apologies in advance, but such is the nature of decisions. </p><p>With that background in place, I'll now (with great trepidation) open the discussion for others to comment and/or make suggestions of what they'd like to see changed about the way we currently manage Rakudo Perl. </p><p>Thanks in advance, </p><p>Pm </p> pmichaud 2009-01-15T02:53:47+00:00 perl6 List of working and non-working Rakudo features <p>A newcomer to Rakudo and Perl 6 asked me "Where can I get a list of features that currently work in Rakudo?" Rather than try to build (and maintain) the list myself, I've built a wiki page for it at <a href=""></a>.</p><p>You'll notice that the page starts with a list of "common things that don't work" -- I'm hoping that people can use this to get a sense for the common pitfalls without having to search RT (which can be a bit slow). But below that we can start listing things that _do_ work.</p><p>Feel free to add/modify the page in whatever ways you think will be useful.</p><p>Pm</p> pmichaud 2009-01-02T16:50:23+00:00 perl6