masak's Friends' Journals http://use.perl.org/~masak/journal/friends/ masak's Friends' use Perl Journals 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:20+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 masak's Friends' Journals http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~masak/journal/friends/ Rakudo Star 2010.08 released http://use.perl.org/~pmichaud/journal/40518?from=rss <p>[This announcement was made last week on rakudo.org -- I'm reposting to use.perl.org so it will show up in the various Perl aggregators. --Pm]</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="http://github.com/rakudo/star/downloads">http://github.com/rakudo/star/downloads</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="http://perl6.org/">http://perl6.org/</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="http://rakudo.org/how-to-help">http://rakudo.org/how-to-help</a>, ask on the perl6-compiler@perl.org 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="http://github.com/rakudo/rakudo">http://github.com/rakudo/rakudo</a><br>[2] <a href="http://parrot.org/">http://parrot.org/</a></p> pmichaud 2010-09-01T12:36:56+00:00 perl6 Rakudo Star - an "early adopter" distribution of Perl 6 http://use.perl.org/~pmichaud/journal/40469?from=rss <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="http://github.com/rakudo/star/downloads">http://github.com/rakudo/star/downloads</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="http://perl6.org/">http://perl6.org/</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="http://modules.perl6.org/">http://modules.perl6.org</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="http://rakudo.org/how-to-help">http://rakudo.org/how-to-help</a>, ask on the perl6-compiler@perl.org 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="http://github.com/rakudo/rakudo">http://github.com/rakudo/rakudo</a> <br>[2] <a href="http://parrot.org/">http://parrot.org/</a> </p> pmichaud 2010-07-29T12:28:04+00:00 perl6 Last Post http://use.perl.org/~JonathanWorthington/journal/40450?from=rss <p>Well, on use.perl.org, anyway. I'd like to thank those who run this place for doing so, as it's been the place I've blogged about my Perl 6 stuff for the last couple of years. However, I've found the user experience of WordPress a lot more enjoyable - it was great for the Perl 6 Advent Calendar - and figure I'll blog more if I more enjoy doing so.</p><p>So, from now you'll be able to read my Rakudo news and other Perl 6 related ramblings from my <a href="http://6guts.wordpress.com/">shiny new blog</a>. For those reading through Planet Six, no action required - I'll arrange for my new blog to be aggregated there.</p><p>See you <a href="http://6guts.wordpress.com/">over there</a>.</p> JonathanWorthington 2010-07-18T02:58:24+00:00 journal Rakudo Star (a "usable Perl 6") to be released by July 29 http://use.perl.org/~pmichaud/journal/40407?from=rss <p>As many of you know, last summer we announced that we would be releasing a "<a href="http://use.perl.org/~pmichaud/journal/39411">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="http://use.perl.org/~pmichaud/journal/40248">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="http://rakudo.org/node/72">#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="http://perl6.org/">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 Perl Mova + YAPC::Russia http://use.perl.org/~JonathanWorthington/journal/40399?from=rss <p>On Friday I flew from rainy Sweden to scorching hot Kiev to attend a combined Perl Mova + YAPC::Russia. The passport queue wasn't overly long, and I'd happily managed to be hand luggage only, so I wasn't too long in the airport. I planned to take the "official" bus, but before it appeared I heard a lady shouting about a mashrutka going to the center, so I took that instead. Understanding basic Russian - well, it coulda been Ukrainian too - sure comes in helpful. I was dropped by a metro station, leaving the 15 euro-cent (yes, really) metro ride a few stops to where I was staying - a hotel right on the main Independence Square. I was a little bemused as I checked in to be spoken to in a mixture of Russian and Ukrainian, by the same person in the same conversation.</p><p>My plane had been slightly late, so I was also slightly late joining the pre-workshop dinner. After I'd filled up on a tasty dish of borsch, we wandered on to a pub that offered no less than 22 different beers. I was...happy.<nobr> <wbr></nobr>:-) Some beer later, it was time for a little stroll, which terminated in a Japanese restaurant, where I had my first encounter with wasabi vodka. All in all, a very fun start to my visit here.</p><p>I was worried I'd sleep badly in my room since it was a little hot, but I actually slept really quite well and was nicely refreshed for the hack meet. There were a lot of people there hacking on all kinds of different projects. Some folks were interested in contributing to Rakudo, and so we gathered around on a table and I helped each of them find and get started on a task. It went extremely well - everyone in attendance contributed Rakudo patches or code that allowed us to close an RT ticket right there on the day, or that will after I apply patches. Of note, people who were new to Rakudo hacking:</p><ul> <li>Located and unfudged tests for \e that was recently fixed, allowing the ticket about that to be closed.</li><li>Implemented<nobr> <wbr></nobr>.all,<nobr> <wbr></nobr>.any,<nobr> <wbr></nobr>.one and<nobr> <wbr></nobr>.none method versions of junction constructors and added tests for them, allowing that ticket to be closed.</li><li>Debugged and then wrote a patch that fixed a bug in range iteration, plus added tests, allowing an RT ticket to be closed.</li><li>Implemented<nobr> <wbr></nobr>.cando and did some related refactors in the area that I suggested and also located some tests to unfudge. Due to network issues that one didn't get applied on the day, though I have it and have just applied it locally, so it'll be in soon.</li><li>Tracked down what was wrong with forming colon pairs from variables involving twigils, patched it and made sure we had some test coverage of that; again, we closed a ticket.</li><li>Wrote a patch to fix a bug in the series operator that had been reported in RT, along with some test cases for it.</li></ul><p>I think it goes without saying that this is really quite impressive, especially given they had to share one Rakudo core hacker between them for guidance. In fact, I even had time to cook up a few patches myself amongst guiding others! It was great fun to hack alongside such pepole. I handed three spectest repo commit bits out that day, and I think they were all used. It's experiences like the one at this hack meet that make me really glad that we're writing most of Rakudo in Perl 6 or a restricted dialect of it - all of the above tasks required (apart from a one line change in one of them) no PIR or C knowledge at all. Some of those at the hackmeet said they may find time for a bit more Rakudo hacking in the future, which would be really great.<nobr> <wbr></nobr>:-) After the hack meet, there was more nice food - including a Chicken Kiev - and some lovely beer at prices I've become rather unacustomed to in Sweden.</p><p>Day two was talks day. I had one 40 minute talk on Perl 6 signatures which went well. I received some great questions, and I hope I answered them all to people's satisfaction. Later on, I gave a lightning talk about Rakudo * and what it would contain, and showed off a <a href="http://pivo.jnthn.net/">simple little example site</a> that used Rakudo Perl 6, including the modules JSON::Tiny by moritz++ and FakeDBI by mberends++ along with Blizkost (sorear++ for that) to get at the Perl 5 CGI module (though I'll refactor it to use Web.pm in the near future - I just wanted an excuse to show off Blizkost). The evening was, of course, more food and beer, and a lot of fun.</p><p>The final day of the workshop was a bit different - a river cruise! It was very relaxing, and gave me yet another way to enjoy this beautiful city. Certainly good for unwinding after a workshop. Most people left either after that or were flying home today; I on the other hand used "no direct flight on a Tuesday" as an excuse to get another day to potter around Kiev, and today I've enjoyed doing exactly that, gently strolling between my favorite sights and stopping in the odd open air cafe in a park to keep myself refreshed in the somewhat stuffy weather. Soon it'll be time to take my last dinner here, an evening stroll and maybe find some outdoor place to sit and nurse a final beer before it's time to get some sleep before my flight home tomorrow.</p><p>Beautiful Kiev. It gets harder to leave each time I come.<nobr> <wbr></nobr>:-)</p> JonathanWorthington 2010-06-15T15:11:09+00:00 journal More Perl 6 Anti-FUD http://use.perl.org/~pmichaud/journal/40326?from=rss <p>More Perl 6 Anti-FUD here:</p><p><a href="http://www.perlmonks.org/?node_id=836533">http://www.perlmonks.org/?node_id=836533</a></p><p><a href="http://www.perlmonks.org/?node_id=836564">http://www.perlmonks.org/?node_id=836564</a></p><p>and thoughts on the name "Perl 6"</p><p><a href="http://www.perlmonks.org/?node_id=836626">http://www.perlmonks.org/?node_id=836626</a></p><p>Pm</p> pmichaud 2010-04-23T23:38:22+00:00 journal A wholly inadequate reply to an Anonymous Monk http://use.perl.org/~pmichaud/journal/40322?from=rss [Reposted from <a href="http://www.perlmonks.org/?node_id=836349">http://www.perlmonks.org/?node_id=836349</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 perlmonks.org recently started a discussion on "<a href="http://www.perlmonks.org/?node_id=835419">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="http://www.perlmonks.org/?node_id=835737">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="http://use.perl.org/comments.pl?sid=43556&amp;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="http://svn.pugscode.org/pugs/src/perl6/STD.pm6">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="http://irclog.perlgeek.de/perl6/2010-04-22#i_2253574">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="http://arstechnica.com/open-source/news/2010/04/perl-5-development-resumes-version-512-released.ars?comments=1#comment-20189196">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 Perl 6 talk in Malm&#246; http://use.perl.org/~JonathanWorthington/journal/40316?from=rss <p>Recently I moved to Sweden to join startup company <a href="http://www.edument.se/">Edument</a>. They are, happily, very open to and supportive of my involvement in the Perl 6 project, and are organizing and sponsoring me to give a <a href="http://natverk.dfs.se/node/19602">talk on Perl - both 5 and 6</a> for the <a href="http://www.dfs.se/">Dataf&#246;reningen</a> in Malm&#246; on Tuesday 27th April. I believe this is only open to those who are members of the user group; if you are, feel free to come along though.</p> JonathanWorthington 2010-04-20T09:55:36+00:00 journal The Easter Hackathon http://use.perl.org/~JonathanWorthington/journal/40303?from=rss <p>I spent my Easter up in Uppsala with masak++, who it turns out is not only awesome at breaking Rakudo, but also a great host. Amongst a lot of memes, bad puns, wonderful noms (I learned how to make k&#246;tbullar!) and even a Czech beer, we got quite a bit of Perl 6 hacking done too.<nobr> <wbr></nobr>:-)</p><p>On the first evening, we managed to fix up a bunch of issues with various escape sequences in regexes and strings, and also the fact that "\$x" was failing to escape the $ since we made ng the new master! I fixed a longstanding bug that <a href="http://use.perl.org/~masak/journal/40167">annoyed masak so much that he dedicated a whole blogpost to it</a>, did some work on enforcing zone constraints in signatures and, in an awesome bit of collaborative development along with colomon++ and moritz++ wired up their new reduction implementation to the reduction meta-operator parsing stuff. That means that you now have triangle forms of the meta-ops, chaining meta-ops work and right-associative ones do the right thing too. We never had any of these right before.</p><p>Spurred on by the interpolation work on the previous night, on the next day I started looking at what it would take to implement more of the interpolation bits, and after a bunch of hacking I accidentally the whole lot of it. You can now interpolate indexes into both arrays and hashes, calls to subroutines and method calls on all of these. The way this works in Perl 6 parsing-wise is really neat: we just call from the quote parser back into the standard expression parser, but giving it a few constraints so it knows only to parse the things that are allowed to be interpolated into strings. It's a fairly directly following of STD - we differ in a couple of minor ways for now, but the approach is the same.</p><p>Along the way, I used the regex tracer that pmichaud++ had implemented while developing the new grammar engine, and noticed that we seemed to be dropping into a lot of protoregexes we shouldn't have been. A little more exploration and I realized that we were failing to calculate a bunch of constant prefixes for regexes. Fixing that gave a 5% saving on parse times.</p><p>The day after that, I worked on something I'd really been putting off because it's hard and painful: making the setting the outer lexical scope of user programs. While some languages define a prelude, Perl 6 essentially defines a "circumlude" - it's as if your program was running as an inner lexical scope inside the built-ins. That means that you find just about everything through lexical scoping. I got the first difficult 80% done and committed, but I suspect I've now got another really difficult 80% left to go, and probably another really really difficult 80% after that. Along the way, I fixed some bugs to do with scope modifiers "leaking". Anyway, to prove it helped somewhat, I tossed a whole bunch of "our"s that had been in as hacks while we didn't have the setting as an outer lexical scope. I suspect that perfecting this is going to be a large chunk of my work on Rakudo over the next couple of weeks.</p><p>The last day, I did the (relatively easy, thanks to all the groundwork I had laid during my signatures grant) bits of work to get us able to do smart-matching against signatures. This deserves an entire post of its own, and I'll write one for you soonish, but essentially you can use it to write a given/when that dives into a hash/array/object and looks at whats in it, just using declarative signature syntax. It's just like having a sub-signature on a parameter passed to a block or routine, apart from the signature object stands alone. By the way, I do plan to submit a talk on signatures for YAPC::EU - I'm really quite excited about the declarative power they offer that goes far, far beyond a better way to do parameters than Perl 5's @_. Especially in combination with multi-dispatch.</p><p>masak++ spent a good portion of the time working on Temporal/DateTime spec and starting an implementation to back it up. It has to be one of the most bikeshedded areas in the Perl 6 spec, with plenty of "let's do something SO clever" thinking along with the much more sensible "we want something minimal but useful in the language itself, and the clever stuff belongs in modules". Anyway, masak++ and mberends++ for having the patience and diligence to take on something that we really need a finalish answer on, amongst all the various opinions people have on how it should be done. I'm hopeful that we're now approaching the point where we have something that works for the vast majority of use cases, and the answer to anyone who it doesn't work for is simply, "go write a module".</p><p>Anyway, that was The Easter Hackathon! For those not following the commits, I'm happy to report that others are also committing bits here and there, and we're steadily working towards brining you Rakudo *.<nobr> <wbr></nobr>:-)</p> JonathanWorthington 2010-04-08T23:59:06+00:00 journal A quick Rakudo update http://use.perl.org/~JonathanWorthington/journal/40258?from=rss <p>The last week has brought some <a href="http://use.perl.org/~pmichaud/journal/40248">sad news</a>. While software is of course insignificant compared to life and health, and it's absolutely right that at this time Rakudo should be the last thing Pm should be worrying about, I know a lot of people will be wondering what this means for the Rakudo * release. Myself and the other Rakudo developers are still working out the exact details, but here's an overview.</p><ul> <li>Rakudo * will be delayed in the "not in late April" sense. We all agree on this. There's no way you can take the lead developer of a project away, when the overall team isn't that big anyway, and expect to deliver the same product on the same schedule.</li><li>While I've always stated Q2 in my talks, we've also always had an internal target date of April. Of course, this is open source so nothing is internal, and April has been widely latched on to.<nobr> <wbr></nobr>:-) We're sticking with the Q2 goal, but now expect to deliver in May or June (preferably, before YAPC::NA<nobr> <wbr></nobr>:-)).</li><li>While we do of course greatly miss Pm's company, direction, and code, I'm comfortable that there's not anything on the Rakudo * ROADMAP that absolutely blocks on Pm. There's things that are harder for the rest of us to do, but we've actually tackled some of them head-on in the last several days, and now have first cuts of many of them - or in some cases are virtually done with them.</li></ul><p>There's been a lot of exciting progress in Rakudo recently - the ChangeLog for the last release gives a bunch of it, but we've done a whole load more since then too. I'll try and blog about some of it soonish. In the meantime, I'd like to thank all of the Rakudo and Perl 6 team for being amazing to work with on this, and my thoughts and prayers are with Pm and Paula.</p> JonathanWorthington 2010-03-22T01:09:03+00:00 journal Bad news, revisited http://use.perl.org/~pmichaud/journal/40248?from=rss <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. http://use.perl.org/~pmichaud/journal/35389<br>2. http://use.perl.org/~pmichaud/journal/37315</p> pmichaud 2010-03-17T04:32:16+00:00 journal My life refactored, Zavolaj, workshops, Rakudo and more! http://use.perl.org/~JonathanWorthington/journal/40247?from=rss <p>It's been a while since I scribbled anything here, so a few quick updates.</p><p>First, an update on me. Since last time I wrote, I've moved country. Yup, I actually left behind my beloved Bratislava and I'm now hacking from Lund in Sweden. The beer - like everything else - is more expensive, and I don't have views of a beautiful city castle from my apartment here. But the city is overall very pleasant, I'm located a short walk to the center and the train station, and the supermarkets have a great range of international nom (and HP sauce!) I've yet to try the nearby curry house, or any of the other many appealing restaurants here, but I'm optimistic there will be plenty of WIN. Anyway, here's hoping I can get nicely settled down here.</p><p>I was greatly assisted with the move to Sweden by Perl 6 hacker Martin Berends, to whom I am extremely grateful. On the way, we went via the Netherlands Perl Workshop. I gave a couple of talks; I'll get the slides online shortly. It was really lovely to be at the Netherlands Perl Workshop again - the atmosphere was every bit as warm and friendly as I remembered from the last time. To everyone who organized and attended: thanks for a wonderful couple of days.<nobr> <wbr></nobr>:-)</p><p>In the couple of days before the move and during the NPW, mberends++ and I hacked on a shiny new project: <a href="http://github.com/jnthn/zavolaj/">Zavolaj!</a> It is a way of doing native calls from Perl 6, just by adding a trait to a stub subroutine, and is a first draft for native calling in Perl 6. The upshot is that we now have a working MySQL client written using Zavolaj, in pure Perl 6! mberends++ is continuing to build this out, and happily this all means that Rakudo * will ship with database access, amongst other things. (I've also done an example of calling a Win32 API, and we're both pondering an ImageMagick binding with it too).</p><p>My first days in Scandinavia were actually mostly spent in Copenhagen, at a Perl 6 hackathon organized by Copenhagen.pm - a group I hope to drop in on now and then, since I'm only an hour or so's train ride away. There's a wonderful <a href="http://perlgeek.de/blog-en/perl-6/copenhagen-hackathon.html">write-up by moritz++</a> that tells a lot of what went on, and I can only echo his sentiments about how much fun it was to hack and hang out in meat space with other Perl 6 folks. I'm already looking forward to the next time we get to do that!</p><p>Rakudo wise, the work goes on at a good pace. I've been working on lots of bits, and colomon++ has been having quite the patch fest too. The release later this week is a good step forward from last month's release, which was the first after the ng branch was merged. We've won back a lot of functionality again, and this is the first release ever that has some basic support for versioned modules - a direct consequence of the hackathon - and also regexes taking parameters, thanks to a patch from bkeeler++.</p><p>Anyway, that's all for now. Only to note that I expect to be making it to the Nordic Perl Workshop in Iceland in May, and with a bit of luck to the Perl workshops in France and Ukraine too (will take some fun logistics to do the two, but I did miss the French Perl Workshop last year, and I always really love to visit Ukraine, so I'll try and work out a way). Have fun, and I'll try and blog again soonish!</p> JonathanWorthington 2010-03-16T00:48:36+00:00 journal Gone http://use.perl.org/~Ovid/journal/40243?from=rss <p>Like many others, I'm no longer posting here very much. You'll find my new technical journal at <a href="http://blogs.perl.org/users/ovid/">blogs.perl.org</a>. It's much shinier.</p><p> <a href="http://siteanalytics.compete.com/use.perl.org/">As you can see, use.perl visits have been dropping for a while</a> (blogs.perl.org is too new to show up on that search) and the <a href="http://use.perl.org/">front page of use.perl has been sadly neglected</a>. As for blogs.perl.org, after an initial rough start, <a href="http://blogs.perl.org/users/adam_kennedy/2009/12/migrating-from-useperlorg-to-blogsperlorg.html">plenty</a> <a href="http://blogs.perl.org/users/thefinalcut/2009/12/first-post-on-the-shiny-new-onion.html">of</a> <a href="http://blogs.perl.org/users/limbicregion/2009/11/goodbye-useperlorg-hello-blogsperlorg.html">people</a> are switching over and are very happy with the shiny.</p><p>I have fond memories of use.perl.org, but it's just too old and out-of-date. Come on over to our new platform and look around. Plus, <a href="http://github.com/davorg/blogs.perl.org/issues">tell us what you want changed about it</a>. (To be fair, while I was involved in the project to get it launched (mostly kibitzing and asking why things were stalled -- I'm such a marketroid<nobr> <wbr></nobr>:), the hands-on work was Dave Cross, Aaron Crane and the wonderful folks at <a href="http://www.sixapart.com/">SixApart</a>.)</p> Ovid 2010-03-14T08:02:43+00:00 journal Unpacking data structures with signatures http://use.perl.org/~JonathanWorthington/journal/40196?from=rss <p>My signature improvements Hague Grant is pretty much wrapped up. I wrote a couple of posts already about the new signature binder and also about signature introspection. In this post I want to talk about some of the other cool stuff I've been working on as part of it.</p><p>First, a little background. When you make a call in Perl 6, the arguments are packaged up into a data structure called a capture. A capture contains an arrayish part (for positional parameters) and a hashish part (for smok^Wnamed parameters). The thing you're calling has a signature, which essentially describes where we want the data from a capture to end up. The signature binder is the chunk of code that takes a capture and a signature as inputs, and maps things in the capture to - most of the time, anyway - variables in the lexpad, according to the names given in the signature.</p><p>Where things get interesting is that if you take a parameter and coerce it to a Capture, then you can bind that too against a signature. And it so turns out that Perl 6 allows you to write a signature within another signature just for this very purpose. Let's take a look.</p><p> <code>multi quicksort([$pivot, *@values]) {<br> &nbsp;&nbsp;&nbsp;&nbsp;my @before = @values.grep({ $^n &lt; $pivot });<br> &nbsp;&nbsp;&nbsp;&nbsp;my @after = @values.grep({ $^n &gt;= $pivot });<br> &nbsp;&nbsp;&nbsp;&nbsp;(quicksort(@before), $pivot, quicksort(@after))<br> }<br> multi quicksort( [] ) { () }<br> </code> </p><p>Here, instead of writing an array in the signature, we use [...] to specify we want a sub-signature. The binder takes the incoming array and coerces it into a Capture, which essentially flattens it out. We then bind the sub-signature against it, which puts the first item in the incoming array into $pivot and the rest into @values. We then just partition the values and recurse.</p><p>The second multi candidate has a nested empty signature, which binds only if the capture is empty. Thus when we have an empty list, we end up there, since the first candidate requires at least one item to bind to $pivot. Multi-dispatch is smart enough to know about sub-signatures and treat them like constraints, which means that you can now use multi-dispatch to distinguish between the deeper structure of your incoming parameters. So, to try it out...</p><p> <code>my @unsorted = 1, 9, 28, 3, -9, 10;<br> my @sorted = quicksort(@unsorted);<br> say @sorted.perl; # [-9, 1, 3, 9, 10, 28]<br> </code> </p><p>It's not just for lists either. An incoming hash can be unpacked as if it had named parameters; for that write the nested signature in (...) rather than [...] (we could have use (...) above too, but [...] implies we expect to be passed a Positional). For any other object, we coerce to a capture by looking at all of the public attributes (things declared has $.foo) up the class hierarchy and making those available as named parameters. Here's an example.</p><p> <code>class TreeNode { has $.left; has $.right; }<br> sub unpack(TreeNode $node (:$left,<nobr> <wbr></nobr>:$right)) {<br> &nbsp;&nbsp;&nbsp;&nbsp;say "Node has L: $left, R: $right";<br> }<br> unpack(TreeNode.new(left =&gt; 42, right =&gt; 99));<br> </code> </p><p>This outputs:</p><p> <code>Node has L: 42, R: 99<br> </code> </p><p>You can probably imagine that a multi and some constraints on the branches gives you some interesting possibilities in writing tree transversals. Also fun is that you can also unpack return values. When you write things like:</p><p> <code>my ($a, $b) = foo();<br> </code> </p><p>Then you get list assignment. No surprises there. What maybe will surprise you a bit is that Perl 6 actually parses a signature after the my, not just a list of variables. There's a few reasons for that, not least that you can put different type constraints on the variables too. I've referred to signature binding a lot, and it turns out that if instead of writing the assignment operator you write the binding operator, you get signature binding semantics. Which means...you can do unpacks on return values too. So assuming the same TreeNode class:</p><p> <code>sub foo() {<br> &nbsp;&nbsp;&nbsp;&nbsp;return TreeNode.new(left =&gt; 'lol', right =&gt; 'rofl');<br> }<br> my ($node (:$left,<nobr> <wbr></nobr>:$right))<nobr> <wbr></nobr>:= foo();<br> say "Node has L: $left, R: $right";<br> </code> </p><p>This, as you might have guessed, outputs:</p><p> <code>Node has L: lol, R: rofl<br> </code> </p><p>Note that if you didn't need the $node, you could just omit it (put keep the things that follow nested in another level of parentheses). This works with some built-in classes too, by the way.</p><p>It works for some built-in types with accessors too:</p><p> <code>sub frac() { return 2/3; }<br> my ((:$numerator,<nobr> <wbr></nobr>:$denominator))<nobr> <wbr></nobr>:= frac();<br> say "$numerator, $denominator";<br> </code> </p><p>Have fun, be creative, submit bugs.<nobr> <wbr></nobr>:-)</p> JonathanWorthington 2010-02-20T00:21:50+00:00 journal The first release from ng is coming! http://use.perl.org/~JonathanWorthington/journal/40190?from=rss <p>Tomorrow's regularly scheduled Rakudo release is the first one since the long-running "ng" branch became master. It represents both a huge step forward and at the same time a fairly major regression. Internally, the changes are enormous; some of the biggest include:</p><ul> <li>We're parsing using a new implementation of Perl 6 regexes by pmichaud++. It is a huge improvement, supporting amongst other things protoregexes, a basic form of LTM, variable declarations - including contextuals - inside regexes and more. The AST it generates is part of the PAST tree rather than having a distinct AST, which is a neater, more hackable approach. The issues with lexical scopes and regexes are resolved. Closures in regexes work.</li><li>NQP is also re-built atop of this. It incorporates regex and grammar support, so now we run both grammar and actions through the one compiler. It's bootstrapped.</li><li>In light of those major changes, we started putting the grammar back together from scratch. A large part of this was copy and paste - from STD.pm. The grammar we have now is far, far closer to STD than what we had before. Operator precedence parsing is handled in the same kind of way. We've started to incorporate some of the nice STD error detection bits, and catch and nicely report some Perl 5-isms.</li><li>Since the grammar got re-done, we've been taking the same approach with the actions (the methods that take parse tree nodes and make AST nodes). Thanks to contextual variable support and other improvements, a lot of stuff got WAY cleaner.</li><li>The list/array implementation has been done over, and this time it's lazy. There's certainly rough edges, but it's getting better every day. The work to implement laziness has led to many areas of the spec getting fleshed out, too - a consequence of being the first implementation on the scene I guess.</li><li>All class and role construction is done through a meta-model rather than "magic". The Parrot role composition algorithm is no longer relied upon, instead we have our own implementation mostly written in NQP.</li><li>The assignment model was improved to do much less copying, so we should potentially perform a bit better there.</li><li>Lexical handling was refactored somewhat, and the changes should eliminate a common source of those pesky Null PMC Access errors.</li></ul><p>Every one of these - and some others I didn't mention - are important for getting us towards the Rakudo * release. The downside is that since we've essentially taken Rakudo apart and put it back together again - albeit on far, far better foundations - we're still some way from getting all of the language constructs, built-in types and functions back in place that we had before. It's often not just a case of copy-paste; many of the list related things now have to be written with laziness in mind, for example.</p><p>So anyway, if you download tomorrow's release and your code doesn't compile or run, this post should explain - at least at a higher level - why. After a slower December and January, Rakudo development has now once again picked up an incredible pace, and the last couple of week's efforts by many Rakudo hackers have made this release far better than I had feared it was going to be. If we can keep this up, the March release should be a very exciting one.</p> JonathanWorthington 2010-02-18T01:18:33+00:00 journal Catching up: two Rakudo Days from December http://use.perl.org/~JonathanWorthington/journal/40161?from=rss <p>Today plenty happened in Rakudo land - in fact, it was my most active day's Rakudo hacking in quite a while. colomon++ also made some great commits, and between us a lot of things moved forward today. For my part, hashes and pairs are in much better shape.</p><p>I wrote before that I'd got some Rakudo days left to write up; there are two of them, but I'll cover them both in this post, since some of the work crossed the two of them anyway. Here's what I got up to between them.</p><ul> <li>Filled out attribute composition logic for role application. A good chunk of this was written in NQP - in fact, all of the role appliers are.<nobr> <wbr></nobr>:-) Along the way I brought roles up to speed with the attribute part of the meta-object protocol - I'd forgotten that when doing it for classes, though since we couldn't compose attributes at that time it wasn't so interesting anyway. The end result was that we could pass S14-role/attributes.t again.</li><li>The specification states that if in a role you do inheritance, then this is just passed on to the class that the role is eventually composed in to, and added to that class's parents. We never had any support for this in master; with a neat meta-model approach it became rather easier to get it in place in ng.</li><li>Got BUILD/CREATE fixed up a bit and added back support for "has $.answer = 42" style declarations, again through the new attribute sub-protocol.</li><li>Got us handling non-block where blocks again, and added Block.ACCEPTS back - in Perl 6.</li><li>We had various "helpers" to let us do some of the low-levelish stuff in PIR. This is mostly for the places where we need those things in place in order to be able to compile the rest of the built-ins that are written in Perl 6. However, a couple of these helpers knew too much about Parrot and too little about the meta-model, which abstracts it away. So, I re-wrote some of those in terms of the meta-model. Much cleaner.</li><li>Before we relied entirely on Parrot for our "do we do this role" checks. However, given the unfortunate semantic mis-match between Parrot's built-in role support and what we need for Perl 6 (I did try and influence things in a different direction back when we were doing Parrot's role support, but failed), I've been gradually working us towards not relying on those for Perl 6's role support. (In master, it felt to me like we have almost as much code working around the semantics of Parrot roles as we'll need to have to not use them.) Anyways, the divorce isn't quite complete yet, and it's not even a goal for the ng branch. However, I did make a notable step towards it by getting our<nobr> <wbr></nobr>.does checks implemented entirely in terms of the meta-model. In the long run, I'm hoping we may be able to write the entire role implementation in NQP, which helps with the even-longer-run dreams I have of Rakudo having additional backends. But that's for The Future.<nobr> <wbr></nobr>:-)</li><li>Cleaned up and re-enabled sigil based type checking in signatures.</li></ul><p>Thanks to Vienna.pm for sponsoring me to hack on Rakudo, not only for these two days, but also throughout 2009!</p> JonathanWorthington 2010-02-06T22:45:42+00:00 journal The importance of a break http://use.perl.org/~JonathanWorthington/journal/40160?from=rss <p>Several days before Christmas, encouraged by my mum asking, "when you're going to start your Christmas break", I stopped working and hacking on stuff and started relaxing. Until then, I hadn't realized just how tired I was. I slept quite a few ten hour nights in the following week, and had an enjoyable Christmas break. I'd figured I'd maybe take a week or so's break, and then get straight back to things, but a week on I had no motivation or energy to dig in again whatsoever. So, I decided my break would go on through New Years. New Year's celebrations this year involved curry - something I certainly wouldn't mind it involving again.</p><p>Early January brought several days in Sweden, part of planning for an upcoming refactoring of my work/location - there's <a href="http://www.jnthn.net/cgi-bin/blog_read.pl?id=713">details on my personal blog</a>, but the short version is that I've accepted a job at a Swedish startup and will be moving there in March. It's not full time, so I'll continue to have time for Perl 6 development. They know about and, happily, are supportive of my involvement in Perl 6 and my continued attendance of Perl conferences.</p><p>I spent a weekend in Prague on the way home. I did it by train rather than flying, which was enjoyable. It snowed almost my entire time in Prague, and I caught a cold in the following week, but it was kinda worth it to wander around this beautiful city. Didn't bother studying Czech at all, and sorta got by with speaking Slovak, though some folks heard me speak and immediately concluded English would be easier.<nobr> <wbr></nobr>:-) Somehow it kinda felt like I was back somewhere I belonged, even though I'd never been there before. I love central Europe, and excited as I am about Sweden, I know I'll miss this part of the world a lot.</p><p>Anyway, I eased back into some work in January, but mostly took it quite easy. The happy result is that, come February, I'm finding myself recharged and ready to dig back into things again. I got some nice commits done to Rakudo yesterday, and today I meant to, but instead participated on an interesting thread on p6l and did some other useful meta stuff (like this post). Tomorrow should have plenty of hacking time though, and I'm looking forward to it. I also have a couple of blog posts to do about Vienna.pm-funded Rakudo Days I did in December, but never got around to writing up; thankfully I did make notes on what I did on them.<nobr> <wbr></nobr>:-) My main focuses from here on will be on:</p><ul> <li>Continuing to get Rakudo's ng branch into shape - we'll make it master soon. A lot is missing, but things are going back fast and often very neatly. It's easy to focus on what it doesn't yet do that master does, but it has many things right that master does not - now including laziness!</li><li>Finishing up my signatures grant. I really, really want to do that within the next couple of weeks.</li></ul><p>Anyway, that's what's been up with me. If you take away anything, it's that you may not realize how much you need a break from something until you take it, and if it's not the only thing putting food on the table, then it's probably better to take the needed amount of break and come back revitalized. I guess the other option is to dig back in regardless, but I suspect that's the path to burnout, something I'm quite keen to avoid.</p><p>More technical blabbering here soon.<nobr> <wbr></nobr>:-)</p> JonathanWorthington 2010-02-06T00:31:49+00:00 journal Test::Class::Most http://use.perl.org/~Ovid/journal/40148?from=rss <a href="http://blogs.perl.org/users/ovid/2010/01/-package-sometestclass.html">Test::Class::Most</a>. Ovid 2010-01-31T19:25:10+00:00 journal Testing with PostgreSQL http://use.perl.org/~Ovid/journal/40145?from=rss <p>My new personal project has a PostgreSQL database. <a href="http://blogs.perl.org/users/ovid/2010/01/testing-postgresql.html">Here's how I'm handling testing</a>.</p> Ovid 2010-01-30T16:22:57+00:00 journal Roles without Moose? http://use.perl.org/~Ovid/journal/40127?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/roles-without-moose.html">Milliseconds are important</a>.</p> Ovid 2010-01-25T14:04:31+00:00 journal Unless what? http://use.perl.org/~Ovid/journal/40103?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/unless-what.html">Unless what?</a> </p> Ovid 2010-01-15T11:47:53+00:00 journal Dear Recruiters http://use.perl.org/~Ovid/journal/40100?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/dear-recruiters.html">Dear Recruiters</a> </p> Ovid 2010-01-13T13:06:11+00:00 journal Next QA Hackathon -- What Do You Need? http://use.perl.org/~Ovid/journal/40093?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/next-qa-hackathon----what-do-you-need.html">Read about the next QA Hackathon</a>.</p> Ovid 2010-01-12T11:37:14+00:00 journal Most Popular Testing Modules - January 2010 http://use.perl.org/~Ovid/journal/40086?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/most-popular-testing-modules---january-2010.html">Most popular testing modules as of January 2010</a> </p> Ovid 2010-01-07T21:46:46+00:00 journal Cool Things in Perl 6: Subsets http://use.perl.org/~Ovid/journal/40072?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/cool-things-in-perl-6.html">They're going to be a lot of fun</a>.</p> Ovid 2010-01-04T13:11:31+00:00 journal Perl 6 Config::INI parser on github http://use.perl.org/~Ovid/journal/40060?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2009/12/perl-6-configini-on-github.html">Details here</a>.</p> Ovid 2009-12-30T17:48:47+00:00 journal Improve My Perl 6! http://use.perl.org/~Ovid/journal/40051?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2009/12/improve-my-perl-6.html">Collaborative filtering (user recommendations) in Perl 6</a>.</p> Ovid 2009-12-24T11:29:45+00:00 journal Gitpan languages http://use.perl.org/~Ovid/journal/40036?from=rss <p>What? You didn't know that <a href="http://blogs.perl.org/users/ovid/2009/12/gitpan-languages.html">SOAP::Lite was written in Visual Basic</a>?</p> Ovid 2009-12-18T14:15:32+00:00 journal Atom Feed Help http://use.perl.org/~Ovid/journal/40029?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2009/12/atom-feed-help.html">Atom feed help requested</a> </p> Ovid 2009-12-17T10:40:35+00:00 journal MySQL and Oracle http://use.perl.org/~Ovid/journal/40020?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2009/12/mysql-and-oracle.html">MySQL and Oracle</a>. (Despite teething pains, blogs.perl.org is holding up quite well on the new server)</p> Ovid 2009-12-14T12:56:02+00:00 journal