chromatic's Journal http://use.perl.org/~chromatic/journal/ chromatic'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-25T02:01:04+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 chromatic's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~chromatic/journal/ Perl 6 Design Minutes for 30 June 2010 http://use.perl.org/~chromatic/journal/40433?from=rss <p>The Perl 6 design team met by phone on 30 June 2010. Allison, Patrick, and chromatic attended.</p><p> <strong>Allison:</strong> </p><ul> <li>working on Parrot packages for Debian experimental</li><li>seems like a good idea to do that before the 2.6 supported release</li><li>there was also a request for Rakudo packages</li><li>not sure if I'm the best person to do it</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I'm sure we should package Rakudo Star</li></ul><p> <strong>Allison:</strong> </p><ul> <li>Debian had a packager for those, but I haven't looked at the packages</li><li>this'd be an early run of what we'll do with Rakudo Star</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>we're not quite ready for packaging that yet</li><li>maybe a couple of weeks</li><li>finished the <code>List</code> and <code>Iterator</code> types for the #30 release</li><li>adjusted Rakudo's <code>Associative</code> and <code>Positional</code> roles</li><li>much cleaner implementation now</li><li>that'll require a few small spec changes</li><li>redid Rakudo's container types</li><li>more robust</li><li>preparing for autovivification of hashes and arrays</li><li>expect to finish those in the next couple of days</li><li>there was no container model previously; the code was consequently crufty</li><li>lots of cleanup of incorrect assumptions</li><li>Rakudo lists are now properly lazy</li><li>comment syntax fixed</li><li>ROADMAP updated</li><li>fixed the meaning of <code>Nil</code>; it's defined, not undefined</li><li>added the sink prefix (?)</li><li>fixed setting of <code>$!</code> </li><li>started fixing bugs and closing tickets on Monday, did 15 or 20</li><li>mostly already fixed in the previous couple of weeks</li><li>looking at the implementation of the series operator</li><li>spec is self-contradictory or ambiguous or both</li><li>waiting for Larry's clarification</li><li>fixed a bug in <code>$*ARGFILES</code> </li><li>had a nice contribution of that implementation last week</li><li>that behavior works on any set of files, not just those on the command line</li><li>working on autoviv</li><li>have some regex backtracking bugs to fix</li><li>will work on closures after that</li><li>put together three new YAPC presentations</li><li>the Rakudo Star presentation will become a video cast or a blog post or both</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on a slew of Parrot optimizations for Rakudo</li><li>have a few more to go</li><li>might have to create a Rakudo branch temporarily</li><li>will try to help merge the new GC</li><li>working on a metamodel for Parrot objects, informed by Perl 6 and Moose</li></ul> chromatic 2010-07-03T08:13:30+00:00 journal Modern Perl: The (Draft) Book http://use.perl.org/~chromatic/journal/40423?from=rss <p>This took longer than I expected, but <a href="http://www.modernperlbooks.com/mt/2010/06/modern-perl-the-book-the-draft.html">the draft of the Modern Perl book is available for review</a>. I'm especially interested in hearing from people who don't consider themselves expert Perl 5 programmers. The goal of the book is to explain how Perl 5 works (and how to write Perl 5 effectively) to help novices become adepts.</p> chromatic 2010-06-28T23:43:33+00:00 journal Perl 6 Design Minutes for 16 June 2010 http://use.perl.org/~chromatic/journal/40419?from=rss <p>The Perl 6 design team met by phone on 16 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>documented <code>TOP</code> (again), and explained how parsing is initiated and how it actually works</li><li>series operator (<code>...</code>) now picks a monotonic function when using single characters as endpoints</li><li>STD can now catch duplicates involving <code>proto</code>s as well as <code>only</code>s</li><li>STD no longer advises removal of parens on spaceless <code>sub()</code> declaration</li><li>mostly advised sorear and pmichaud</li><li>Stefan is finishing the boostrap of the STD parser</li><li>also working on adding a parallel NFA and DFA engine</li><li>no, he doesn't want to generate all the states in advance</li><li>it works faster lazily</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on chroot environments with something more secure than chroot</li><li>relevant to building Parrot packages</li><li>looking at some bugs for Will</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>Rakudo developers decided not to make extra special effort to make a June release of Rakudo Star</li><li>the calendar works against us</li><li>the new date for the release is July 29</li><li>we're I comfortable with hitting that target</li><li>we won't be happy with the results of moving heaven and earth to release in June</li><li>there are lots of advantages</li><li>one disadvantage is not having Rakudo Star at YAPC::NA</li><li>one big advantage is using the supported Parrot 2.6 release as the basis</li><li>I'll write a post outlining the plan in the next couple of days</li><li>otherwise working on lists and interators in Perl 6 and Rakudo</li><li>after deciding to make iterators immutable, Larry and I realized that solves many problems</li><li>everything works out as plain as day after that</li><li>very happy with that design</li><li>the incorrect assumptions of the old model were pervasive</li><li>replacing the old pieces is taking a while, which is no surprise</li><li>this approach feels right though</li><li>the new branch does things no previous version could do</li><li>slices work much better, for example</li><li>metaoperators work properly</li><li>map is lazy</li><li>slurpy arguments in lists are lazy by default</li><li>no weird binding or action at a distance problems</li><li>plenty of changes to <code>Associative</code> and <code>Positional</code> roles</li><li>those are now super clean and may be lazy</li><li>more features work</li><li>~30 failing tests (not test files, just tests) now, ~500 last night</li><li>most of the current failures are minor</li><li>will try to merge the branch before the release</li><li>replacing lots of ugly code with fewer lines of elegant code</li><li>Jonathan and others have worked on lots of other pieces</li><li>adding plenty of new features</li><li>looking forward to tomorrow's release</li></ul><p> <strong>c:</strong> </p><ul> <li>editing the Rakudo book</li><li>moving the Rakudo release date may let us have a printed book available about the same time</li><li>depends on how much there is left to write</li></ul> chromatic 2010-06-26T17:07:30+00:00 journal Perl 6 Design Minutes for 09 June 2010 http://use.perl.org/~chromatic/journal/40415?from=rss <p>The Perl 6 design team met by phone on 09 June 2010. Larry, Allison, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>not much spec change this week</li><li>figured out a syntax for a regex block to return more than one cursor</li><li>based on <code>gather</code>/<code>take</code> </li><li>in STD hacking, continued to assist Stefan O'Rear in getting STD bootstrapped via viv</li><li>now that it's bootstrapped, we're refactoring things that make sense now</li><li>we're now starting to move bits of Cursor code from Perl 5 into Perl 6</li><li>refactoring the grammar for sanity of design</li><li>started upgrading STD to normal Perl 6 syntax where it previously catered to <code>gimme5</code>'s limitations</li><li>for example, switched STD's old<nobr> <wbr></nobr><code>.&lt;_from&gt;</code> and<nobr> <wbr></nobr><code>.&lt;_pos&gt;</code> hash lookups to using<nobr> <wbr></nobr><code>.from</code> and<nobr> <wbr></nobr><code>.pos</code> accessors</li><li>started the prep work for moving <code>EXPR</code> out of <code>STD</code> to make it generally available to any grammar wanting operator precedence</li><li>in STD parsing, made Perl 5 <code>$&lt;</code> detection have a longer token to avoid confusion with match variables</li><li>STD no longer attempts two-terms detection on <code>infix_circumfix_meta_operator</code> </li><li>STD now parses <code>&gt;&gt;R~&lt;&lt;</code> correctly, or at least dwimmily</li><li>STD doesn't complain about P5isms in <code>printf</code> formats like <code>"%{$count}s"</code> </li><li>STD was parsing<nobr> <wbr></nobr><code>/m</code> and<nobr> <wbr></nobr><code>/s</code> with the opposite semantics</li><li> <code>termish</code> now localizes <code>$*MULTINESS</code> in its scope so that inner declarations aren't accidentally multified</li><li>STD now carps about <code>package Foo;</code> as a Perl 5 construct</li></ul><p> <strong>Allison:</strong> </p><ul> <li>talked to Chris Shiflett, a PHP developer, on someone from the PHP community to sit on the Parrot board</li><li>will be in the US for a few weeks</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on list simplification</li><li>had a couple of breakthrough ideas on Monday</li><li>working on the implementation now</li><li>worked out inversion lists for character class matching in regexes</li><li>will make them faster, especially with long ranges of character classes</li><li>fixed a half-dozen tickets in RT</li><li>fixed Rakudo hash constructors</li><li>fixed an intermittent bug with colon-pair signatures</li><li>two possible parses exist in STD, but we removed an unneeded one in Rakudo</li><li>fixed a bug with Parrot's <code>exit</code> opcode</li><li>NQP and PAST needed an update not to cheat with PASM constants</li><li>I fixed that too</li><li>Vasily added multisub and multimethod support to NQP, that was a big plus</li><li>fixed the <code>**</code> quantifier in regexes to understand surrounding whitespace</li><li>regex engine tried to match beyond the end of a string, so I added guards for that</li><li>will work on lists furiously before the next release</li><li>I don't think it'll take long</li><li>closures are next, hope to have those in place by the weekend</li></ul><p> <strong>c:</strong> </p><ul> <li>released a new version of Pod::PseudoPod::LaTeX to support the various books in progress</li></ul> chromatic 2010-06-24T12:24:33+00:00 journal Perl 6 Design Minutes for 02 June 2010 http://use.perl.org/~chromatic/journal/40410?from=rss <p>The Perl 6 design team met by phone on 02 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>mostly, I supported sorear in bootstrapping STD to use <code>viv</code> instead of <code>gimme5</code> </li><li>his stage 2 and stage 3 now output identical Perl 5 versions of STD</li><li>produces a huge amount of warnings</li><li>appears to require Perl 5.12 at the moment</li><li>working on both of those</li><li>S03 refines hyper dwimminess to be more like APL, with modular semantics</li><li>S02 refines <code>Blob</code>s to simply be immutable <code>Buf</code>s, with similar generic characteristics</li><li>S02 now describes native <code>blob</code> types</li><li>implemented post-declaration checks for <code>BEGIN</code> and <code>use</code>, since those can't wait for end of file</li><li>STD no longer loses existing bindings when we go to a sublanguage</li><li>STD now uses <code>$*GOAL</code> variable only as informative, never as a "stopper"</li><li>instead, we create a <code>&lt;stopper&gt;</code> rule for <code>$*GOAL</code> if necessary</li><li>can check for that only, instead of that or <code>$*GOAL</code> </li><li>answering lots of questions on how STD and <code>viv</code> work besides that</li></ul><p> <strong>Allison:</strong> </p><ul> <li>did a lot of research on graph color algorithms for register usage algorithms</li><li>will finish my finals on Monday</li></ul><p> <strong>Will:</strong> </p><ul> <li>trying to herd the discussion of dynop libraries</li><li>a recent branch to close an old ticket broke a lot of assumptions</li><li>some bugs have become more visible because of these changes</li><li>hope to get that cleaned up this week</li></ul><p> <strong>Allison:</strong> </p><ul> <li>I liked your suggestion of bringing back the <code>getstderr</code> and related opcodes</li></ul><p> <strong>Will:</strong> </p><ul> <li>trying to resurrect Partcl</li><li>stuck on a TT #389 closing issue</li><li>not sure how to fix that, the way things are now</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on the iterator and list design</li><li>brainstorming the implementation</li><li>will implement somethine one way or another this week</li><li>people keep implementing workarounds for the current system</li><li>they'll bite us eventually</li><li>Moritz and I worked on making the regex engine returning real Perl 6 objects</li><li>that mostly works</li><li>exposes some places where lists don't work exactly right</li><li>the workarounds there made me replan the list and iterator implementation</li><li>answered some questions online</li><li>Jonathan added a better backtrace algorithm for Rakudo</li><li>reports Perl 6 source lines instead of PIR lines</li><li>I'll review his code</li><li>think I can borrow it for NQP for all HLLs</li><li>Jonathan reports that it was a lot easier in NQP than PIR</li></ul><p> <strong>c:</strong> </p><ul> <li>trying to answer a few Parrot design questions</li><li>looking at the continuation of design from Perl 1 - 4 to Perl 5 and Perl 6</li><li>hope to have coding time soon</li></ul> chromatic 2010-06-22T01:12:29+00:00 journal Perl 6 Design Minutes for 26 May 2010 http://use.perl.org/~chromatic/journal/40408?from=rss <p>The Perl 6 design team met by phone on 26 May 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li><nobr> <wbr></nobr><code>:()</code> syntax is now always signature</li><li>we now use <code>foofix:[...]</code> as the general op form instead of <code>foofix:(...)</code> </li><li>refactored the sematics of<nobr> <wbr></nobr><code>:nth</code> and<nobr> <wbr></nobr><code>:x</code> </li><li><nobr> <wbr></nobr><code>:nth()</code> now only ever takes a monotonically increasing list</li><li>S03 now explains how "not-raising" works on <code>!=</code> and <code>ne</code> </li><li>it now basically matches the intuitions of an English speaker via HOP definition of negate metaop</li><li>STD sometimes didn't require semi between statements</li><li>statement modifiers are expression terminators but not valid statement terminators</li><li>an unexpected statement modifier word like <code>if</code> could terminate one statement and start another</li><li>fixed up backslashes in character classes to allow <code>\s</code> etc and reject <code>\u</code> etc</li><li>STD was accidentally using the same lexpad for different multis</li><li>Cursor now treats<nobr> <wbr></nobr><code>:()</code> on name extension as a signature always, never as a categorical</li><li>we shouldn't introduce the stopper for circumfix until we're in the circumfix, or we can't use the same char on both ends</li><li>placeholder messages error messages are now much more informative and correct</li><li>we now disallow use of placeholder after same variable has been used as a non-placeholder, even for an outer reference</li><li>renamed add_macro (which it doesn't) to add_categorical (which it does)</li><li>participating frequently in discussions on semantics both on irc and p6l</li><li>working closely with sorear++ as he brings viv closer to bootstrapping, yay!</li><li>soon can bootstrap past gimme5</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on Pynie this week in my limited spare time</li><li>one goal is to generate the parser directly from the Python grammar</li><li>wrote a small, lightweight PEG parser which generates a match tree from the Python 3 grammar</li><li>can generate a lexer directly</li><li>right now it creates a parse tree</li><li>looks similar to the match nodes of NQP-rx</li><li>dumps out a tree to the PIR parser</li><li>working on PaFo elections for next year, but trying to delegate those</li><li>will have more time after June 7</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on Perl 6 advent tests</li><li>many more people are doing more work than me</li><li>liasing with Rakudo folks for any important Parrot bugs before the Rakudo Star release</li><li>my current direction there is "don't break anything"</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>sorear added hash flattening to NQP</li><li>lots of work on closures in PAST and NQP</li><li>they properly clone</li><li>fixes some lexical problems</li><li>need to get that to work in Rakudo</li><li>that's tougher; Rakudo has to wrap Parrot subs</li><li>wrapper object needs cloning as well, along with its attributes</li><li>we'll add a new PAST node type to help</li><li>that node understands contexts</li><li>essentially a way to add void context optimizations to your AST</li><li>that solves many problems in Rakudo beyond closures</li><li>added a setting into NQP along with its test suite</li><li>not automatically loaded, but available</li><li>contains standard hash and array methods</li><li>Parrot's ops2c project uses those</li><li>other people can update and enhance that setting as necessary</li><li>NQP also has the ability to parse type names</li><li>NQP doesn't do anything with them yet</li><li>eventually they'll allow the use of multis</li><li>cleaning up some NQP bugs regarding lexicals and package storage of subs</li><li>Bruce Keeler enabled variable interpolations in regexes</li><li>working on some refactorings to simplify that approach</li><li>works in NQP and Rakudo now</li><li>that's a feature we've never had before</li><li>Rakudo's REPL now works better, thanks to sorear</li><li>HLLCompiler now written more in NQP as part of that</li><li>NQP now can do <code>eval</code> </li><li>NQP remembers lexicals in interactive mode now</li><li>adding that to Rakudo is more complex</li><li>working on that</li><li>pleased with the progress on #perl6</li></ul><p> <strong>c:</strong> </p><ul> <li>reviewing long term plans for GC and Lorito</li><li>should have more time free soon</li></ul> chromatic 2010-06-20T19:40:02+00:00 journal Perl 6 Design Minutes for 19 May 2010 http://use.perl.org/~chromatic/journal/40401?from=rss <p>The Perl 6 design team met by phone on 19 May 2010. Larry, Will, and chromatic attended. Patrick added his notes later.</p><p> <strong>Larry:</strong> </p><ul> <li>S03 makes more explicit that doctrine that <code>~~</code> topicalizes, and removes smartmatch table fossils that automatically fall out from that</li><li>S05 renames 'accent' to 'mark' for better Unicode conformance</li><li><nobr> <wbr></nobr><code>:a</code> and<nobr> <wbr></nobr><code>:aa</code> changed to<nobr> <wbr></nobr><code>:m</code> and<nobr> <wbr></nobr><code>:mm</code> </li><li>S05 disrequires retroactive semantics on<nobr> <wbr></nobr><code>:samecase</code> and<nobr> <wbr></nobr><code>:samemark</code> </li><li>the method form must now explicitly add case or mark modifiers to the pattern</li><li>regularized <code>mm//</code> to <code>ms//</code> to avoid confusion with new<nobr> <wbr></nobr><code>:m</code> ignoremark option</li><li>STD now does a bit better at diagnosing bogus <code>??!!</code> constructs of various sorts</li><li>STD now correctly adds operators to symbol tables as subs</li><li> <code>CORE.setting</code> now has protos of all the operators so they can be recognized as subs too</li><li>Cursor now canonicalize operator names in the symbol table</li><li>btw, not quite like specced</li><li>STD now reads user's mind on '<code>Str $toto</code>' to intuit missing declarator</li><li>STD now properly diagnoses a typename between routine declarator and sub name</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on code for Carl Masak, trying to get his poker code example running on Rakudo</li><li>both fun and frustrating</li><li>some stuff doesn't quite work yet</li><li>going through the Advent examples</li><li>adding them to spectests</li><li>make sure we won't regress on such public examples</li><li>other people are helping with that now</li></ul><p> <strong>c:</strong> </p><ul> <li>will get back to editing the Rakudo book soon</li><li>hope to have it in print by YAPC, but no guarantee</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>fixed closures in NQP, as a precursor for fixing them in Rakudo</li><li>worked with sorear on REPL in Rakudo and PCT in general</li><li>ported the NQP "standard library" done by japhb++, bacek++, and many others into the nqp-rx repository and made it part of the standard build sequence for nqp and Parrot</li><li>decided we need a new "context sensitive" node type in PAST, will be used to create proper closures and to handle sink context</li><li>worked with bacek on adding better multimethod support to PAST and nqp-rx</li><li>discovered a problem with lexical subs in NQP being automatically entered into the package namespace (and some existing code relying on this behavior)</li><li>did some initial fixes to at least get things entered properly, but a complete fix may require a deprecation cycle</li><li>plan to review others' patches this week</li><li>plan to fix REPL, closures, and sink context in Rakudo (since those are currently large pain points)</li><li>plan to work on loops and iterators after that</li></ul> chromatic 2010-06-16T21:38:09+00:00 journal Perl 6 Design Minutes for 12 May 2010 http://use.perl.org/~chromatic/journal/40400?from=rss <p>The Perl 6 design team met by phone on 12 May 2010. Larry, Allison, Patrick, and Will attended.</p><p> <strong>Larry:</strong> </p><ul> <li>clarified usage of brackets around infixes</li><li>added various 128-bit types to the spec; we might make them arbitrarily extensible via role</li><li>at least LLVM could support this, even to non-powers-of-two sizes</li><li>modernized the paleolithic grammatical category description in S02</li><li>STD now uses double-quote rules for interpolating <code>@foo[]</code> into regex</li><li>STD now gives better message on <code>1__3</code> </li><li>added the specced 128-bit types to CORE.setting</li><li>added <code>minmax</code> function to CORE.setting</li><li>implemented <code>circumfix:&#171;X Y&#187;</code> as grammar derivation</li><li>currently only allows a <code> &gt;&gt; inside</code></li><li>now also recognizes <code>foofix:("\x[face]")</code> and <code>foofix:("\c[YOUR CHARACTER HERE]")</code> without actually evaluating</li><li>playing with factoring <code>yaml</code> out of <code>gimme5</code>, since <code>viv</code> is not likely to go that route.</li><li>mostly just answered a lot of questions on irc</li><li>egged people on about concurrency issues</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>thought on handling closures properly</li><li>have a solution, just need some time to implement</li><li>discussion on changes to CodeString</li><li>work on compiler toolkit to avoid CodeString, using StringBuilder instead where possible, in PCT, NQP, and rakudo. Pretty easy, no downstream projects block on a deprecation issue</li><li>after that, lists</li><li>also been answering questions on interactive mode (REPL) for rakudo et al. (the issue with losing lexicals)</li></ul><p> <strong>Allison:</strong> </p><ul> <li>resolved the git conversation pretty well (for Parrot's repo migration)</li><li>worked on a pure PEG parser (following the paper), straight PIR, single day; now self-parsing. Interesting project, is lightweight. currently has memoization, but that might not be right for us because of backtracking. With some more effort, could probably handle EBNF form (useful for python)</li><li>could be setup for developer status for Debian which will improve our packaging status for Debian and Ubuntu</li></ul><p> <strong>Will:</strong> </p><ul> <li>Parrot CodeString performance improvements</li><li>we're definitely faster in branch, but some feedback from pmichaud should help us clean up the API a bit as well, look for those to hit trunk in the next few days</li><li>Parrot makefile deps cleanup</li></ul> chromatic 2010-06-16T01:47:02+00:00 journal Perl 6 Design Minutes for 05 May 2010 http://use.perl.org/~chromatic/journal/40351?from=rss <p>The Perl 6 design team met by phone on 05 May 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>various spec updates, some major</li><li>removed <code>p5=&gt;</code> description because it's not supported in core</li><li>deleted <code>self:sort</code> construct because self isn't a real syntactic category</li><li>explained Perl patterns in terms of PEGs, and spec'ed tiebreaking rules explicitly</li><li>last but not least, finally purveyed the long-threatened revamp of proto to keep routine and method semantics similar</li><li>they all now work much more like the multiple dispatch semantics currently used by STD, where we always call the proto first</li><li>the proto is then always in charge of the actual multiple dispatch; it can of course delegate that</li><li>and the default for a null body corresponds closely to current semantics</li><li>in hacking news, the lexer generator mislaid any alternative that was a bare<nobr> <wbr></nobr><code>.</code> pattern, so cursor_fate never called its alternative, oops</li><li>took me a long time to run that one down, because it resulted in a horrendous backtrack causing mysterious misplaced errors</li><li>revamped character class parsing to be more helpful and correct</li><li>STD now check a normal regex bracket's innards for old-school character class, and warns if found</li><li>added a<nobr> <wbr></nobr><code>.looks_like_cclass</code> method to Cursor to detect most accidental uses of P5 ranges</li><li>some valid P6 brackets will complain, but the workarounds are easy</li><li>just put whitespace on both ends is one way</li><li>removed a few of these old-school-ish character classes from STD</li><li>changed<nobr> <wbr></nobr><code>:tr</code> language to<nobr> <wbr></nobr><code>:cc</code> language since character classes share it</li><li>(translation pays more attention to ordering, but the language is the same)</li><li>turned out parsing character classes discovered issues in STD; various character classes needed to backslash <code>#</code> that would otherwise be a comment</li><li>to that end, we now allow <code>\#</code> in character classes instead of misparsing as unspace</li><li>if we find an invalid <code>-</code> in a regex, we now presume we're in an old-school character class and fail with a sorry instead of a panic to give the character class code a shot at it</li><li>STD now uses <code>~</code> syntax for regex brackets to set <code>$*GOAL</code> correctly</li><li>cleaned up recursive panic detection; it was possible to get both false positives and negatives before</li><li>STD shouldn't use 'note' to emit a panic inside a suppose because that leaks the message that should be trapped</li><li>STD now suppresses duplicate <code>sorry</code> messages more correctly</li><li> <code>sorry</code> no longer uses <code>panic</code> in a supposition, but dies directly to throw the exception to the suppose's try block</li><li>STD now allows subscripts on regex variables so <code>$x[0]</code> isn't taken as a character class; still needs speccing</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>can we make them consistent?</li></ul><p> <strong>Larry:</strong> </p><ul> <li>historically S05 has allowed bare arrays to mean interpolation</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>we've never had a working implementation of that</li></ul><p> <strong>Larry:</strong> </p><ul> <li>a bare <code>@</code> would be illegal</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>it's currently illegal</li></ul><p> <strong>Larry:</strong> </p><ul> <li>you'd have to backslash it to match part of an email address</li><li>it's not like the <code>@</code> alternations are a big deal one way or another</li><li>that'd be a little more consistent</li><li>I forced it to think of the sigil as <code>$</code> than what it really is</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>after seeing how Jonathan et all did interpolation for quoted strings, I thought we should do the same thing in regexes</li></ul><p> <strong>Larry:</strong> </p><ul> <li>STD now has a partial fix to prevent leakage of<nobr> <wbr></nobr><code>::T</code> from role signatures</li><li>unfortunately, the current fix will lose signatures of file-scoped generic roles</li><li>this probably has to do with not knowing whether we're really going to want a new pad; unfortunately we'd have to look ahead to know that currently</li><li>various other minor tweaks and bug fixes in STD and Cursor</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>mostly responding to messages and reports</li><li>should be able to get back to coding full-time and online for the next week</li><li>plan to resolve the list and closure issues with NQP and Rakudo</li><li>will answer other questions and try to keep other people productive</li><li>planning for the Rakudo Star release on June</li></ul><p> <strong>Allison:</strong> </p><ul> <li>busy with the last week of classes</li><li>spent most of it writing a little language with PCT</li><li>it was easy to use and easy to swap the stages of PCT</li><li>I remembered what Patrick did with LOLCODE</li><li>also had a discussion of source code control systems</li><li>next week should be more productive</li><li>need to work more closely with Debian packagers to get packages into Debian</li></ul><p> <strong>Will:</strong> </p><ul> <li>cleaning out as many deprecations in Parrot as possible</li><li>trying to improve the speed of CodeString after the immutable STRINGs merge</li><li>bundling lots of little concats helps</li><li>hope to merge in an optimization branch for that by the weekend</li><li>want to make that faster or less memory intensive</li><li>may require the use of a new StringBuilder for Parrot</li><li>hopefully will result in a faster Rakudo build</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I've never seen CodeString take a long time</li><li>unless you run into memory problems</li><li><p> * discussion of the StringBuilder PMC *</p></li> </ul><p> <strong>c:</strong> </p><ul> <li>still working on optimizations, particularly CodeString</li><li>looking at more PBC and PBC-building optimizations</li><li>PBC size went down dramatically and startup improved for Rakudo</li><li>should have that much faster for the 2.4 release</li><li>will poke at GC tasks starting next week</li></ul> chromatic 2010-05-10T06:07:34+00:00 journal Perl 6 Design Minutes for 28 April 2010 http://use.perl.org/~chromatic/journal/40338?from=rss <p>The Perl 6 design team met by phone on 28 April 2010. Larry, Allison, Jerry, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>caught up on a week's worth of backlog</li><li>made a few spec tweaks</li><li>discussed them with other people</li><li>trying to make error messages more awesome in STD</li><li>working on the ability to parse the insides of character classes</li><li>STD doesn't like parsing itself recursively there</li><li>need to iron out a few things</li><li>enum names can now be variables</li></ul><p> <strong>Allison:</strong> </p><ul> <li>Debian packages ready to ship to Debian sponsors</li><li>putting together a list of GC tasks</li><li>cleaned out the existing page, have the big things listed</li><li>trying to decide which tasks to do first</li><li>doing a lot of reading and research</li><li>my little language project is due on Monday</li><li>HLLCompiler was enormously useful</li><li>will start working on the GC stuff next week</li><li>should also start a fresh pass through the ticket queue</li><li>added a workaround for the final remaining TT #389 bug</li><li>Jonathan had a test case</li></ul><p> <strong>Will:</strong> </p><ul> <li>tried to focus on getting Rakudo blockers removed</li></ul><p> <strong>c:</strong> </p><ul> <li>spent some time getting Rakudo to work with trunk</li><li>will need a Rakudo guts hacker for the last part</li><li>worked on the compact_string revamp branch with Vasily</li><li>merged now</li><li>that makes trunk about 12% faster than the 2.3.0 release</li><li>will work on a few Rakudo profiles once it works with trunk again</li><li>expect at least a 5% performance improvement there</li><li>have some other ideas, but won't do them without profiling first</li><li>came up with a scheme to reduce PBC size by coalescing strings</li><li>Peter Lobsinger is exploring that</li></ul> chromatic 2010-05-02T00:27:42+00:00 journal Perl 6 Design Minutes for 21 April 2010 http://use.perl.org/~chromatic/journal/40332?from=rss <p>The Perl 6 design team met by phone on 21 April 2010. Larry, Allison, Patrick, Will, Jerry, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>been under the weather, so didn't get much done other than keeping up with questions</li><li>S05 now allows negative quantifier ranges on reversible patterns</li><li>S02 now defines the term <code>now</code> to return the current instant</li><li>like <code>rand</code> and <code>self</code>, it does not parse as a function, since it never takes arguments</li><li>we now specify what kinds of math are allowed on instants and durations</li><li>improved error message on attempt to use old-school backreferences in regexes</li><li>STD now implements the <code>now</code> term and several other time-related names</li><li>we now allow enum names to be "constant variables" so that a class enum can declare an accessor</li><li>thinking alot about a better unification of the semantics of protos</li><li>this may also solve the current ambiguity in the meaning of postfix parens</li><li>in any case, this is for post Rakudo *</li></ul><p> <strong>Allison:</strong> </p><ul> <li>mainly worked on packaging for Debian and Ubuntu before the release</li><li>closed TT #389, no methods in namespaces</li><li>collecting thoughts on what we need next from the GC</li><li>we've done a lot of small cleanups</li><li>now we need to solve some persistent problems</li><li>might need to make some fundamental changes, like reducing copying</li><li>coming up on my final week of classes, so lots of work there coming up</li></ul><p> <strong>Will:</strong> </p><ul> <li>updated a spectest</li><li>minor ticket wrangling in Rakudo's RT queue</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>GSoC will make its acceptance announcements soon</li><li>expect TPF will get 10 slots</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>reviewing Rakudo's current state</li><li>made a couple of minor NQP patches</li><li>reviewing patches, especially from Moritz and Bruce Keeler</li><li>should check them in, probably with some refactorings</li><li>hope to work on the <code>List</code> implementation, especially laziness and context</li></ul><p> <strong>c:</strong> </p><ul> <li>fixed as much of line numbering as I found broken</li><li>working on branch merges</li><li>still looking at optimizations</li><li>will focus most energy this month on the sweep-free GC</li><li>hope to encourage other people to work on identified optimizations</li><li>will review Solomon Foster's Mandlebrot example, especially with regard to performance</li></ul> chromatic 2010-04-28T22:20:35+00:00 journal Perl 6 Design Minutes for 14 April 2010 http://use.perl.org/~chromatic/journal/40318?from=rss <p>The Perl 6 design team met by phone on 14 April 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>on p6l, did a bit of bikeshed paint removal with regard to hyphens vs underscores</li><li>S02 now explicitly disallows both whitespace and unspace in top level of an interpolation</li><li>per spec change, when STD is parsing an interpolation inside quotes and looking for a possible postfix, we now presume that a backslash belongs to the quotes and is not an unspace</li><li>in the src/perl6 directory, renamed all Perl 6<nobr> <wbr></nobr><code>.pm</code> files to<nobr> <wbr></nobr><code>.pm6</code> to avoid confusion</li><li>this was necessary because the implementation of STD translates Perl 6 back to the corresponding Perl 5</li><li>the ambiguity was causing problems with tools such as <code>NYTProf</code> </li><li> <code>Cursor.pmc</code> now prefers<nobr> <wbr></nobr><code>.pm6</code> over<nobr> <wbr></nobr><code>.pm</code> in any particular directory when searching for Perl 6 code</li><li>as usual lately, most of my hacking work was in improving the human interface of the parser</li><li>STD now distinguishes two final messages: "<code>Parse failed</code>" vs "<code>Check failed</code>"</li><li>STD now warns on attempts to smartmatch with <code>True</code> or <code>False</code> </li><li>STD now distinguishes continuable-but-fatal "sorry" messages from immediately fatal "panic" messages</li><li>sorry messages will eventually fail at check time</li><li>changed many of STD's semantic errors to use sorry messages when the parse state is not affected</li><li>modified moritz++'s conflict marker patch to be more like the Clang compiler's behavior</li><li>conflict markers now emit a "sorry" message and continues parsing one side of the conflict</li><li>also fixed a buglet that prevented it from processing the conflict marker if first thing in the file</li><li>while fixing the vws (vertical white space) rule for that, also changed it so that extra lines are now eaten with <code>\V*\v</code> for consistency</li><li>it had be using <code>\N*\v</code> </li><li>gimme5 now supports pointing to both ends of missing goal message</li><li>STD's "<code>Couldn't find final<nobr> <wbr></nobr>...</code>" messages now use that capability to point to both ends of the error</li><li>standard quotes now also use the ~ compositor to set the goal and get that behavior</li><li>STD will now dwim <code>&lt;&lt;op&gt;&gt;</code> ("Texas hypers") better even if <code>op</code> contains angles</li><li>suppressed confusing backtracking on <code>~&lt;&lt;</code> that produced a misleading quotewords error</li><li>some other patches</li><li>CORE.setting now recognizes the '<code>note</code>' function</li><li>gimme5 now translates <code>note</code> to <code>print STDERR</code> </li><li>cleaned up some unneeded locmesses</li><li>Actions.pm now handles prefix metaops without spewing spurious yaml dumps</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on TT #389</li><li>the actual fix was about two lines</li><li>spent a lot of time fixing tests around it</li><li>didn't like the original two-line fix</li><li>fixed it in IMCC by passing along the<nobr> <wbr></nobr><code>:nsentry</code> flag</li><li>NQP-rx still depends on that feature</li><li>I understood from Patrick that NQP-rx doesn't need that feature</li><li>don't want to launch that before the 2.3 release</li><li>worked on a lot of smaller issues</li><li>worked on the Parrot Developer Virtual Summit</li><li>will talk about some process changes more, as there are details to work out</li><li>will work on GC as the next priority</li><li>useful for Rakudo in general and Parrot concurrency</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>catching up on mail and tickets</li><li>should get back to coding in the next couple of days</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on the immutable strings branch</li><li>need a couple of changes in the Rakudo binder</li><li>now it's time to convince everyone else it's a worthwhile design change</li><li>going to work on bugfixes</li><li>will try to land the constant string cache</li><li>otherwise, added some optimizations</li></ul><p> <strong>Will:</strong> </p><ul> <li>worked on Partcl</li><li>fixed a Parrot bug that broke Rakudo</li><li>does Rakudo need TT #389 in 2.3?</li></ul> chromatic 2010-04-21T04:09:26+00:00 journal Perl 6 Design Minutes for 07 April 2010 http://use.perl.org/~chromatic/journal/40306?from=rss <p>The Perl 6 design team met by phone on 07 April 2010. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>clarified that object identity from <code>WHICH</code> may not be a mundane value type</li><li>instead object id's are of type <code>ObjAt</code> to avoid type name collisions.</li><li>rewrote misleading description of "thunk"</li><li>made some clarifications of the desired semantics of buffers</li><li>Buf is primarily a role for dealing compact, unsigned integer arrays in a stringy way</li><li>but a Buf may be instantiated with other numeric types as well.</li><li>removed bogus mentions of Buf8, Buf16, Buf32; only the native buf types are sized that way</li><li>STD now actually parses the insides of <code>tr///</code> and carps about malformed ranges</li><li>labels are now stored symbolically as constants rather than types</li><li>so no coercion routine is added for the name, so it doesn't collide with the function namespace</li><li>labels are now constants with a unique label type to prevent confusion with ordinary constants</li><li>module subcompilation now reports the name of the file it's compiling</li><li>improved various error messages regarding <code>foreach</code>, <code>!!op</code>, <code>$!{}</code>, <code>EOF</code>, and missing punctuation after blocks</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on line number reporting in HLLs</li><li>no ticket to go on, no good examples</li><li>didn't make much progress, but didn't have much time</li><li>sounds like Christoph and chromatic are working on it</li><li>might look at TT #389</li></ul><p> <strong>c:</strong> </p><ul> <li>you're welcome to it!</li><li>let me know if you have questions; it's close</li></ul><p> <strong>Allison:</strong> </p><ul> <li>no travel plans for the next couple of months</li><li>should have a lot more Parrot time</li><li>probably time to consider another big project</li><li>probably GC related</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>updated the progress graph last night</li><li>up to date as of yesterday</li><li>Rakudo's passing over 30,000 tests, which is great</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>we have 27 mentors signed up for GSoC</li><li>a dozen student proposals have come in</li><li>the admission period ends Friday, so I expect at least a handful more</li><li>looks like a good year for proposals</li><li>trying to keep on track of Rakudo development</li><li>trying to be a go-between for Rakudo and Parrot</li><li>seems like it's helping Rakudo as Parrot addresses issues that come up</li></ul><p> <strong>c:</strong> </p><ul> <li>Vasily and I fixed the Rakudo performance regression</li><li>we're going to experiment with immutable strings in a branch</li><li>expect some notable performance improvements there</li><li>also worked on the plan to fix line number reporting</li><li>need a test harness to help identify problems and avoid regressions</li><li>learned my lesson last time I worked on that....</li></ul><p> <strong>Larry:</strong> </p><ul> <li>I cringe every time I hear "line numbers"</li><li>I like what Clang does about highlighting the arguments to functions</li><li>it'd be nice if we can do similar</li></ul><p> <strong>c:</strong> </p><ul> <li>that'd require more changes to Parrot, but it's doable</li></ul><p> <strong>Larry:</strong> </p><ul> <li>I just want people to bear it in mind</li></ul><p> <strong>Allison:</strong> </p><ul> <li>there's no reason we can't have richer annotations</li><li>our first step is making sure the information we provide them (or they ask for) is accurate</li><li>is it time to have another big development meeting for Parrot?</li><li>the release is coming up</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>sounds good</li></ul> chromatic 2010-04-09T22:07:25+00:00 journal Perl 6 Design Minutes for 31 March 2010 http://use.perl.org/~chromatic/journal/40296?from=rss <p>The Perl 6 design team met by phone on 31 March 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>in SpecLand, made it clear that the brackets in pairs are not related to subscripts, but follow the corresponding fatarrow semantics</li><li>in particular, name extenders are just strings or list of strings, properly indicated by : or<nobr> <wbr></nobr>:() in most cases (this includes all operator names).</li><li>we now forbid name extension using the<nobr> <wbr></nobr><code>:{}</code> keyless adverbial syntax</li><li>we don't need that because name extensions are really only supposed to use values, not closures</li><li>if we really, really, need to supply a closure as part of a name extension, we can put it in parens, as in<nobr> <wbr></nobr><code>:({})</code>.</li><li>we can use that notation for supplying a closure as a first argument to a method without requiring a space between the colon and the curly, as in<nobr> <wbr></nobr><code>.map:{...}</code> </li><li>people keep writing that and expecting it to work, so I thought it would be good to make it work</li><li>the colon is still require before the curlies, or it's a hash subscript</li><li>we now capitalize the <code>Junction</code> type again because I couldn't get people to stop capitalizing it</li><li>also, the native aspect of junctions is not their most salient difference from normal types</li><li>conjectured an <code>Each</code> type that autothreads lists like junctions, but is serial and lazy, and is used for its values in list context, not boolean context</li><li>in S05, did much cleanup of cursor semantics to reflect what STD and Rakudo actually do these days</li><li>retargeted the <code>&lt;&amp;foo&gt;</code> regex assertion form to explicitly call a routine, just like <code>&lt;.foo&gt;</code> always calls a method</li><li>a bare <code>&lt;foo&gt;</code> assertion now prefers to call a lexical function if visible, or calls as a method in current grammar if not</li><li>this is a compile-time distinction, not a fallback at run time</li><li>in code hacking, continued debugging of the backtracking transactions I added last week</li><li> <code>gimme5</code> now sets the correct xact on <code>||</code> alternations</li><li>deleted more of the transactions that are no longer needed when building match results that are no longer hypothetical</li><li>a <code>LazyMap</code> now always passes through the first result regardless of its associated commit transaction state</li><li>that's because the first cursor in a lazy list always represents the current match hypothesis, not a future hypothesis that needs pruning</li><li>STD now parses to the new specs regarding name extensions not including<nobr> <wbr></nobr><code>:{}</code> </li><li>now allow colon form of method arguments to omit the space if the next char is a left curly, which is what people seem to expect anyway</li><li>note that this makes the closure the first argument, not the only argument</li><li>STD now gives more useful error messages when user says things like 'if' as a function call (<code>if(...) {...}</code>), or a statement control like 'given' where one isn't expected (<code>$x = given {...}</code>)</li><li>STD now properly objects to unrecognized internal regex modifiers such as<nobr> <wbr></nobr><code>:has</code> </li><li>improved the message on adverbs with empty angles (<code>:foo&lt;&gt;</code>) to list some better options</li><li>the problem arises when people think that the angles produce a null string, when in fact they produce a <code>Nil</code> list</li><li>other malformed pairs are also better diagnosed, such as<nobr> <wbr></nobr><code>:!</code> not followed by an identifier, or pairs with duplicate arguments</li><li>added a new rule that traps all warnings and errors</li><li>STD now uses <code>suppose</code> in place of custom try blocks in diagnosing such things as two terms in a row, or unexpected infixes</li><li>also uses <code>suppose</code> to soften the warning about backtick-less embedded comments by not complaining if the supposed comment eats the whole line anyway</li><li>put in some code to de-dup identical warnings</li><li>STD now includes the signature's return type (after <code>--&gt;</code>) in the check for redundant '<code>of</code>' types</li><li>did various tiny speed tweaks, fossil removals</li><li>started playing with how to mark sink context and pure operations</li><li>split out <code>Actions.pm</code> from <code>viv</code> so that it can be used by other STD-based AST builders</li><li>this is in preparation for propagating attributes up and down the AST such as sink context and purity</li><li>eventually this will result in "Useless use of" messages where appropriate, not to mention the ability to do constant folding</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on the <code>compact_pool()</code> function</li><li>split it into a series of smaller functions</li><li>it could use more work, but it's an improvement</li><li>found one possible bug</li><li>worked on some documentation, especially for PMC attributes</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>reviewed some patches to add variable handling in regexes</li><li>they need some changes, but the overall concept is good</li><li>reviewed a few other messages</li><li>most of my time is going toward my family</li><li>hope to get more time to be more active in the next couple of days, but I can't promise that yet</li></ul><p> <strong>Will:</strong> </p><ul> <li>talked to Jonathan about Rakudo Star priorities</li><li>he's very pleased with the memory fixes</li><li>the next thing on his list is getting good line numbers in reported errors</li><li>closing tickets</li><li>working to get rid of the last recursive Makefile</li><li>may wait until after the new release, when we remove a lot of deprecated things</li><li>practicing my NQP skills by working on Tcl again</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on the Rakudo memory problems</li><li>Vasily and I fixed the big memory use problem</li><li>still some performance tuning to do there</li><li>wrote up tasklists for two other important performance pieces</li><li>will work on line numbers after we get performance back</li></ul> chromatic 2010-04-05T04:42:21+00:00 journal Perl 6 Design Minutes for 24 March 2010 http://use.perl.org/~chromatic/journal/40284?from=rss <p>The Perl 6 design team met by phone on 24 March 2010. Larry, Allison, Patrick, Jerry, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>clarified that nearly all normal operators autothread, including <code>===</code> and <code>eqv</code> </li><li>specced the <code>\|</code> parcel parameter syntax</li><li>documented that <code>R</code> metaoperator does not change associativity</li><li>clarified that <code>trusts</code> traits do not extend to child classes, and moritz++ specced it</li><li>in STD, we now suppress spurious errors from badinfix lookahead (and react more accurately to bogus terms)</li><li>now put the error location pointer before a bad infix, not after</li><li>we no longer assume missing block punctuation is always semi or comma, but keep them as a suggestion</li><li>missing punctuation message now points before any whitespace</li><li>awesomified error message about no unspace in regexes to explain how to quote space or <code>#</code> </li><li>pass single coeff to <code>radcalc</code> to make<nobr> <wbr></nobr><code>:16&lt;.BABEFACE&gt;</code> easier to allow</li><li>gives better message on missing <code>**</code> part of radix literals</li><li>worked around fact that<nobr> <wbr></nobr><code>::</code> doesn't correctly suppress relexing of multi tokens</li><li>scrapped the workaround and did a complete refactor of commit point transactions; no longer uses exceptions to commit</li><li>instead, it walks the current commit chain to the proper commit target to disable choosers that should not choose any more options</li><li>commit chain aliasing and forking to make a cactus stack is now managed by cursors, mostly transparently</li><li>weighed in on the subject of stability domains (or lack thereof) in Rakudo *</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>still working on personal issues, but hope to have some resolution by Saturday</li><li>haven't had much time to work on Rakudo, but show up on #perl6 to give advice sometimes</li><li>read Larry's email to the list; it was very helpful</li></ul><p> <strong>Allison:</strong> </p><ul> <li>met some interesting people at SxSW doing open source education technology</li><li>reviewing the roadmap</li><li>the GC sounds like the most important thing to work on next</li><li>trying to catch up from having spotty network access lately</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>the other Rakudo developers have started weekly planning meetings</li><li>Jonathan has taken the lead</li><li>plenty of contributors are in the meeting and offered to take on new tasks</li><li>Rakudo Star may have a smaller scope, but it'll still come out in Q2</li><li>it's nice to see that the Rakudo community continues even as Patrick has an extended absence</li><li>still some Parrot issues affecting Rakudo</li><li>PaFo hopes to have its 501(c)3 application done by summer</li></ul><p> <strong>c:</strong> </p><ul> <li>bugfixes</li><li>minor optimizations</li><li>helped merge the PCC refactor branch</li><li>working on Rakudo memory issues (long analysis follows, partly Parrot GC and partly NQP behavior)</li></ul> chromatic 2010-03-31T21:20:11+00:00 journal Perl 6 Design Minutes for 17 March 2010 http://use.perl.org/~chromatic/journal/40283?from=rss <p>The Perl 6 design team met by phone on 17 March 2010. Larry, Allison, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>documented which ops don't autoclose with <code>*</code>, including assignment</li><li>conjectured a generalization of the closure-calling context (value-only lists) that subscripts enforce</li><li>this generalization might allow the autoclosing of some of the current exceptions such as <code>1..*</code> </li><li>added <code>Z</code> to go with <code>X</code> metaop; documented that <code>X</code> and <code>Z</code> desugar to higher-order methods, <code>crosswith</code> and <code>zipwith</code> </li><li>speculate about how to <code>zip</code>/<code>cross</code> dwimmily with non-identical ops; possibly creating a real use case for surreal precedence</li><li>however, for now sticking with conservative approach of requiring parens on differing list infixes</li><li>hacking on <code>viv</code> again</li><li>trying to get that bootstrapped, so I don't have to use <code>gimme5</code> </li><li>unbitrotted <code>viv --p6</code> so it exactly reproduces STD.pm again</li><li>various developments with <code>viv --p5</code> toward replacing <code>gimme5</code> </li><li>should make it easier to emit other parsers eventually</li><li>may emit Rakudo code someday</li><li>it's a race to see whether STD can do that before the current Rakudo parser resyncs with STD</li><li>anyone who wants to bootstrap on some other VM might want to use that</li><li>mostly tired of writing in the subset of Perl 6 that <code>gimme5</code> understands</li><li>mostly hacking on better error messages, as always</li><li>catches use of non-<code>$</code> hard reference</li><li>STD now read minds of people who forget that "<code>.meth</code> I" is a two-terms-in-a-row error</li><li>now produces good messages on attempts to use <code>y///</code> or <code>tr/a-z/A-Z/</code> syntax</li><li>now reports "previous line missing its semicolon" in the unexpected block checker</li><li>ambiguous use of<nobr> <wbr></nobr><code>.</code> probably indicates p5-think, not missing method parens</li><li>STD now has in a <code>q</code>-like sublanguage for <code>tr///</code> string parsing</li><li>implements the <code>MONKEY_TYPING</code> constraint on <code>augment</code> and <code>supersede</code> declarators</li><li>various random cleanups and bugfixes</li><li>added <code>Z</code> metaoperator</li><li>lots of works on regex flags to unify them into a single <code>%*RX</code> structure at parse time</li><li>makes it easier to do all of the lexical scoping in parallel</li><li>can now remap run-time's <code>$?FOO</code> variables to parser's <code>$*FOO</code> dynamic variables</li><li>otherwise, bugfixes, spec cleanup, and test cleanup</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on tickets</li><li>updating the Parrot roadmap to match our Rakudo Star support plan</li><li>working on the mini-language in NQP for a class assignment</li><li>found a new Pynie developer who saw my talk at Pycon</li><li>may be doing a Summer of Code project in it</li><li>answering lots of questions on IRC and helping out with ideas</li></ul><p> <strong>c:</strong> </p><ul> <li>working on lots of little bugs for Parrot</li><li>should have the method namespace bug fixed, with help from Andrew</li><li>exploring some optimization possibilities</li><li>should be able to merge the PCC refactor shortly</li><li>Allison, see TT #1511</li></ul><p> <strong>Allison:</strong> </p><ul> <li>we need to add a new opcode, something like <code>set_want</code> </li><li>call it to update the CallContext with expected return information</li></ul><p> <strong>c:</strong> </p><ul> <li>works a bit like Perl 5 there</li><li>we could use that information for MMD, that'd be interesting</li></ul> chromatic 2010-03-31T21:17:44+00:00 journal Perl 6 Design Minutes for 10 March 2010 http://use.perl.org/~chromatic/journal/40261?from=rss <p>The Perl 6 design team met by phone on 10 March 2010. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>scrapped @array[%100_000] modular subscript notation in favor of a more general mapping closure</li><li>put back<nobr> <wbr></nobr><code>:s</code> file test, removed<nobr> <wbr></nobr><code>:z</code>,<nobr> <wbr></nobr><code>:T</code>,<nobr> <wbr></nobr><code>:B</code>,<nobr> <wbr></nobr><code>:M</code>,<nobr> <wbr></nobr><code>:A</code>,<nobr> <wbr></nobr><code>:C</code> </li><li>clarified that these are defined on IO, not on strings</li><li>deprecated the <code>{*}</code> and <code>#=</code> reduction stub notations in grammars</li><li>attributive parameters now default to <code>is copy</code> binding; but easy for an attribute to override this with <code>is ref</code> </li><li>tried to move operator definitions to CORE; found one approach that doesn't work and abandoned it</li><li>STD now allows <code>_</code> in numeric variable names like <code>$10_000</code>.</li><li>factored out curlycheck so we can use it on any trailing curly</li><li> <code>postcircumfix:&lt;{ }&gt;</code> now uses curlycheck for consistency</li><li>STD now speculates missing semicolon when two terms in a row are separated by at least one newline</li><li>removed mention of <code>*.notdef</code> in favor of<nobr> <wbr></nobr><code>:!defined</code> </li><li>still need to remove it from the spec though</li><li>ambiguously rebound outer lexicals now detected even if ambiguity propagates from an inner scope </li><li>reports more pertinent information in that case so the difficulty can be understood by the user</li><li>various random debugger refactorings</li><li>properly scope dynamic package names for block-oriented packages to include name declaration</li><li>package_def of<nobr> <wbr></nobr><code>;</code> packages now eats statementlist itself to stay inside proper scope</li><li>much work on package qualified names</li><li>correctly parse <code>&lt;$x&gt;</code> part of <code>FOO::&lt;$x&gt;</code> as part of variable name</li><li>correctly follow symbolically indirected <code>OUTER::</code> links</li><li> <code>find_top_pkg</code> no longer cares if name ends in<nobr> <wbr></nobr><code>::</code> </li><li>STD now figures out whether initial components lead to package or lexical scope</li><li>no longer scans outer scopes on qualified names</li><li>now handles <code>FOO::&lt;$x&gt;</code> form in <code>check_variable</code> </li><li>no longer checks for <code>@/%</code> mistakes on qualified names</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>haven't had much hacking time lately due to personal demands</li><li>should be able to hack again later today and the rest of the week</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on the PCC refactor</li><li>that went well; the hackathon was good</li><li>it didn't pull in a lot of people, but me dedicating the weekend to it was helpful</li><li>also pulled in a few other people willing to try things out</li><li>we made good progress</li><li>our initial task is over</li><li>we're in the nebulous stage of debugging</li><li>need to review a change in optional return values</li><li>also worked on Ubuntu and Debian packaging</li><li>Parrot 2.0 is in both</li><li>it'll be in April's Lucid Lynx Ubuntu</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>Google Summer of Code is starting</li><li>TPF and PaFo are teaming up this year</li><li>we're working on the organization application</li><li>Jonathan Leto is leading things and I'm backing him up</li><li>we're looking for mentors and ideas; see the <a href="http://www.perlfoundation.org/perl5/index.cgi?gsoc">TPF GSoC wiki page</a> </li></ul><p> <strong>Will:</strong> </p><ul> <li>started going through Rakudo's RT queue</li><li>did more Parrot building and cleanup work</li><li>no longer invoking Perl to invoke the C compiler for each build file</li><li>shaved some time off the build</li><li>eliminated one recursive make, leaving two</li><li>then I can remove more things from config</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on a bunch of branches</li><li>fixed a couple of bugs</li><li>hope to get more bug fixing time in</li></ul> chromatic 2010-03-23T01:37:49+00:00 journal Perl 6 Design Minutes for 03 March 2010 http://use.perl.org/~chromatic/journal/40242?from=rss <p>The Perl 6 design team met by phone on 03 March 2010. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>noted how lastcall allows nextsame control of nested dispatchers</li><li>reserved the final paren-based shape declaration syntax without committing to it meaning anything</li><li>clarified that <code>Nil</code> itself is defined but likes to produce undefined values when indexed</li><li>added some clarifications of how the series operator deals with type information</li><li>clarified that <code>Pair.ACCEPTS</code> uses "so" and "not" semantics so<nobr> <wbr></nobr>:s returns <code>True</code> or <code>False</code> </li><li>removed the <code>1/2</code> and <code>+2-3i</code> literal forms, now rely on angle forms <code>&lt;1/2&gt;</code> and <code>&lt;+2-3i&gt;</code> for literals, and the bare forms now rely on constant folding rather than a fragile special syntax</li><li>in STD, made undeclared variables more fatal</li><li>STD now tries to be helpful if the user makes the typical P5-ish variant-sigil mistake on arrays and hashes</li><li>also improved error message on the <code>-</code>{}&gt; kind of mistake that P5 programmers will make</li><li> <code>my $a, $b</code> now gives better message</li><li>STD now reserves the <code>()</code> shape syntax per current spec</li><li>fixed regression on indirect method knowing that method name is not bound early</li><li>moved unexpected-<code>!!</code> panic from infixstoppers to <code>infix:&lt;!!&gt;</code> for better extensibility</li><li>so a user's infix definition isn't ignored if it starts with <code>!!</code> </li><li>you can define user operators starting with that, and it only complains for the right reasons now</li><li>STD now gives an accurate message when a prefix is missing its term</li><li>removed deprecated rational and complex literal forms from STD</li><li>much preliminary work for moving operator defs to CORE.setting, not yet checked in</li><li>only blocker is not being in Copenhagen</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>Jonathan, Carl, Moritz, and Martin will be there</li><li>I proposed a panel discussion instead of my talk on Tuesday afternoon at 3 pm</li><li>I'll be online then</li><li>can't make it due to sudden personal reasons</li><li>will be online quite a bit the next few days though</li><li>can participate in the hackathon remotely</li><li>worked mostly on helping other people get their tasks done</li><li>updated the parser to handle more operator conditions</li><li>working toward enabling user-defined operators</li><li>quite a few new people submitted patches</li><li>several were non-trivial</li><li>one patch put grammars, regexes, and tokens back in Rakudo</li><li>that's not trivial and it worked pretty well</li><li>I'm reviewing patches and making comments</li><li>lots of good progress</li><li>expect lots more during the hackathon</li></ul><p> <strong>Allison:</strong> </p><ul> <li>going to work on code stuff this weekend instead of traveling</li><li>had a very productive trip</li><li>glad to be home to get work done</li><li>working on the PCC branch this week</li><li>should be, fingers crossed, small and easy to get done</li><li>want to avoid creature feeping</li><li>get the re-ordering through and move on</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>having trouble building Rakudo on Windows</li><li>have time to debug with people online</li><li>this is preventing me from talking to Patrick about and working on S19</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>we can work on that tomorrow</li></ul><p> <strong>Will:</strong> </p><ul> <li>saw that problem on p6c as well</li><li>fixed a Parrot bug for Patrick related to STRING indices</li><li>we have some speed fixes on top of that</li><li>still working on the build cleanup</li><li>hope to merge to trunk in the next two or three days</li></ul><p> <strong>c:</strong> </p><ul> <li>haven't had and won't have much time</li><li>fixed a few bugs</li><li>working on helping other people get stuff done</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>is there a hackathon or meeting time available after OSCON?</li></ul><p> <strong>Allison:</strong> </p><ul> <li>recommend the weekend after</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>there'd have to be a hackathon for me to get TPF sponsorship</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>the pace of spec changes has picked up</li><li>any ideas what's driving that?</li><li>is it different from before?</li><li>was the end-of-year lull the same as before?</li></ul><p> <strong>Larry:</strong> </p><ul> <li>everyone did take a break over Christmas</li><li>most of the changes are still simplifications</li><li>or responses to implementation issues</li><li>dealing with inconsistencies</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>a lot of implementation issues have come up over the past three weeks</li></ul><p> <strong>Larry:</strong> </p><ul> <li>ng has flushed out a lot of design issues</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>that's great!</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>that's great for Larry, but I have a deadline!</li></ul><p> <strong>Allison:</strong> </p><ul> <li>remember, it's a stake in the ground</li><li>"This is a release of Perl 6 you can use NOW!"</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>we're driving the spec with regard to lists and arrays</li></ul><p> <strong>Larry:</strong> </p><ul> <li>they essentially have the same structure</li><li>they need separate typology</li><li>you need to know whether to clone an iterator</li><li>that's the only reason you have to know</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>did you see my comment about binding being the distinguishing feature?</li></ul><p> <strong>Larry:</strong> </p><ul> <li>I think about that in inside out terms</li><li>not sure I can put that in words yet</li><li>had a conversation with Solomon about the FP view of iterators and arrays</li><li>that's some of my thinking</li><li>do we promise to hold a pointer fixed, or go on to the next thing?</li><li>whether that thing is persistent is mostly the bailiwick of the GC, from the standpoint of the language</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I wasn't sure how that applied to my specific context</li><li>maybe I should work up a description of words or implementation</li><li>some lists I want to keep around reified elements</li><li>some lists I don't</li><li>the distinction is whether it's bound to any variable</li></ul><p> <strong>Larry:</strong> </p><ul> <li>may depend on what it's bound to</li><li>we might make the keeparound promise only for binding to <code>@</code> </li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I came up with binding to <code>$</code> examples</li><li>we can get laziness but eat up a ton of memory</li><li>if we throw things away when iterating, we get more things wrong</li></ul><p> <strong>Larry:</strong> </p><ul> <li>it's a matter of tracking</li><li>are we bound to something that tells the GC to keep the rest of the list around?</li><li>that's the FP view</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>that's not just a GC view</li><li>it's how people refer to them</li><li>my GC is taken care of by my virtual machine anyway</li><li>it's about reachability from the HLL</li><li>or did you see it disappear</li></ul><p> <strong>Larry:</strong> </p><ul> <li>that's whether you have a reference to it</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>how do you know whether to keep a reference to it?</li><li>I've produced this element</li><li>can I send it back to the caller</li><li>or do I need to keep it around so something else can get to it</li><li>if the iterator itself is bound, you keep the reference</li><li>if it's not bound, you can return it but not keep the reference around</li><li>I'll write up my thoughts</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>will these changes settle down after Rakudo *?</li><li>are they a precursor to that release?</li><li>will they continue afterward?</li><li>will Rakudo * go stale?</li><li>that's a tough one to answer</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I can't guarantee stability at this point</li><li>we want a useful release</li><li>we'd like not to have any deprecations after that point</li><li>given how implementations and applications <em>drive</em> implementations</li><li>Rakudo * exists to encourage people to develop applications</li><li>we've never made that stability an explicit goal for Rakudo *</li><li>we'll probably institute deprecation cycles when it comes out</li><li>we don't want to change the world out from under people</li><li>it doesn't represent a spec freeze</li><li>thinking of a separate distribution release from the compiler release</li><li>a three month stability cycle of releases for Rakudo *</li><li>a different point of view</li><li>any distribution release doesn't have to be tied to the newest compiler release</li><li>I see Rakudo * as a series of releases, not a single release</li></ul> chromatic 2010-03-13T23:19:22+00:00 journal Perl 6 Design Minutes for 24 February 2010 http://use.perl.org/~chromatic/journal/40217?from=rss <p>The Perl 6 design team met by phone on 24 February 2010. Larry, Allison, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>my work last week was almost entirely responsive to various discussions on irc and p6l, even when it doesn't seem like it</li><li>clarified that <code>LEAVE</code>-style phasers do not trip till after an exception is handled (and not resumed)</li><li>the implementation of take is specifically <em>before</em> unwinding even if implemented with a control exception</li><li>simplified series operator by moving generator function to the left side (any function on right side will now be a limiting conditional)</li><li>a <code>*</code> is no longer required to intuit the series on the left; the absence of generator before the<nobr> <wbr></nobr><code>...</code> operator is sufficient</li><li>first argument on the right of<nobr> <wbr></nobr><code>...</code> is now always a limiter argument</li><li>for convenience and consistency, added a new<nobr> <wbr></nobr><code>...^</code> form to exclude a literal limiter from the generated series</li><li>unlike ranges, however, there is no leading exclusion <code>^...</code> or <code>^...^</code> </li><li>series is a list associative list infix, and each<nobr> <wbr></nobr><code>...</code> pays attention only the portion of the list immediately to its left (plus the limit from the right)</li><li>an "impossible" limit can terminate a monotonic intuited series even if the limit can never match exactly</li><li>variables now default to a type of <code>Any</code>, and must explicitly declare <code>Mu</code> or <code>Junction</code> type to hold junctions</li><li>this is to reduce pressure to duplicate many functions like <code>==</code> with <code>Mu</code> arguments; most of our failure values should be derived from Any in any case</li><li>a <code>Mu</code> result is more indicative of a major malfunction now, and is caught at first assignment to an <code>Any</code> variable</li><li> <code>Instant</code>/<code>Duration</code> types are biased away from <code>Num</code> and towards <code>Rat</code>/<code>FatRat</code> semantics</li><li> <code>Instant</code> is now completely opaque; we no longer pretend to be the same as TAI, numerically speaking</li><li> <code>Instant</code>s are now considered a more basic type than epochs, which are just particular named instants</li><li>all culturally aware time can be based on calculations involving instants and durations</li><li>list associative operators now treat non-matching op names as non-associative rather than right-associative, forcing parens</li><li> <code>Whatever</code> semantics now autocurry any prefix, postfix, or infix operator that doesn't explicitly declare that it handles whateverness itself</li><li> <code>WhateverCode</code> objects now take a signature to keep clear how many args are not yet curried</li><li>so <code>*+*</code> is now more like <code>WhateverCode:($x,$y)</code> </li><li>autocurrying is still transitive so multiple ops can curry themselves around a <code>*</code> </li><li>added semilists as <code>Slicel</code> type to go with <code>Parcel</code> </li><li>this allows us to bind <code>@array[1,2,3]</code> differently from <code>@array[1,2,3;4,5,6]</code>, for instance</li><li>the <code>Matcher</code> type now excludes <code>Bool</code> arguments to prevent accidental binding to outer <code>$_</code> when closure is needed</li><li> <code>when</code> and <code>~~</code> will now warn of always/never matching on direct use of <code>True</code> or <code>False</code> names as matcher</li><li>STD generalizes <code>\w</code> lookahead to all twigils now</li><li>STD now treats non-matching list associatives as non-associative</li><li>things like <code>1 min 2 max 3</code> are now illegal, and require parenthesization for clarity</li><li>STD now treat invocant colon as just a comma variant so it does not fall afoul of the list associativity change</li><li>CORE now recognizes the <code>TrigBase</code> enumeration</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>first release of the new branch of Rakudo last week</li><li>passing ~25,000 tests at the release</li><li>thanks to optimizations from chromatic, Jonathan, and Vasily, Rakudo has a lot of speed improvements</li><li>in particular, it can run those tests in under 10 minutes, non-parallel, depending on your hardware</li><li>older releases took 25 minutes and more</li><li>the regex tests will slow things down</li><li>ultimately, we're seeing a big speed improvement over the past releases</li><li>cleaned up lists and slices, now they work pretty well</li><li>worked with Solomon Foster and others to speed up trig operations</li><li>fixed a bug related to lexicals declared in classes</li><li>fixed the long-standing and often recurring problem with curlies ending a line/statement causing the next statement to be a statement modifier</li><li>easy to fix in the new grammar</li><li>that was nice</li><li>made an initial implementation of the <code>sort</code> method</li><li>it's very short, because Parrot provides one</li><li>there are a few bugs in Rakudo there still, but I'll get them</li><li>planning for the Copenhagen hackathon on March 5 - 9</li><li>Jonathan and I have been updating the Rakudo roadmap</li><li>will check that in in the next couple of hours</li><li>so far, every time we review it, we surprise ourselves at how much we've accomplished</li><li>we're meeting all of the top priority goals without making any heroic efforts</li><li>we'll put those goals in as well as timelines</li><li>most of the major tasks from previous roadmaps have happened</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on Python this week</li><li>attended Python VM summit, Python language summit, and PyCon</li><li>Parrot's on good track to support what Python needs</li><li>useful to make community connections</li><li>when I reviewed Pynie, I was surprised to see how close it is to supporting the whole Python syntax</li><li>some of those features are big, like objects</li><li>but we should support them soon</li><li>Debian packages delayed by the absence of a sponsor</li><li>they should go into Debian soon though</li><li>I put in a request for feature-freeze exception for Ubuntu 10.4</li><li>Parrot 2.0 should go in</li><li>haven't made any commits to the PCC branch</li><li>that'll be a top priority for next week</li></ul><p> <strong>c:</strong> </p><ul> <li>fixed a Parrot GC bug for last week's Rakudo release</li><li>made some optimizations in Rakudo and Parrot</li><li>helped Jonathan find a few more</li><li>fixed a long-standing math MMD bug</li><li>still working on HLL subclassing; more tricky than you think</li><li>may be some conflicting design goals about vtable overriding and MMD</li></ul><p> <strong>Allison:</strong> </p><ul> <li>Patrick, do we need an explicit deprecation for old PGE and NQP?</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I think Will already added one for NQP</li><li>we can add one for PGE if we need</li><li>they don't necessarily have to disappear at the next release</li><li>but no one's planning to maintain them</li></ul><p> <strong>Allison:</strong> </p><ul> <li>no reason not to put in the notice now</li><li>we don't have to remove them at the earliest possible date</li></ul> chromatic 2010-03-02T05:12:09+00:00 journal Perl 6 Design Minutes for 17 February 2010 http://use.perl.org/~chromatic/journal/40209?from=rss <p>The Perl 6 design team met by phone on 17 February 2010. Larry, Allison, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>much work clarifying relationship of parcels to everything else (<code>&lt;a b&gt;</code>, assignment, arguments, captures, parameters, signatures, <code>gather</code>/<code>take</code>, and loop returns)</li><li>we now list all scope declarators in one spot</li><li>conjectured some ideas on how to handle the allomorphism of literals more dwimmily</li><li>had already specced some of this behavior for literals found inside <code>qw</code> angles.</li><li>literals that exceed a <code>Rat64</code>'s denominator automatically keep the string form around for coercion to other types</li><li>clarified that anon declarator allows a name but simply doesn't install it in the symbol table</li><li>respecced the trig functions to use a pragma to imported fast curried functions</li><li>still uses enum second argument for the general case (rakudo is still stuck on slow strings there)</li><li>on iterators, renamed<nobr> <wbr></nobr><code>.getobj</code> to<nobr> <wbr></nobr><code>.getarg</code> since arguments are the typical positional/slicey usage</li><li>signatures are never bound against parcels anymore, only against captures</li><li>we now use "argument" as a technical term meaning either a real parcel or an object that can be used independent of context as an argument</li><li>anything that would stay discrete when bound to a positional, basically</li><li> <code>return</code>, <code>take</code>, and loop return objects are also arguments in that sense</li><li>they all return either a parcel or anything that can stand on its own as an argument</li><li>STD now adds a shortname alias on adverbialized names, ignores collisions on the shortname for now, which is okay for multis</li><li>STD now complains about longname (adverbialized) collisions</li><li>STD no longer carps about duplicate anonymous routine declarations</li><li>made the undeclared type message the same for parameters as for other declarations</li><li>clarify the error message about anonymous variables</li><li>no longer report a <code>$)</code> variable error where <code>)</code> is the <code>$*GOAL</code> </li><li>add <code>WHAT</code> etc. to list of functions that require an argument</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on two HLL implementations</li><li>one is Pynie, the other is Camle</li><li>nothing to do with Caml or ML</li><li>I've noticed huge improvements in NQP-rx from the previous NQP</li><li>can't say which feature improvements make the most difference, but I'll migrate Pynie pretty soon to take advantage of the new version</li><li>continuing to shepherd Debian and Ubuntu packages</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>essentially all I did was unify things</li><li>previously it had been two or three tools</li><li>it's just one</li></ul><p> <strong>Allison:</strong> </p><ul> <li>even the syntax seems more regular</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>there are more pieces available in NQP-rx</li><li>Rakudo's -ng is now master</li><li>the old master is now -alpha</li><li>we took a big hit on spectests, but they seem to be coming back quickly</li><li>5000 tests pass on trunk now</li><li>we have 16k or 17k we haven't re-enabled; they make the spectest slower</li><li>Jonathan thinks we may pass 25,000 tests now</li><li>that's great, considering where we were a week ago</li><li>I redid Rakudo's container, value, and assignment module</li><li>previously variables held values directly</li><li>now they contain reference PMCs</li><li>that cleaned up many things</li><li>we use more PMCs, but now we don't clone and copy as much</li><li>we move references around more</li><li>seems closer to how Perl 6 handles things</li><li>was much easier than I expected</li><li>updated the NQP-rx regex engine and built in constant types</li><li>handles Unicode character names</li><li>reclaims plenty of tests</li><li>answered lots of questions for people adding things into Rakudo</li><li>prioritizing other people writing code over writing code</li><li>increases our developer pool; seems to be working well</li><li>new release of Rakudo planned for tomorrow</li><li>don't know how many tests we'll pass, but it should go well</li><li>plan to put in a few things like <code>sort</code> and grammars over the next week</li><li>then I'll review the RT queue to find bugs and (hopefully) closeable bugs</li></ul><p> <strong>c:</strong> </p><ul> <li>working on GC tuning</li><li>also working on String PMC tuning</li><li>working on built-in types and their behavior as classes and parent classes</li><li>the multidispatch bugs in particular I hope to solve</li></ul> chromatic 2010-02-25T00:27:32+00:00 journal Perl 6 Design Minutes for 10 February 2010 http://use.perl.org/~chromatic/journal/40193?from=rss <p>The Perl 6 design team met by phone on 10 February 2010. Larry, Patrick, Will, Jerry, and chromatic attended.</p><p> <strong>Will:</strong> </p><ul> <li>working on simplifying Parrot's build process</li><li>trying to remove an invocation of Perl 5 for every compilation</li><li>it's old and a waste of many things</li><li>hope to have that removed by the end of the week</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>the new #ps time should help me to attend</li><li>looking forward to a Parrot/Rakudo workshop, possibly at YAPC::NA</li><li>already working on artwork</li><li>would like to get the command-line done for Rakudo *</li><li>lacking tuits</li><li>need some time with Patrick over the next few days</li><li>weekends should free up after next week</li></ul><p> <strong>Larry:</strong> </p><ul> <li>refined the specified semantics of bitwise operators</li><li>changed ugly <code>**()</code> special form to <code>prefix:&lt;||&gt;</code> by analogy to <code>prefix:&lt;|&gt;</code>, and relationship of <code>**</code> to <code>*</code>.</li><li>STD now accepts prefix <code>||</code> for slice interpolation</li><li>deleted old p5=&gt; that masak++ noticed</li><li>added explicit copyright notices to STD files</li><li>spruced up error message on -&gt; in postfix position (either pointy block or Perl 5 method dereference)</li><li>mostly just served as Chief Resident Oracle on IRC</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>had a nice vacation in Florida</li><li>didn't have as much hacking time, due to plane delays</li><li>should get back to coding later today</li><li>working on the Rakudo hackathon in Copenhagen on March 6 and 7</li><li>core hackers session on 8th and 9th there</li><li>looking forward to that</li></ul><p> <strong>c:</strong> </p><ul> <li>fixed a couple of bugs</li><li>did a bit of optimization</li><li>wrote out a GC optimization plan</li><li>wrote plan for a sweep free GC</li><li>think we can get those both going in the next week</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>noticing a lot of new branches and removals and new things in Parrot recently</li><li>are these following the roadmap?</li><li>are people going off on their own?</li></ul><p> <strong>Will:</strong> </p><ul> <li>the deprecation stuff is all documented and seems reasonable</li><li>Andrew's discussion today is new stuff, but a reasonable discussion to have</li><li>I'm working on cleanup stuff</li><li>having a roadmap and trying to force people to stick to it is always... impossible</li><li>people will work on what they find shiny or what blocks them</li><li>if it's not on the roadmap, it's okay if it's not hurting the project</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>we've changed our deprecation cycle</li><li>was that change enough to unstick people to do something?</li><li>was it beneficial to our users and our core developers?</li></ul><p> <strong>Will:</strong> </p><ul> <li>definitely a positive</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>still not a lot of mailing list discussion</li><li>how is Parrot meeting Rakudo's goals for the Rakudo * release?</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>as it stands today, it's adequate for what we need</li><li>if it weren't, you'd be hearing about it</li><li>the next thing for us is performance</li><li>any performance improvements are welcome</li><li>the biggest thing there is GC, and that's an area of focus</li><li>no big pushes I need to make lately</li><li>have noticed Andrew's desire to remove some Parrot features</li><li>they're useful from an HLL perspective</li><li>I do worry about changes to core Parrot divorced from HLL concerns</li><li>I don't know who's going to be the traffic cop for those changes</li><li>I don't have time to do it</li></ul><p> <strong>Will:</strong> </p><ul> <li>based on the discussion in channel today</li><li>making Parrot leaner, faster, smaller may not necessarily jive with keeping the features as they exist now</li><li>he's not trying to remove features</li><li>he's trying to get the same effect with a faster Parrot</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I agree with those motives</li></ul><p> <strong>Will:</strong> </p><ul> <li>even if we do rewrite things, they have to work more or less as they do right now</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>reviewing the roadmap from December....</li><li>GC work is happening</li><li>no one seems to work on subroutine leave semantics</li><li>Stephen Weeks is the best one to look at that</li><li>performance is our biggest need right now</li><li>but the -ng branch performs better for various reasons</li><li>has anyone built -ng against the latest Parrot?</li></ul><p> <strong>Will:</strong> </p><ul> <li>I think Vasily has checked his branches against Rakudo</li><li>not sure if that was against -ng</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>master and -ng are pretty close together in terms of the Parrot core</li><li>we'll make -ng the master branch very soon</li><li>unless I get bogged down on iterators again</li></ul> chromatic 2010-02-19T03:31:59+00:00 journal Perl 6 Design Minutes for 03 February 2010 http://use.perl.org/~chromatic/journal/40191?from=rss <p>The Perl 6 design team met by phone on 03 February 2010. Larry, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>more cleanup of iteration semantics</li><li>no longer signal end with <code>Nil</code>, but with special <code>EMPTY</code> failure</li><li>this can support either unthrown or thrown exception styles</li><li>added in batching iterator interface</li><li>proposed new <code>E</code> operator for efficient list end detection; gathering feedback</li><li>detangling of sigils from contexts; for example, <code>@</code> no longer implies flattening</li><li>coercions all defined to take parcels so they don't flatten accidentally</li><li>more cleanup of various types (captures,lists) that should be considered parcels</li><li>forcibly amputated the <code>@@</code> sigil; have fixed up most of the bloody stumps</li><li>instead of *@@ parameters, we now have a <code>**</code> slice marker on parameters</li><li>removed references to <code>[;]</code> reduction since it wouldn't work (because of return parcel embedding)</li><li>new <code>**()</code> interpolator instead</li><li>clarified that function calls in a list are called eagerly, but their results are potentially lazy</li><li>(also mentioned ways to make the call lazy too)</li><li>renamed iterator methods for more clarity, removing contradictory usages of "item"</li><li>iterators now iterated with <code>get</code>, <code>getobj</code>, <code>batch</code>, and <code>batchobj</code> </li><li>specced that a missing maximum allows the iterator to decide batch size.</li><li> <code>get</code> and <code>getobj</code> must be atomic under multi-threading so message queues work (but maybe that's backwards, and <code>push</code> should be atomic)</li><li>slice now defined to turn subparcels into <code>Seq</code> objects</li><li>spec that most of the work of <code>flat</code> and <code>slice</code> are done by binding to <code>*@</code> or <code>**@</code> </li><li>new <code>flat</code> operator detangles flattening semantics from normal unmarked <code>list</code> semantics</li><li>for all specced functions, <code>*@@</code> parameters changed to <code>**@</code> </li><li>multiple dimensions now defined in terms of nested parcels, not feeds, to avoid implying multithreading on every subscript</li><li>either range or series iterator now autotruncates in a subscript</li><li>no autotruncation on left end of a subscript anymore</li><li>did some cleanup of feeds; more is needed to have clearer target semantics</li><li>feeds no longer take a whatever target with implicit semantics; just use an explicit target</li><li>not much hacking, but edited tests to change <code>@@</code> to something else appropriate</li><li>tracked name changes in CORE</li><li>wrote a long screed on why Perl 6 has one-pass parsing and why typenames must be pre-declared</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on interators and lists in the -ng branch</li><li>brought up a few issues with Larry as appropriate</li><li>took issue with others, as appropriate</li><li>happy with our progress there</li><li>expect to make this branch the new master in the next day or so</li><li>will be some regressions, but it's time to do it</li><li>there's no development taking place on other branches, so let's commit and do it</li><li>people will be comfortable about doing their own work and not having it lost on some other branch</li></ul><p> <strong>c:</strong> </p><ul> <li>looking into GC tuning and ideas</li><li>still working on getting methods out of namespaces</li><li>need four uninterrupted hours</li></ul> chromatic 2010-02-18T04:58:35+00:00 journal Perl 6 Design Minutes for 27 January 2010 http://use.perl.org/~chromatic/journal/40144?from=rss <p>The Perl 6 design team met by phone on 27 January 2010. Larry, Allison, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>tweaked definition of when a series operator is considered infinite</li><li>nailed down more list assignment semantics with respect to interators</li><li>clarified how <code>($a, $b, @a) = 1..*</code> works</li><li> <code>KeyWeight</code> deletion criterion kept consistent with other <code>KeyHash</code> types</li><li>negative keyweights are allowed to fail at pick time</li><li>"mostly eager" now assumes unknown closure generators are probably infinite</li><li>random whackage on <code>List</code>, <code>Seq</code>, <code>Parcel</code>, <code>Capture</code>, <code>Iterator</code>, <code>Nil</code> etc.</li><li> <code>List</code> is now simply the iterator role, and doesn't do <code>Positional</code> </li><li> <code>Seq</code> takes over <code>Positional</code> duties for reified (or reifiable) value lists</li><li>think of <code>Seq</code> now as a constant <code>Array</code> (but also lazy like <code>Array</code>)</li><li> <code>Iterable</code> now means you can ask for an iterator, but doesn't do <code>List</code> </li><li> <code>Array</code>, <code>Seq</code>, etc do <code>Iterable</code>, but not <code>List</code> </li><li>only actual iterators do <code>List</code> </li><li> <code>Nil</code> is defined as a suitable sentinel for both list and slice iterators</li><li>continued to rethink that with pmichaud++ et al</li><li>we'll probably end up with an <code>EMPTY</code> special exception object to be the iterator sentinal</li><li>proposed an <code>E</code> operator to go with it to make testing for <code>EMPTY</code> across multiple iterators very fast</li><li>other than that, mostly just bug whacking, no major refactors</li><li>still thinking about doing real LTM for STD</li><li>did lazify <code>Cursor</code>'s fnum-&gt;fate translations for shorter LTM candidates in preparation for smarter LTM</li><li>we don't need special objects for the items that get matches</li><li>we do need to think more about the hyper cases</li><li>how to do list processing using balanced trees of delegated sub refs</li><li>don't want to build in serial assumptions where we don't need them</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>made the Rakudo #25 release last week</li><li>it was much easier to make the release than explain what we were planning to do instead</li><li>also working on iterators and lists</li><li>NG branch is blocking on that</li><li>worked on the design in my head for three weeks</li><li>realized that we were doing iterators completely wrong the other night</li><li>Larry's making some useful changes to the spec in response</li><li>there are still some unclear spots in the spec</li><li>we need an implementation to figure those out</li><li>my biggest question is the relationship between <code>List</code>, <code>Parcel</code>, <code>Itertor</code>, and array</li><li>as of this morning, I think I have it</li><li>that code seems to be working <em>and</em> efficient</li><li>so far it's working well</li><li>continuing with that</li><li>wrote a very short range iterator prototype that colomon has used</li><li>also write a <code>map</code> iterator that works</li><li>coming up with examples for the <code>zip</code> operator was nice</li><li>good ideas for what we need to be able to do</li><li>objects that can iterate have a<nobr> <wbr></nobr><code>.iterator()</code> method</li><li>to interpolate that into a list,<nobr> <wbr></nobr><code>.list()</code> returns a flat <code>Parcel</code> for that iterator</li><li> <code>Parcel</code>s know how to generate <code>Iterator</code>s</li><li>those know how to handle <code>Iterator</code>s of <code>Iterator</code>s</li><li>I suspect that's how we do hyper iteration</li><li>change <code>Parcel</code>s to understand that</li><li>adding pieces back into the ng branch</li><li>next I have to fix slurpy parameters</li><li>many of our builtins need that</li><li>need to figure out Jonathan's code to do that</li><li>after that, I'll do arrays</li><li>that should remove the blockers on the ng branch</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on Pynie</li><li>Francois has helped greatly to update it for Plumage</li></ul><p> <strong>c:</strong> </p><ul> <li>still working on the TT #389 fix</li><li>think I have the right design, just need time to implement it</li><li>working on a potential new time for #parrotsketch</li></ul><p> <strong>Allison:</strong> </p><ul> <li>thinking about hackathons</li><li>would be nice to have a Rakudo hackathon at YAPC::NA</li></ul><p> <strong>c:</strong> </p><ul> <li>Parrot will come up; didn't it come up about half the time last year?</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>it was all Parrot</li></ul><p> <strong>Allison:</strong> </p><ul> <li>you'll have an influx of Rakudo interest two months after Rakudo Star</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>probably will have one before then</li><li>but can tell people "Go to YAPC; we'll show you how to help in person there"</li></ul> chromatic 2010-01-29T21:00:38+00:00 journal Perl 6 Design Minutes for 20 January 2010 http://use.perl.org/~chromatic/journal/40137?from=rss <p>The Perl 6 design team meet by phone on 20 January 2010. Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Allison:</strong> </p><ul> <li>did distro testing on Ubuntu and the Mac</li><li>set up a Hardy chroot; Parrot works just fine there</li><li>have a feeling we missed some deprecations, but we have a lot in there</li><li>enough to work on for three months</li></ul><p> <strong>c:</strong> </p><ul> <li>I added the STRING idea, to give us the possibility of the value semantics change</li></ul><p> <strong>Allison:</strong> </p><ul> <li>less stressful to have three months at a time</li><li>otherwise working on class assignments</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>family illness knocked me out for a few days</li><li>we'll postspone the January release for up to a week</li><li>going to make the Rakudo-ng branch the master branch</li><li>that won't take more than a week</li><li>we'll release by Thursday of next week</li><li>also need to make the -ng branch build with Parrot 2.0.0</li><li>need to merge some outstanding patches to make that work</li></ul><p> <strong>c:</strong> </p><ul> <li>are you going to stick with 2.0.0?</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>unless we need a change in Parrot that we can't live without, yes</li></ul><p> <strong>Will:</strong> </p><ul> <li>we could do a point release if you need one</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>that's up to Parrot</li><li>from Rakudo's perspective, that's not terribly important</li><li>we're shifting everything around for the -ng branch</li><li>we'll definitely stick the February release to Parrot 2.1</li><li>I'll post messages to the list about the new release plan shortly</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on the one_make branch in Parrot</li><li>trying to mark dependencies properly in a single <em>Makefile</em> </li><li>get some of that out of the configure system</li><li>we should be able to merge to trunk in a day or two</li><li>there's still more work to do, but we're at a merge point soon</li></ul><p> <strong>c:</strong> </p><ul> <li>released Parrot 2.0.0 yesterday</li><li>sending out release announcements soon, but the code is out</li><li>Stephen Weeks helped me fix up PGE not to fetch methods from namespaces</li><li>should be able to merge the TT #389 fix branch to trunk very soon</li><li>will take a look at other Rakudo blockers after that</li></ul> chromatic 2010-01-28T00:10:27+00:00 journal Perl 6 Design Minutes for 13 January 2010 http://use.perl.org/~chromatic/journal/40132?from=rss <p>The Perl 6 design team met by phone on 13 January 2010. Larry, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>made constant declarations more consistent with type declaration syntax</li><li>removed various spec fossils regarding the old<nobr> <wbr></nobr><code>:by</code> modifier</li><li>reworked <code>KeyHash</code> docs to make the semantics clearer</li><li>refactored regex AST methods out of Cursor</li><li>symbol table files are now compiled into their own subdirectory</li><li>STD can now use modules defined in the test suite</li><li>testing STD against the test suite now produces many fewer warnings about missing modules</li><li>STD now specifically disallows forms like<nobr> <wbr></nobr><code>:!foo(0)</code> and<nobr> <wbr></nobr><code>:5bar[42]</code> that supply unexpected args</li><li>STD now tracks 'of' types in declarations and prevents spurious 'of' types</li><li>STD treats anon enums, subsets, and constants etc more consistently</li><li>removed old type slot from constant declarator, now uses more standard type slots</li><li>random bug fixing</li><li>errors with expectation lists are less noisy, no longer reporting lookaheads and whitespace</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>lots of thinking</li><li>looking at Rakudo-ng today</li><li>plan to do lists tomorrow</li><li>want to get those out of the way</li><li>Jonathan and I think we can merge it for the January release</li><li>should know more after the weekend</li></ul><p> <strong>c:</strong> </p><ul> <li>working on TT #389</li><li><nobr> <wbr></nobr><code>:method</code> should not add entries to NameSpace</li><li>PGE/TGE have problems</li><li>will not land for 2.0</li><li>may add (and immediately deprecate) an experimental op to help migration</li></ul> chromatic 2010-01-26T22:54:19+00:00 journal Perl 6 Design Minutes for 06 January 2010 http://use.perl.org/~chromatic/journal/40123?from=rss <p>The Perl 6 design team met by phone on 06 January 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>in Spec Land, renamed <code>p{}</code> to <code>qp{}</code> to avoid using up another common single letter</li><li>bare <code>say</code>/<code>print</code> is now just a warning</li><li>Carl M&#228;sak dug up fossilized restriction on hash literals, which I removed</li><li>since the insides of blocks are now parsed as statements, there is no longer an inconsistency in line-ending curlies</li><li>refined the picking vs grabbing semantics with respect to immutable vs mutable bags and such</li><li>to avoid legacy confusion, renamed <code>break</code>/<code>continue</code> to <code>succeed</code>/<code>proceed</code> </li><li>clarified that an implicit <code>succeed</code> returns the value of the whole <code>when</code> block</li><li>it is not somehow magically inserted around the last statement</li><li>renamed <code>true</code> to <code>so</code> to avoid confusion of the predicate with the <code>True</code> enum value</li><li>at the suggestion of moritz++, split <code>Any</code> up into <code>Any</code> and <code>Cool</code> types</li><li> <code>Cool</code> stands for Convenient OO Loopbacks, or any other acronym you'd like</li><li>the built-in types derived from <code>Cool</code> are the ones that do Perlish dwimmy coercions</li><li>user types still derive from <code>Any</code> by default, so aren't born with gazillions of methods</li><li>conjecturally, also keep "last-resort" multis in <code>Cool</code> package</li><li>responded non-explosively to a potentially explosive rant/twitter</li><li>clarified various things in response</li><li>it is not necessary that all implementations be equally good at everything</li><li>there will be a minimal Perl 5ish grammar alongside STD that any VM can support as a well-behaved subset</li><li>it is also acceptable to support bug-for-bug compatibility with Perl 5</li><li>the language designer is neither omniscient nor omnipotent</li><li>the design process is therefore convergent on the part of all parties involved</li><li>the rate of convergence is an emergent property, and is to be forced</li><li>convergence is deemed to be positive as long as anyone is still working on Perl 6</li><li>the solidification of the spec is also part of the convergence, and depends on proven implementation</li><li>unproven parts of the spec are to be considered implicitly conjectural</li><li>as implementations converge on specs, we can throw out or delay parts of the spec that as yet unproven</li><li>everyone is allowed to panic <em>once</em>.</li><li>on to implementation, found fencepost precedence error inside list prefix</li><li>moved the default initparse method from STD into Curso so other grammars don't have to define it</li><li>added quote modifier<nobr> <wbr></nobr><code>:p</code> (aka<nobr> <wbr></nobr><code>:path</code>) so we can form the <code>qp{}</code> path literal</li><li>installed better warnings about bare <code>say</code>/<code>print</code> </li><li>generalized the <code>say</code>/<code>print</code> warning to anything a p5er might try that might be in p6 without the defaulting</li><li>STD and CORE now support recent renamings to <code>so</code>, <code>succeed</code>, and <code>proceed</code> </li><li>no longer reports "Bogus statement" when "Missing term" is more accurate</li><li>now catches<nobr> <wbr></nobr><code>/\b/</code> and advises to use an appropriate p6 word boundary assertion instead</li><li>emits better message when an intended reduce is interpreted as composer</li><li>detects most attempts to use postfix after whitespace, and suggests omitting whitespace</li><li>now parses tick-less embedded comment syntax as line-end comment (but still warns for now)</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>took the last couple of weeks off</li><li>keeping up with things, but not much writing code</li><li>read the S01 changes with great interest</li><li>glad to see them</li><li>answered some PGE questions for Carl</li></ul><p> <strong>Larry:</strong> </p><ul> <li>we've talked about them all along</li><li>they weren't written down in an obvious place</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on Parrot</li><li>trying to move as much out of the configure process into a <em>Makefile</em> as possible</li><li>intended to improve the build</li><li>attempting to remove recursive makes</li><li>avoid unnecessary rebuilds</li><li>improve dependency tracking in the build</li><li>probably ready after 2.0</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I'm impressed</li><li>thanks for taking that on; we needed it</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on deprecation notices</li><li>we've talked about a lot of things over the past six months</li><li>not sure they're all in the file appropriately</li></ul><p> <strong>c:</strong> </p><ul> <li>working on bugfixes</li><li>also working on deprecations</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I intend to merge the ng branch before the January release</li><li>some people are antsy, but I have a lot of confidence</li><li>we'll probably pass about 70% of the test suite</li><li>it looks like a regression, but we have different features added now</li><li>lazy lists work, for example</li><li>lots of things fudged in the previous version work now</li></ul> chromatic 2010-01-23T00:12:46+00:00 journal Perl 6 Design Minutes for 16 December 2009 http://use.perl.org/~chromatic/journal/40121?from=rss <p>The Perl 6 design team met by phone on 16 December 2009. Allison, Patrick, Jerry, and chromatic attended.</p><p> <strong>Patrick:</strong> </p><ul> <li>finished my Hague Grant</li><li>sent the final report to Jesse to wild approval</li><li>drafted a new version of PDD 31 on HLL interop</li><li>write some code to implement part of that in NQP's HLLCompiler</li><li>added various tests</li><li>need to get languages using that now</li><li>Rakudo will use that</li><li>it's the basis for Rakudo's <code>use</code> and <code>import</code> </li><li>if it works for Rakudo, it should follow for other languages which use HLLCmpiler</li><li>had a few comments about missing pieces and corrections</li><li>it's still a draft spec, but we need iteration to finish the spec</li><li>working on little bits of code here and there</li><li>adding features for projects which use NQP</li><li>trying to return to using Rakudo and updating the -ng branch</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on the Pynie refresh this week</li><li>started over with the Python 3 grammar</li><li>have that translated into NQP-rx</li><li>it compiles and can parse a few things</li><li>working my way through the grammar</li><li>no actions set up yet</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>there is a<nobr> <wbr></nobr><code>.DEBUG</code> rule</li><li>call it on a subrule to turn on tracing from that rule down</li><li>that saves you from having to put in <code>panic</code> statements</li></ul><p> <strong>Allison:</strong> </p><ul> <li>is there a good NQP-rx tutorial for actions?</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on it</li><li>is your work in the Pynie repo?</li></ul><p> <strong>Allison:</strong> </p><ul> <li>it's in Mercurial on bitbucket.org under project <em>pynie</em> </li><li>that's what Python 3 uses</li><li>also the Parrot roadmap session went very well</li></ul><p> <strong>Jerry:</strong> </p><ul> <li>we still have some actions to take based on that work</li><li>need to convert our priority list into Trac tickets and wiki items</li><li>Parrot's goal for every month until Rakudo * is to support Rakudo * and HLLs in general</li></ul><p> <strong>Allison:</strong> </p><ul> <li>that's valuable</li><li>it changes our priorities in the next year</li><li>it moves things between "would be nice" and "necessary"</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on the roadmap session</li><li>helping with the Context/CallSignature merge</li><li>will do a dry run of the Rakudo release today</li></ul> chromatic 2010-01-22T01:52:43+00:00 journal Perl 6 Design Minutes for 09 December 2009 http://use.perl.org/~chromatic/journal/40115?from=rss <p>The Perl 6 design team met by phone on 09 December 2009. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Will:</strong> </p><ul> <li>some work on NQP port of Partcl</li><li>Patrick has been very helpful</li><li>sent a message to the Parrot list about the planning meeting this Sunday</li><li>initiated a community document to discuss those plans</li></ul><p> <strong>Allison:</strong> </p><ul> <li>implemented large chunks of obscure C code to perform fast string matching using the FFT</li><li>wondering if that'd be useful in Parrot</li><li>maybe we do our indexing operations by character set in the NFG form</li><li>also does very basic pattern matching by leaving out optional characters</li><li>could be useable in the core tests, where it's tricky to depend on PGE</li><li>this was my final assignment before the Christmas break</li><li>have a month off to work on Parrot stuff then</li><li>I'll show off my assignment when I submit it</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>finished my final report for my Hague grant</li><li>haven't quite finished the grant, but left TODO items</li><li>rather than trying to finish everything and then write the report, I'd draft the report and keep notes on what I needed to finish</li><li>need to work on HLL interop</li><li>enable Perl 6 and other Parrot languages to load libraries from other HLLs</li><li>will work on that over the next few days</li><li>had several coversations about optimizations, constants, and inferior runloops</li><li>made minor PAST improvements</li><li>integer constants can automatically promote to num constants without going through a PMC</li><li>updated NQP to make it easier to write custom operator subs, if you're using the operator precedence parser</li><li>implemented the beginnings of smart matching</li><li>not full Perl 6 smart match</li><li>makes sense in the Parrot context</li><li>can match against regexes, tokens, rules, and any types with protoobjects</li><li>code looks more like Perl 6</li><li>not much on Rakudo besides answering questions</li><li>will get back to the Rakudo-ng merge after finishing my grant work</li><li>also worked on Partcl</li><li>updated its regex syntax, particularly for enumerated character classes</li><li>fixed it to handle unquoted, non-word characters in regexes</li><li>previously it only handled barewords as literal matches</li><li>it's closer to the Perl 5 syntax now</li></ul><p> <strong>Larry:</strong> </p><ul> <li>didn't like the name <code>PairValSet</code>, renamed it <code>EnumMap</code> </li><li>likewise <code>PairSet</code> is now <code>PairMap</code>, and <code>PairVal</code> is just <code>Enum</code> </li><li>so individual constant pairs now called "enums"</li><li>we distinguish pairs, which have read-write values, from enums, which are constant in the value</li><li>you can now do<nobr> <wbr></nobr><code>.enums</code> on hashes and arrays as well as enumerations</li><li>differs from<nobr> <wbr></nobr><code>.pairs</code>, which give reference semantics into the values of the original data structure</li><li><nobr> <wbr></nobr><code>.enums</code> gives you a constant snapshot</li><li>David Green suggested renaming <code>Enum.name</code> to <code>Enum.key</code>, and he was right, since they're constant pairs</li><li>trying to be consistent about calling the whole type an "enumeration" and referring to the bits as "enums", even though the keyword is <code>enum</code> </li><li>thought people would rebel at typing the long name</li><li>clarified that the anonymous <code>enum</code> is compile-time evaluated as an anonymous list of constants</li><li>you can always cast to an <code>EnumMap</code> at run time for the other behavior</li><li>simplifying conditional semantics</li><li>STD parser now parses a <code>WHENCE</code> closure as part of the typename, rather than relying on subscript parse</li><li>block escape within a closure within a string used to parse as a normal block by responding to comments outside of the block</li><li>already fixed the embedded block in the regex syntax</li><li>made that usable by strings and regexes now</li><li>blocks in regular code try to figure out if they're at the end of a statement</li><li>look for the trailing curly</li><li>inside a string or regex, there are no statements</li><li>it makes no sense to look for the end of the statement there</li><li>the obsolescence messages were still in the old framework that upsets some Perl 5 people</li><li>changed the wording to "Unsupported use of<nobr> <wbr></nobr>..."</li><li>#perl6 found a precedence inconsistency in parsing of list prefixes vs list infixes in NG</li><li>turned out to be wrong in STD first, and NG copied it</li><li>I fixed it in STD, Patrick fixed it in NG</li><li>otherwise last week was rather too ADD-ish, so mostly did Q&amp;A on IRC</li></ul><p> <strong>c:</strong> </p><ul> <li>fixed some bugs</li><li>made some optimizations</li><li>think I've fixed most constant PMCs in PBC now, which should help NQP and Rakudo</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>it'll take a while before Jonathan and I can take advantage of that</li><li>Allison, when you <code>push_eh</code> an ExceptionHandler onto an array in a context, it creates an RPA</li><li>does that hold other things besides an EH?</li></ul><p> <strong>Allison:</strong> </p><ul> <li>potentially</li><li>events get stored in the scheduler</li><li>only EHs are scoped to a context</li><li>the old <code>pushmark</code>/<code>popmark</code> stuff to do actions used that same global array</li><li>it may have changed to use the same array</li><li>that's deprecated though</li><li>they won't use that array for long</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I need something to replace <code>pushaction</code> and <code>popaction</code> before they go away</li><li>when we handle <code>LEAVE</code> semantics, we want to avoid generating an exception to leave that scope for caching</li><li>I don't want to generate and rethrow actions to go up the stack</li><li>those ops let me do that without generating exceptions</li></ul><p> <strong>Allison:</strong> </p><ul> <li>we do need singleton exception objects for <code>FAIL</code> and <code>RETURN</code> </li><li>no extra information needed</li><li>right now, you can insert anything you want in that array</li><li>the <code>local_branch</code> and <code>local_return</code> uses that array</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>it shouldn't</li><li> <code>bsr</code> and <code>ret</code> may have</li><li>I provide my own there</li></ul><p> <strong>Allison:</strong> </p><ul> <li>oh right</li><li>I might not have checked in that code</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>by the way, NQP doesn't use <code>local_branch</code> or <code>local_return</code> </li></ul> chromatic 2010-01-21T04:41:19+00:00 journal Announce: Parrot 2.0.0 "Inevitable" Released! http://use.perl.org/~chromatic/journal/40114?from=rss <blockquote><div><p> <em>The Beyond and below are like a deep of ocean, and we the creatures that swim in the abyss. We're so far down that the beings on the surface superior though they are can't effectively reach us. Oh, they fish, and they sometimes blight the upper levels with points we don't even understand. But the abyss remains a relatively safe place.</em></p></div> </blockquote><p> Vernor Vinge, <em>A Fire Upon the Deep</em> </p><p>On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0 &quot;Inevitable.&quot; <a href="http://parrot.org/">Parrot</a> is a virtual machine aimed at running all dynamic languages.</p><p>Parrot 2.0.0 is available on <a href="ftp://ftp.parrot.org/pub/parrot/releases/stable/2.0.0/">Parrot's FTP site</a>, or <a href="http://parrot.org/download">follow the download instructions</a>. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using <a href="http://subversion.tigris.org/">Subversion</a> on <a href="https://svn.parrot.org/parrot/trunk/">our source code repository</a> to get the latest and best Parrot code.</p><p>Parrot 2.0.0 News:</p><ul> <li> <p>Features</p><ul> <li>Context PMCs now support attribute-based introspection</li><li>Context and CallSignature PMCs merged into CallContext</li><li>.lex directive throws exceptions when used with incorrect register types</li></ul></li><li> <p>Platforms</p><ul> <li>Packaging improved for free OS distributions</li><li>PPC, PPC64, and ARM now tested when running Linux</li></ul></li><li> <p>Performance</p><ul> <li>Minor improvements to the profiling runcore</li><li>Improvements from the CallContext PMC merge</li></ul></li><li> <p>New deprecations</p><ul> <li>In/out parameters in STRING modification functions</li><li>Void handling in NCI signatures</li><li>Parameter passing opcodes order in PBC</li></ul></li><li> <p>Tests</p><ul> <li>Continued migration of core tests from Perl 5 to PIR</li></ul></li><li> <p>Tools</p><ul> <li>dependency checker improved</li></ul></li><li> <p>Miscellaneous</p><ul> <li>Deprecation cycle length changed to three months from six</li><li>GC accuracy improved</li><li>PMC freeze improvements; much more reliable</li><li>Makefile improvements for dependency handling</li></ul></li></ul><p>Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 16 February 2010.</p><p>Enjoy!</p> chromatic 2010-01-21T04:37:49+00:00 journal Announce: Rakudo Perl 6 development release #24 ("Seoul") http://use.perl.org/~chromatic/journal/40033?from=rss <p>On behalf of the Rakudo development team, I'm pleased to announce the December 2009 development release of Rakudo Perl #24 "Seoul". Rakudo is an implementation of Perl 6 on the <a href="http://www.parrot.org/">Parrot Virtual Machine</a>. The tarball for the December 2009 release is available from <a href="http://github.com/rakudo/rakudo/downloads">http://github.com/rakudo/rakudo/downloads</a>.</p><p>Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github. More details are available at <a href="http://rakudo.org/how-to-get-rakudo">http://rakudo.org/how-to-get-rakudo</a>.</p><p>Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. The December 2009 release is code named "Seoul" for Seoul.pm, who hosted Jonathan so well recently, and because they have <a href="http://en.wikipedia.org/wiki/Soul_Cake_Duck#Soul_Cake_Duck">a cake duck</a>.</p><p>Shortly after the October 2009 (#22) release, the Rakudo team began a new branch of Rakudo development ("ng") that <a href="http://use.perl.org/~pmichaud/journal/39779">refactors the grammar to much more closely align with STD.pm</a> as well as <a href="http://use.perl.org/~pmichaud/journal/39874">update some core features that have been difficult to achieve in the master branch</a>. Most of our effort for the past month has been in this new branch, but as of the release date the new version had not sufficiently progressed to be the release copy. We expect to have the new version in place in the January 2010 release, but may elect to have an interim release from the new branch before then.</p><p>This release of Rakudo requires Parrot 1.9.0. One must still perform <code>make install</code> in the Rakudo directory before the <code>perl6</code> executable will run anywhere other than the Rakudo build directory. For the latest information on building and using Rakudo Perl, see the readme file section titled "Building and invoking Rakudo".</p><p>Some of the specific changes and improvements occuring with this release include:</p><ul> <li>Rakudo is now passing 32,192 spectests, a "decrease" of 561 passing tests since the November 2009 release. We pass fewer tests now because specification changes caused many obsolete (but passing) tests to be removed from the suite -- from 38,318 in November to 37,376 now. The percentage of passing tests has increased, from 85.5% in November to 86.1% today.</li><li>More improvements to the Rat type and related math functions to remain aligned with the specification.</li></ul><p>The Perl 6 language specification is still in flux. Please take note of the following changes, which might affect your existing programs. In the next release of Rakudo, the deprecated features will likely be gone.</p><ul> <li>The root of the object hierarchy has been changed from <code>Object</code> to <code>Mu</code>. The type <code>Object</code> goes away.</li><li> <p>The term <code>undef</code> is gone. You can replace it with other constructs, depending on context:</p><ul> <li> <code>Nil</code> is undefined in item context, and the empty list in list context</li><li> <code>Mu</code> is the most general undefined value which does not flatten in list context</li><li>as a smart matching target, you can replace <code>$obj ~~ undef</code> by <code>$obj ~~ *.notdef</code> </li></ul></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="http://rakudo.org/how-to-help">http://rakudo.org/how-to-help</a>, ask on the perl6-compiler@perl.org mailing list, or ask on IRC #perl6 on freenode.</p><p>The next release of Rakudo (#25) is scheduled for January 21, 2010. A list of the other planned release dates and codenames for 2010 is available in the <em>docs/release_guide.pod</em> 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> chromatic 2009-12-18T08:14:37+00:00 journal