Stories
Slash Boxes
Comments
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)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Monday October 19, 2009
08:56 PM

Perl 6 Design Minutes for 16 September 2009

[ #39773 ]

The Perl 6 design team met by phone on 16 September 2009. Larry, Patrick, Jerry, Nicholas, and chromatic attended.

Larry:

  • mostly worked on my open source ecology talk
  • backlogging after the return from family trips
  • pushing a slideshow of Guy Steele about the implementation of easily parallelized data structures
  • talking over that with Daniel Ruoso
  • helping Matthew Wilson bootstrap his JS emitter for STD
  • not much spec hacking, except a conjecture about the parallel semantics

Jerry:

  • released Parrot 1.6.0
  • went very smoothly
  • really like how boring it was
  • due to release Rakudo 21 tomorrow

Patrick:

  • mostly a lot of thinking this week
  • protoregexes in PGE, for example
  • reran the spectest progress file since the last release
  • Moritz and others greatly improved the calculation of the test suite size
  • previously it looked as if the suite were shrinking, due to plan lines
  • the curve is more accurate since August
  • Rakudo now passes over 15,000 tests -- almost 15,500
  • substantial increase since August
  • most of those tests are of operators on Nums, Rats, and Ints
  • lots of transcendental functions
  • I claim very little credit other than getting the process started
  • turned on HLL mapping for converting Parrot Floats into Rakudo Nums
  • in some places, Parrot Float internals leaked out
  • passed more tests, didn't seem to take a speed hit in the spec tests
  • that wasn't true with Int and String before
  • haven't seen direct reports of slowdowns from anyone else
  • will be able to focus all of my energy in Rakudo and NQP over the weekend

Nicholas:

  • Leon pointed me to a link about Python 3's uptake a year later
  • only about 1% of registered Python packages support Python 3
  • they originally had a 2to3 script to help migrate forward
  • now they also have a 3to2 script to encourage people to write in the new version
  • interesting to see how one version is more important than the other

Larry:

  • we already have a couple of those already
  • it's what kp6 was
  • it's what STD with gimme5 does
  • what I'm trying to bootstrap on viv is
  • the problem is that Perl 5 engine isn't actually capable of supporting the Perl 6 semantics on the bare metal, as it were
  • you either do emulation on top of Perl 5
  • or use cheaters on the innards of Perl 5 to sneak the required semantics in
  • both of those have their downsides
  • code that uses one approach is not interoperable with code that uses a different approach
  • neither of them are strictly interoperable with standard Perl 5 code
  • STD does regexp matching, but it doesn't use P5 regexps to do it

Nicholas:

  • it writes out Perl 5 code to do it longhand?

Larry:

  • yes
  • if you've seen Damian's recent talk on getting the P5 regexp engine to store trees...
  • he had to go through contortions to make that work
  • it's not extensible in the way that P6 regexps are
  • it's only part of the way there
  • it probably has other bugs
  • STD has that emulation layer on top
  • getting that to smoothly stitch Perl 6 code back to Perl 5 as if it were Perl 5....
  • it may be possible at the subroutine boundary, but that's about it

Nicholas:

  • it might have all of the fun of using cfront, then eventually the C compiler chokes

Larry:

  • any time you do multiple passes, you set yourself up for various dislocations
  • most of them painful
  • even so, STD is written in a subset of Perl 6 amenable to backtranslation
  • using that subset of Perl 6 as a better Perl 5 will take you only so far and no further

c:

  • fixed bugs
  • improved performance
  • 1.6 should be faster than 1.4, measurably

Patrick:

  • I have trouble measuring that
  • but my gut agrees
  • we keep doing things in Rakudo that should slow things down
  • but it doesn't get slower
  • I just can't measure it
  • the number of tests per second stays relatively flat
  • Jerry, did you try a practice run of the release?

Jerry:

  • hope to do that tonight
  • started reading the release manager guide

Patrick:

  • it's straightforward

Jerry:

  • it's in English, which helps

Patrick:

  • it's similar to the Parrot steps
  • do a practice release in your own GitHub account
  • the steps are the same as if you were doing a real release
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.