Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Monday October 26, 2009
09:05 PM

Perl 6 Design Minutes for 14 October 2009

[ #39806 ]

The Perl 6 design team met by phone on 14 October 2009. Larry, Allison, Patrick, and chromatic attended.


  • have a question
  • I'm not happy with the :lang attribute in regexes
  • I'll explore in my own direction
  • Larry can complain about that when he gets back


  • I wouldn't expect anything less


  • worked more on nqp_rx
  • PAST- and POST-based
  • going exceedingly well
  • I have almost every feature that PGE provides
  • what's left is minor
  • either we don't need them and/or they're easy to add when necessary
  • the new engine passes about 3/4 of PGE's test suite
  • the rest is minor
  • specifying characters by number or Unicode name, for example, \x and \c
  • today's task is to make the new engine self-hosting
  • the regex parser should be able to parse itself
  • that shouldn't be hard to do at all
  • that'll also speed things up quite a bit
  • it's currently two or three times slower than PGE when running the tests
  • that's because the regex parser is slower
  • the code that does the matches is much faster
  • that's a nice tradeoff; we generally parse regexes once and run them a lot
  • adding features to the new engine has been incredibly easy
  • many of them tend to be five or six lines at most
  • it's a bunch of short code
  • I'll continue working on that for the next week
  • I expect to write the new version of NQP in the next couple of days


  • working on the pcc_reapply branch of Parrot
  • lots of fixes there
  • went down from 82 failing tests on the corevm target to 18 failing tests on the full Parrot test suite
  • PGE now compiles and runs just fine on the branch
  • still working on the last few failures
  • started doing language testing as well
  • Cardinal and another language pass on the branch with no problems
  • have CallSignature optimizations ready to merge in
  • waiting for one feature from chromatic on that
  • also, quantum computation is a lot of fun


  • refactored CallSignature PMC to optimize it
  • one last change to make
  • where did the 12,000 passing Rakudo tests come from?


  • mostly trig, transcendental, and math functions
  • they're automatically generated for Int, Num, and Complex
  • it's a nice jump on the graph
  • we need to put out a nice message about what happened
  • I'll talk more about the percentage of the suite passing than the number of passing tests
  • the argument "You can add thousands of passing tests and not make progress" makes some sense
  • that's why I'll talk about percentage of the suite from now on
  • I'll report for Jonathan too
  • he's redoing parameter binding in a branch
  • currently, that's fairly slow in Rakudo
  • after we call a subroutine, we perform the type checks and throw exceptions if necessary
  • we do binding from incoming parameters to lexicals there too
  • that all required a lot of method calls
  • every subroutine call in Rakudo caused at least four or five Parrot method calls
  • he's redone parameter binding
  • primarily in C
  • he's created a set of dynops to make it much quicker
  • Rakudo's Subroutine PMC type can do the type checking before invocation now
  • he's seeing a significant performance improvement there
  • the pcc_reapply branch in Parrot will also simplify what he's doing there
  • he expects to merge before the release next week
  • it's been outstanding work
  • do we have an ETA for the branch landing?


  • very shortly after 1.7
  • within minutes or hours


  • that fits our planning well
  • Parrot releases 1.7 next Tuesday
  • Jonathan will probably merge his branch in then
  • his branch will use Parrot's existing calling conventions
  • if someone tries to build Rakudo today or Jonathan's branch against pcc_reapply, Rakudo will likely fail
  • we're fine with that
  • don't consider it a blocker for Parrot
  • we'll adapt to whatever you do
  • I expect that Rakudo's trunk will run against the 1.7 release until 1.8
  • we have two major projects
  • one is converting our argument handling to Parrot's new PCC
  • the other is completely replacing Rakudo's grammar to use the new NQP
  • almost all of our work will take place in branches, not trunk
  • we'll merge back to trunk when we have everything working
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.