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)

Friday August 07, 2009
07:04 PM

Perl 6 Design Minutes for 08 July 2009

[ #39417 ]

The Perl 6 design team met by phone on 08 July 2009. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

  • sided by several design issues in the past week
  • the number of fundamental issues was higher than usual
  • refactoring the global and lexical namespaces to fit together with their symbol tables
  • Daniel pointed out a problem in my design
  • immutable type objects pointed to mutable symbol tables
  • that didn't quite work
  • had to turn that inside out
  • thinking about the exact semantics of use
  • depends on how symbol tables work out
  • should have that soon
  • thought a lot about the nature of lists
  • are they more primitive than captures?
  • had some discussion about that
  • provisionally called Parcels
  • may be correct to unify them with captures
  • a capture might just be a parcel that can deliver the positionals separately from the names
  • the actual structure might be the same thing
  • Daniel might have a complaint about it

Patrick:

  • I totally agree with the change
  • I just know it's going to muck up a few internals along the way

Larry:

  • we need something to give us the raw arguments in their order
  • has to be what parentheses do by default

Patrick:

  • agree

Larry:

  • that part is not negotiable
  • working on the trait mods
  • Jonathan's been refactoring that
  • still have a collision as a result of defining multis with the same name as we define the new syntax
  • may have to split those
  • the macroish thing which defines new syntax is different from the semantic declaration of the multis called
  • haven't specified that, but it seems like the right approach
  • encouraging other people to hack on the specs
  • encouraged Darren Duncan to swap :auths and :vers
  • he did other cleanup, which was good
  • other people have contributed too
  • doesn't seem to be out of hand
  • clarified value-producing blocks like BEGIN and START as statement prefixes
  • you don't need curlies now
  • you can still do the block form, but they're block or statement
  • you can use a statement prefix as a statement itself
  • the old model of symbol tables in STD used nested hashes
  • using a model now where symbol tables are objects which can function as hashes
  • recombined symbol tables and stashes
  • we can does Hash usefully and get the same benefit in a single object
  • moved back to the notion that the symbol for a symbol table in a package ends in ::
  • tried to get away from that, but it didn't work
  • it's a post-sigil, now
  • the name canonicalizer in Cursor now leaves the double-colon at the end of prefix packages
  • makes it simpler to look up
  • fixed a bug related to pad exporting
  • chose the wrong pad
  • now the declarand (the declared object) remembers the appropriate pad for the rest of the declaration
  • if you put =$fh as the only thing as a line, now it complains about an illegal POD directive
  • changed constants to be our instead of my, last week
  • more chance of name collision within packages and lexical scopes
  • I fixed the error message for a collision
  • aligned a few more things to the specification
  • changed MMD with Jonathan
  • mandatory, named parameters are part of the constraint on a multi
  • where STD uses that, it declares those parameters as mandatory
  • the spec claimed that adverbs and fat-arrow plus circumfix are semantically equivalent
  • fixed the circumfix semantics there in the parse

Patrick:

  • added more operators to the Rakudo setting
  • fixed a few PGE bugs
  • talked with Allison about Parrot's installation
  • mostly talked about various issues on IRC
  • lots of planning, brainstorming, and prioritization for Rakudo and Perl 6
  • starting to put together plans for how Rakudo 1.0 will look and when it will come out
  • not sure I'm the right person to work on Rakudo install refactor
  • will post a couple of messages about that to the list to recruit others
  • looks like a lot of important refactoring, but I'm not sure I'm the right person to do that
  • getting together stuff for OSCON and YAPC::EU
  • finishing up other Parrot tasks for the 1.4 release
  • especially HLL interop
  • posted instructions for other people to do releases of Rakudo
  • anyone can do a release; they don't need to wait a month to do it
  • anyone who wants to practice could just do one anytime
  • GitHub allows that very nicely
  • anyone who wants to be a release manager can practice anytime

c:

  • working on Rakudo-exposed GC bugs

Allison:

  • trying to catch up on tickets and answer questions
  • halfway through the ticket queue
  • everything needs a quick skim at this point
  • have intentionally not made any plans for the next couple of weeks
  • will focus on the release (when I'm not working on OSCON)
  • can work on the install stuff
  • though I think we should do as little as possible to get it working

Patrick:

  • I won't try to refactor Parrot's make install
  • Rakudo wants to be able to build from an installed version of Parrot
  • may give up on installing from a build copy
  • the downloader installs Parrot to a new directory
  • the only blocker there is being able to get a fakecutable working
  • need to go through and add conditional Makefile generation to Rakudo's generate script
  • am I missing anything?

Allison:

  • did it ever work from an installed Parrot?

Patrick:

  • can't do a fakecutable there; that never worked
  • I can build Rakudo
  • it can run if you run the bytecode file
  • it won't run from the perl6 binary
  • we need something that can run from there
  • people expect that

Allison:

  • the fakecutable works if you keep the build directory around
  • but not from an installed Parrot

Patrick:

  • the other problem is the search path of the dynext/ directory
  • in a few places parrot_config reports compiler settings that won't work on some platforms without conditional makefile generation

Allison:

  • it'd be good to get a list of what those are

Patrick:

  • I'll make that list soon
  • part of the reason I've pushed on this so hard is because we need it
  • it has to happen before Rakudo 1.0, but I'll spend my development time elsewhere

Allison:

  • we'll get it as soon as possible

Jerry:

  • as soon as practical

Patrick:

  • I like that phrase

c:

  • if I use a class as a role in a does statement, is that okay?

Larry:

  • with some caveats, yes
  • it takes a snapshot of the class

Patrick:

  • my goal between now and the end of YAPC::EU is to develop a detailed plan for Rakudo 1.0
  • would like that release to happen by next spring
  • if it happens sooner, great
  • 1.0 is just a marker tag
  • beyond a developer release

Larry:

  • Rakudo 1.0 doesn't have to implement all of 6.0.0
  • it can be a beta of Perl 6, for example

Patrick:

  • need to define what things need to be in that release
  • not just spec, but ancillary features
  • before that release, we need to use something much closer to STD, if not STD itself
  • will make a list of what things need to be in there
  • I want to get Rakudo to the point where we can say "It's ready for some real uses"

c:

  • is there a performance target?
  • I'd like to see at least a doubling in speed
  • that's not entirely your problem

Patrick:

  • that may happen on its own
  • I think that's reasonable
  • that's the minimum we can get

Jerry:

  • how about working with other Parrot HLLs?

Patrick:

  • not sure it's a Rakudo or Perl 6 prereq
  • maybe Parrot

Allison:

  • I wouldn't put it on the Rakudo list

Patrick:

  • we need a better module system

Jerry:

  • a bunch of good questions will come up
  • having a set of release managers in place will make that easier

Patrick:

  • July will be the last release I do by myself, assuming release managers pop up
  • and I assume they will
  • modeling this after the Parrot Development Summit last year
  • charting our progress to 1.0 like Parrot did
  • my goal is to finalize things at YAPC::EU
  • want to publish a document with milestones and timelines after that

Jerry:

  • might be nice looking at which percentage of the spec the tests cover
  • and what Rakudo's passing tests cover

Patrick:

  • talked about this with Jesse
  • very good discussion
  • will go through each synopsis and review how Rakudo does with each section of the synopses
  • break it down, give each heading a percentage
  • would be nice if there were automated tools to help with that

Jerry:

  • can smartlinks help?

Patrick:

  • potentially
  • I don't want to block on it
  • might shuffle that off to someone if there's an easy task
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.