schwern's Friends' Journals http://use.perl.org/~schwern/journal/friends/ schwern's Friends' use Perl Journals en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T01:44:50+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 schwern's Friends' Journals http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~schwern/journal/friends/ 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 Gone http://use.perl.org/~Ovid/journal/40243?from=rss <p>Like many others, I'm no longer posting here very much. You'll find my new technical journal at <a href="http://blogs.perl.org/users/ovid/">blogs.perl.org</a>. It's much shinier.</p><p> <a href="http://siteanalytics.compete.com/use.perl.org/">As you can see, use.perl visits have been dropping for a while</a> (blogs.perl.org is too new to show up on that search) and the <a href="http://use.perl.org/">front page of use.perl has been sadly neglected</a>. As for blogs.perl.org, after an initial rough start, <a href="http://blogs.perl.org/users/adam_kennedy/2009/12/migrating-from-useperlorg-to-blogsperlorg.html">plenty</a> <a href="http://blogs.perl.org/users/thefinalcut/2009/12/first-post-on-the-shiny-new-onion.html">of</a> <a href="http://blogs.perl.org/users/limbicregion/2009/11/goodbye-useperlorg-hello-blogsperlorg.html">people</a> are switching over and are very happy with the shiny.</p><p>I have fond memories of use.perl.org, but it's just too old and out-of-date. Come on over to our new platform and look around. Plus, <a href="http://github.com/davorg/blogs.perl.org/issues">tell us what you want changed about it</a>. (To be fair, while I was involved in the project to get it launched (mostly kibitzing and asking why things were stalled -- I'm such a marketroid<nobr> <wbr></nobr>:), the hands-on work was Dave Cross, Aaron Crane and the wonderful folks at <a href="http://www.sixapart.com/">SixApart</a>.)</p> Ovid 2010-03-14T08:02:43+00:00 journal 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 Test::Class::Most http://use.perl.org/~Ovid/journal/40148?from=rss <a href="http://blogs.perl.org/users/ovid/2010/01/-package-sometestclass.html">Test::Class::Most</a>. Ovid 2010-01-31T19:25:10+00:00 journal Testing with PostgreSQL http://use.perl.org/~Ovid/journal/40145?from=rss <p>My new personal project has a PostgreSQL database. <a href="http://blogs.perl.org/users/ovid/2010/01/testing-postgresql.html">Here's how I'm handling testing</a>.</p> Ovid 2010-01-30T16:22:57+00:00 journal 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 Roles without Moose? http://use.perl.org/~Ovid/journal/40127?from=rss <p> <a href="http://blogs.perl.org/users/ovid/2010/01/roles-without-moose.html">Milliseconds are important</a>.</p> Ovid 2010-01-25T14:04:31+00:00 journal 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