Recently in Parrot Category

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

Patrick:

• continuing to prepare Rakudo for its next release
• expect that to happen today
• for now, the releases will be alphabetical: words beginning with A, B, C, D, etc.
• partially to emphasize that I don't consider these user-ready releases
• putting a number on that may imply that
• no easy way to tie releases to numbers right now anyway
• some people have said "What happens when you get to X?"
• I hope we're releasing official releases by then
• updated Rakudo's test harness
• no longer requires Parrot's test harness
• it now passes over 7000 spec tests
• Jonathan gets most of the credit for that
• he's been closing tickets and fixing bugs while I've been working on build issues
• totally unplanned to hit that number
• updated the spectest progress files to show our progress
• haven't updated the graph today
• following along conversations and trying to keep track of various changes

Allison:

• spent the week mainly on install stuff
• various languages can build from an installed Parrot without depending on the build directory
• still some hard-coded paths within Parrot's configuration system for C compilation
• Rakudo and Partcl can definitely build from an installed Parrot
• need to do Pipp next
• set up a languages repository on svn.parrot.org
• waiting for some admin work on that
• came up with a saner version number strategy

Patrick:

• I find it much easier to say that January and July are the memorable releases than to attach numbers to them

Allison:

• with Ubuntu, it's likely we'll get 1.0 and 2.0 into the distribution and not say 1.4
• they have an upstream packaging freeze about a month before we put out our release
• the release that goes into their 09.10 will be 1.0, not 1.4, because the latter won't be out in time

c:

• why not 1.3?

Allison:

• that's a developer release

c:

• we're going to have to talk about that

Allison:

• we have a final copyright assignment from the Perl Foundation to the Parrot Foundation

Jerry:

• have some small pending changes to S19
• nothing much to report there
• Google's giving a GSoC presentation at the University of Washington
• they've asked me to speak about our experiences last year with TPF
• I'll invite people to join the Perl and Parrot Foundations project this year
• hope to have an ideas page to point people at at that point

c:

• have you spoken to Jonathan Leto about that?

Jerry:

• only heard about it yesterday
• it's on my list
• looking for presentations on GSoC to find slides to borrow
• about all I've had time to do lately

Larry:

• having a really nice problem
• a lot of people are helping to flesh out the specifications
• the nice problem is that they have to be managed
• trying to oversee what people are hacking into the new specs
• want to make sure things don't go too far afield
• weighed in on event processing and inexact numeric matches on the mailing list
• nothing there is quite spec-worthy yet
• doing name-whackage of various sorts
• killed off the $*DEFIN, $*DEFOUT, $*DEFERR symbols which emulated Perl 5's old IO select states
• not it relies on that those are contextual vars: $*IN, $*OUT, $*ERR
• any scope can override them
• that's simplification
• many compiler variables that were redundant and error prone with regard to nested scopes
• you now chase links through your symbol tables to find out your lexical or package nesting
• unhandwaved how a setting can loop around user code
• you can mark it so that it knows how to dump the lexical scope surrounding user code
• there's a stub in there called YOU_ARE_HERE
• I'm open to better names
• clarified associativity at the same precedence level
• that can happen with user-defined operators
• non-associative in that case, so you get an error
• noticed that the tighter and looser precedence generators only produced precedence levels that were close to one that exists
• wanted the ability to define something in the middle
• if you use both in the same precedence level, it splits the difference

c:

• sounds like you need a synonym: between

Larry:

• tried that, but you have to specify two things anyway, and there's already syntax for that
• after the discussion of time semantics, put in two core types: Instance and Duration
• defined to be well-behaved in terms of time
• most of my standards hacking has been in user-oriented error messages
• now an error message that warns you if you try to use a C++ constructor

c:

• can we backport that one?

Larry:

• it's also a valid Perl 5 constructor
• just thought it would be more insulting to call it a C++-style constructor :-)

c:

• I still want it

Larry:

• previous patch to catch Haskell-style open-ended ranges where you leave out one of the terms
• that prevented talking about any .. operator in square brackets
• we couldn't use the notation where you put square brackets around infix operators
• I had to fix that
• fixed up the warning when interpreting if() as a function call
• introduced enum names into the symbol table
• it's a bit of a hack
• anonymous enums now parsed correctly
• no more complaints of missing package when you use CALLER:: or CONTEXT::
• can now introduce term symbols, as well as prefix, infix, and postfix
• other random warning-suppresion bugs

c:

• working on project management, version numbers, deprecation, triaging guidelines
• trying to fix as many bugs as possible
• reviewing SKIP and TODO tests

Jerry:

• I read your Setting work this week
• can you roll back a Setting?
• can you access something outside the current Setting?
• I don't have a use case
• is it as simple as calling OUTER::Setting?

Larry:

• if there are multiple settings, they're just enclosing lexical scopes
• any mechanism to navigate lexical scopes works
• the outermost is CORE:: and so forth

Jerry:

• to cut off a file in mid-stream processed with -n, could I close the handle in CORE::?

Larry:

• chances are that's a dynamic variable, a $*ARGV equivalent

Jerry:

• can I find out which Setting I'm currently in?
• finding out its name
• inside my current runloop, can I tell which Settings I have loaded?

Larry:

• we probably want to have a way of naming them, much as CORE:: has a name
• lexical scope should have a way of saying "My lexical scope has a name, and it is..."

c:

• O-S-C-A-R?

Larry:

• ... but I haven't thought about that yet

Jerry:

• any status on protoregexes and stuff?

Patrick:

• I end up being the person of last resort to do things that need doing
• had hoped that other people would pick up the ball on build issues and stuff
• I can make predictions for the next few months, but life catches me off guard
• once I get back to working on PGE, it won't take too long
• it would bug me more if the lack of those features were holding Rakudo back
• that doesn't appear to be the case
• we're making good progress and we're getting new features
• we could use them for adverbs, but we can work around that now
• if that reaches a pain threshold, it'll move it higher in the queue
• that's where I'm focusing my efforts

Jerry:

• Jonathan's very good at moving things forward

Patrick:

• it's fortunate that each of us tends to like doing what the other person hates
• with the exception of lexicals and the build system

Allison:

• no one ever wants to do a build system

Patrick:

• delayed binding helps this though
• seeing grammar changes as they come up makes it easier to figure out what to do
• with the Setting code now, and features written in Perl 6, we're closer to finishing one of my milestones

Jerry:

• how will the install process be for Rakudo?
• it seems like Parrot is doing the heavy lifting there

Allison:

• I've been working on independent building
• what would you like for installing?
• an install script where you identify your language files, and it puts them there?
• you have a languages/ directory in the Parrot lib directory
• you have configuration files that tell you where they are
• you just copy files after that

Jerry:

• certain things might need changing
• grouping the docs?
• cross-indexing?
• if you're doing dynops or dynpmcs?

Allison:

• haven't been doing any doc installs, just executable files
• maybe they should go in with the Parrot docs
• installation works via a MANIFEST
• you specify the type of file with a tag in the MANIFEST, whether doc or lib
• are you happy to have a MANIFEST in your language directory
• let the installer take care of it for you?

Patrick:

• if there's a script to do the install, we'll probably use that
• I just want to get it so that people can build and run Rakudo
• I'll probably look at installation in a month or two

Allison:

• I'll look at a simple MANIFEST for Rakudo
• will patch your Makefile for that
• will build a basic installer script
• it'll be a basic, working install

Jerry:

• the mk_languages_shell.pl script needs an update to make a MANIFEST
• François has been keeping that up to date

Allison:

• I haven't added MANIFEST to any other languages yet

The Perl 6 design team met by phone on 18 February 2009. Larry, Patrick, Allison, Jerry, Nicholas, and chromatic attended.

Larry:

• fixed STD so that if you added A::B, it added A as a subpackage
• so as not to complain about a missing package declaration
• can now have $! as a parameter
• mostly working over a lot of the error messages to be friendly to Perl 5 programmers
• if you use do/while or do/until it now complains
• if you use if or one of the keywords as if it's a function, it tells you what the problem is without saying "I don't recognize that function name"
• people coming from a Haskell background think they can write 1.. to get an indefinite range
• it now tells them what they should write instead
• fixed a bug which reported runaway strings which start and stop on the same line
• not really a runaway
• now it reports that only if the string crosses a newline
• in the spec space
• to accompany the ability to use a bare sigil in declarations as an anonymous name, now you can use a bare :: to signify an anonymous package name or type
• allows us to have a package named is without ambiguity
• blew away the Main package; combined it with the GLOBAL package
• everything in the main program comes up starting in the GLOBAL namespace

Patrick:

• oh, I'm happy!

Larry:

• thought the distinction served no useful purpose
• continued doing spec work combining context variables with globals
• at least in terms of twigils
• realized that filehandles belong to the PROCESS namespace, not the GLOBAL namespace
• continuing on the vein of .Whatever on most normal operators builds a closure of one argument
• made *.method do the same thing
• even in places which are not syntactically special, we can use *.prime in a grep for example
• equivalent to putting .prime in the curlies
• now we have a fairly general mechanism of writing closures of a single argument
• actually reads pretty well if you don't want the curlies
• we could go as far as to undo the special syntax on whens and ~~ so you have to say *.foo to call a method
• still thinking about that
• would regularize the syntax slightly

Patrick:

• had a little emergency over the weekend, but things are fine
• improving Rakudo's build process to make it easier to build
• someone who wants to build it can get a copy of the repo and pass a special option to Rakudo's Configure.pl
• that'll download a copy of Parrot from the right revision and build it for you
• people who want to play with Rakudo don't have to play with Parrot dependencies
• Jonathan and I have most of the guts ready to start writing Setting code
• we can start to write methods in Perl 6 instead of in PIR
• we'll gradually migrate methods which make sense to rewrite in Perl 6
• moving those over into the Setting code
• that'll make it easier for people to hack on
• some things will remain in PIR, but we don't know what those are yet
• most of my plans for this week is doing more cleanups in the build process
• rewriting Rakudo's t/harness to remove dependencies on Parrot files
• have that mostly done
• writing some articles discussing Rakudo's new home
• how to get it, how to build it, and updating websites

Allison:

• working on Parrot's install process
• making it so that Patrick doesn't have to build and install a whole copy of Parrot to build Rakudo

Patrick:

• we'll need that for some time

Allison:

• trying to make it so that people who build and install packages have an easier time
• you won't have to depend on a Parrot build directory
• you can run against an installed Parrot

Patrick:

• I would like to get rid of the build tree dependency

Allison:

• the patch I have gets rid of most of the build tree dependencies
• there are a few header files in weird locations
• they don't get included in PMCs and dynops
• I've fixed all of the build tools
• all that's left is C-level stuff
• should probably send you to the patch to experiment with
• lots of stuff preparing for the release
• seems to be encouraging that we've been getting more novice questions
• seems to be an influx of interest here

c:

• talking to Richard Blackwell about YAPC
• Parrot and Perl 6 hackathon needs
• working on TODO/SKIP test review for Parrot
• also pondering bug triaging guidelines for Parrot
• having some discussions about release policies and deprecations (though mostly Perl 5)
• setting expectations early seems to help a lot

Nicholas:

• what projects did you look at, or did you look at things afresh?

c:

• Subversion's really early milestone release process was a real inspiration
• the Linux kernel's backwards compatibility policy was also
• not much besides that

Jerry:

• Ubuntu's long term support is pretty nice

c:

• I'm a little less thrilled there
• even six months time is a long span between releases

Allison:

• that's kind of a corporate support guideline

Patrick:

• I like knowing that Hardy will be supported for a few years

c:

• that's a risk for them
• how long are they going to support KDE 3 when upstream doesn't?

Nicholas:

• RHEL and other enterprise distributions support Perl 5.8 until 2011 or so
• but we haven't heard anything from downstream there
• and we only support critical security fixes there

c:

• I put in expicit language about vendors promising long-term security fixes
• that's your vendor's problem, not the problem of volunteers

Nicholas:

• in Perl 5, you used to do package; with no namespace
• removed somewhere in 5.8.x
• was such a thing considered for Perl 6?
• you basically banned all unqualified variables

Larry:

• it was a hack in Perl 5
• I want to make new mistakes

Patrick:

• I expect to do Rakudo's next release next Wednesday
• that's a target anyway
• I'll be out of town this weekend
• we'll start its regular release clock with that release
• we'll do monthly releases
• that exact date will vary by a few days here or there until we get the release process down

Jerry:

• will you have a similar release structure as Parrot
• multiple release managers?

Patrick:

• yes
• I don't want to be the single release manager
• I'll probably do the first couple
• I want at least one other person to do some by May or June
• ideally a team
• the Rakudo release needs to happen very quickly after the Parrot release
• we won't be able to do this this month
• what do we need to think about for POD in Perl 6?
• what we have now is "DRAFT DRAFT DRAFT"

Allison:

• can you say "We'll target this version and update if necessary?"

Patrick:

• that's exactly what I've done so far

Larry:

• I agree

Patrick:

• I expect to generate or write a fair bit of POD

Larry:

• it's amenable to mechanical translation
• someone should write a standard parser for POD

Allison:

• Parrot might as well stick with the standard

c:

• are you suggesting a Parrot-based POD6 parser?

Allison:

• if you develop a POD6 parser in Perl 6, could we compile it back down to PIR and use it?

Patrick:

• we'd more likely target NQP
• Rakudo expects the Perl 6 runtime available
• it'd be nice to say that that's just a PBC, but it's also PMCs and dynops

Jerry:

• makes me wonder how small we can make a Parrot distribution that only contains NQP as a language

c:

• that's the Parrot 2 proposal

Jerry:

• I meant ripping out all ops and PMCs you don't need
• maybe no IMCC

c:

• it's not PBC compatible though

Allison:

• he's talking about a version of Parrot built on as few basic opcodes as possible

c:

• no PMCs or ops written in C

Nicholas:

• I thought the computer scientists proved that you only need one operation to make things work, sort of a compare and jump

Jerry:

• then you have Lisp

c:

• but you need infinite storage space

Jerry:

• disk space is cheap, and getting cheaper

c:

• but not infinite
• you can climb that asymptote all you want, but it keeps getting steeper

Patrick:

• the ultimate slippery slope argument

Today was Rakudo day, and I used it to get a bunch of fixes in place as well as applying some patches from other folks. Before digging in to the details, I'm happy to point out that we're now passing over 7,000 spectests - in fact, we got past that last night, before today's round of fixes, so we're well over it now.

• Fixed a bug involving the === operator and proto-objects; specifically, if you had an attribute "has Foo $!x" and in a method - without ever having changed $!x - did "$!x === Foo", it wrongly gave False.
• Whatever wrongly inherited from Object rather than Any, as S02 says it should. Changed this, which allowed me to resolve a ticket.
• Was happy to find an enums related bug report that had already been fixed - this time, by the type registry coming into existence last month. Added a couple of tests to make sure the bug didn't come back and closed the ticket.
• Got bare sigils in signatures working. This turned out to be quite easy, resolved an RT ticket and made ten or so tests that were skipped in assign.t pass too. So you can now do things like:
  my ($, $, $, $four) = 1..4;
my ($one, $two, *@) = 1..4;
To only assign some things. Note that *@ is just the slurpy array * - it's a signature (and in fact you would now be able to write *@ in a signature on a sub too).
• masak discovered that:
  say "a".."c" Z "?", "a".."b"
Gave the wrong output and reported it. bacek sent in a patch. Mortiz wrote a test. Which just left me to review and apply the patch and untodo the test. Teamwork for the win.
• Calling .parse on a grammar that is in a namespace did not work. I fixed it and added a test.
• Our multi-method dispatch has never been quite right, and has long been on my fix list. Now it's at least a lot more correct, in that if it finds no applicable candidates in the current class it now goes looking up the MRO.
• While I was in the multi-dispatcher, I realized that every time we got a cache miss, we leaked a little memory. Fixed the leak. Was glad that Rakudo only has a little bit of C...I'm too stupid to get manual memory management right.
• Did some tweaks to the way we construct subsets to make them act a bit more type-ish, and make sure that the type object works like a proto-object (that is, it's undefined). May need some more tweaks, but it fixes what .defined does and passes all the current spectests for this.
• Applied some documentation patches from leto and Chris Dolan. Easy work thanks to the github fork queue.

Additionally, I tracked down where the perl6 executable often crashes with a double free or got into an infinite loop on exit (it was a problem that only showed when using the executable, and not when using the bytecode file on Parrot - not because the problem wasn't there, but because Parrot didn't bother to reclaim the memory on exit so it never ran the cleanup code that exploded). I wrote a patch which sucked, but prevented the double frees. I showed it on #parrot, at which point pmichaud - now knowing where in Parrot the problem lay - churned out a much smaller patch that was more correct and more efficient. It's in, we bumped up the recommended Parrot version for Rakudo and I closed some tickets about segfaults.

So, thanks to Vienna.pm for sponsoring Rakudo Day this week. There won't be one next week, since I'll be taking some vacation. This weekend is the Belgian Perl Workshop, and the weekend after is the Ukrainian Perl Workshop, so I'm going to spend a bit of time in each of those countries between them, relaxing and enjoying the sights, the beer and the food. And of course, very much looking forward to seeing folks and talking about Perl 6 and Rakudo at the workshops too!

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

Larry:

• hacking symbol table support into the STD parser
• so that I can tell when things have and haven't been defined
• largely complete
• started moving the lexical pads out to a separate file
• they have more information in them
• the Setting file, formerly the Prelude, is now parameterized so that other Settings can be set for the lexical settings
• lots of work on various error messages associated with declaration, non-declaration, and redeclaration errors
• just checked in a unification of the + and * twigils
• threatened that for a long time
• prototyped that in the STD parser
• it seemed to work
• hacked that in
• now we only have the * twigil
• it essentially does the contextual variables
• it looks in global and process symbol tables if it doesn't find them locally
• it looks in the environment only after failing to find it in global and process
• it's very easy to hide that, or substitute a vetted environment table somewhere in your dynamic scope
• cleaned up the definition of how environment is passed on to the subprocess
• dealing with the twigil changes in the Spec
• cleaning up the pseudopackage names somewhat
• regularizing the setting and file scope and current compilation unit and their relationships

Patrick:

• went to Frozen Perl this weekend
• gave one major presentation on Perl 6
• a couple of lightning talks on PCT
• had a hackathon on Sunday
• that went well
• there's a lot of enthusiasm for Rakudo and Perl 6
• Andy Lester focused on that for his keynote
• lots of people talking about it outside of that
• lots of people starting to look at Perl 6 again
• "We're getting to an implementation"
• "These features are nice"
• "I'm looking forward to using this in my business"
• trying to update the instructions to download and build Rakudo from its new repository
• coming along more slowly than I'd like
• noticed at the hackathon that invoking Rakudo with the Parrot command line — parrot perl6.pbc — is confusing for folks
• Parrot's not in a common location they can get to it from
• we'll try to focus more on the executable form
• people can understand that more
• noticed that pbc_to_exe took an inordinately long time to do its work
• hacked on that, and the new version is a lot faster
• learned a lot about IO in Parrot
• tweaking the build scripts for Rakudo
• plan to do more of the same
• will write up more documentation, READMEs, guides, blog posts, etc

Jerry:

• interested in the work on the Setting
• might work with one of the S19 options I've toyed with
• -E to include an environment variable
• can be generalized into a one-liner to add a setting
• had some minor updates to S19
• don't have the split/comb update quite right yet
• been fighting with Parrot's Windows compatibility through changes in the config system
• discovering some things this week about static and shared library linking
• working toward a solution there
• started creating an Ubuntu VM for distribution to interested hackers
• has all sorts of Perl 6-related projects
• Pugs, Rakudo, Parrot, November, Apache, mod_parrot
• VMWare image that should fit on a 16 GB thumb drive
• will make that online
• should make it easier for people who want to hack on Rakudo to do so
• provided we can set up tools to manage and update these distributions

c:

• closed some bugs
• checked in the support, deprecation, and release policy
• brainstorming ideas on how to make a VM with less C code

Nicholas:

• does a VM really take 16 GB?

Jerry:

• I don't think it will
• that's how big I have it now
• it can probably be smaller
• I'm not familiar enough with a minimal install of Ubuntu with enough space for GCC and the build tools

Nicholas:

• it wouldn't fit on a CD
• it might fit on a DVD
• assumed that burning a DVD is a more disposable way of giving it away
• they're effectively free

Jerry:

• I'll consider that
• hadn't thought terribly about distribution
• I can resize it smaller at any time

Patrick:

• just did an Ubuntu install yesterday
• GCC, Git, Subversion... no Parrot yet
• it's a fresh install
• looks like 3.5 GB
• I can generally work in 6 GB
• that'd fit on a dual-layer DVD

c:

• maybe look at a live DVD
• add to that

Patrick:

• Ubuntu lets you boot off a USB drive
• you keep your storage with you

Jerry:

• want to give Jesse credit for Prophet and SD, which syncs with RT, Hiveminder, and Trac
• offline access to bug queues and TODO lists
• it's nice to travel to a venue and then sync so everyone sees how productive you are when you're not connected
• going to put that in the Perl 6 dev VM

Patrick:

• I want that!
• especially with all of the traveling I'm doing

The Perl 6 design team met by phone on 04 February 2009. Larry, Jerry, Will, Patrick, Nicholas, and chromatic attended.

Allison:

• successful migration of the Subversion repository to svn.parrot.org
• took up chromatic's ticket challenge and closed a handful a day, applying patches, fixing bugs, clearing out some old TODOs that don't fit with current architecture
• started, completed, and merged in the second string refactor branch, a large-scale function name cleanup
• a few fixes on the POD parser, mostly handed it off to kj
• updated the Parrot Ubuntu packages on the PPA with instructions for using it
• speaking about Parrot at IBM tomorrow

Jerry:

• enjoyed the lively discussion with mtnviewmark, timtoady, and others about metaops
• really like where that ended up
• Jonathan should be making some rakudo commits shortly to clean up the cross metaop spectest failures
• thanks to Larry's comments, i'm polishing S19
• haven't had much uninterrupted time lately, so progress has been slower than I like
• keep thinking that's going to clear up soon... but that hasn't been
the case for weeks now

Larry:

• completely revamped STD.pm's metatoken parsing
• treating generated metaoperators as longest tokens did not scale
• chasing the implications of that through
• LTM occurs on the metaoperator itself separately from the base operator
• (most of the base operators are infixes)
• what it modifies gets parses as a separate token
• has implications on the order you check things
• != isn't a separate token
• has to be parsed with the combination of the ! metaoperator
• cuts the number of tokens way down
• the lexer runs a fair bit faster
• invented a new notation for disambiguating infix operators
• they may now all be put in [], the same form as reduce operators
• internal to a metasequence (need a new name for that) sometimes need to identify which operator to apply in which order
• &[] now refers to the infix function itself
• makes it easy to pass binary operators into various functional programming primitives
• reduce operator still stays out in front with square brackets
• just generalized the notation
• made more comments on S19
• moving away from the notion of a Prelude
• provisionally now called a Setting
• it implies things before and after the text of a program
• the -n and -p loops put a scope around the scope of your file
• invented several new pseudo-package name prefixes to refer to the Setting
• PERL is the outermost setting as well as LANG for the sublanguage the file is actually parsed in (such as from -n or -p)
• just changed the Prelude to the Setting option in S19
• chopped out the old, non-trie lexer since we're not using it
• thought it might clean up the looks of the LTM for anyone interested in implementing his own
• not that mine is a parallel matcher yet....
• still something I'd like to do
• maybe I won't have to
• working with Mark on revisions to the new metaops (old minus metaops from last week)
• many binary operators could use a metaop which reverses their arguments
• would have the same effect on comparison operators as reversing the sense of the test
• mutated into a R operator
• and the X operator lost its second X to work the same
• started a trend: adding more metaoperators with a prefix capital letter is a good approach
• might end up with Z for a zip with operation
• working on moving some of the preludey/settings stuff out of STD.pm into a separate file
- working over the various symbol tables to do lexical scoping more sanely - this is prep work for parsing a real Setting file and dumping out the symbols such that they can be slurped in for the user's file compilation

Will:

• minor station keeping on Parrot
• no major progress on cleaning up deprecated stuff
• hope to release a copy of This Week in Parrot
• trying to resurrect that
• lots of questions in IRC about why things are happening
• we don't have a good way to answer that
• will try to post short articles on front page of parrot.org
• hope to do so every Sunday until at least 1.0
• then hope to hand it off to someone else

Patrick:

• moved Rakudo out of the Parrot repository
• its official location is github
• the old Rakudo stuff is still in the Parrot repository
• it'll be gone tomorrow
• decided on Git because there weren't many pros for sticking with Subversion
• getting everyone up to speed on using Git isn't super easy
• haven't run into any major blockers yet either
• usually just reorienting ourself to different commands
• hacked up a new Configure.pl for Rakudo out of the Parrot tree
• making it work with an installed Parrot
• Parrot isn't quite there yet
• if someone doesn't have Parrot but downloads Rakudo, what's the best way to get them an appropriate revision of Parrot to run on?
• looking at options for that
• very pleased to see Larry's changes to metaops and other pieces
• pleased that Prelude is now Setting
• equally pleased that I haven't worked on any of these pieces yet....
• hooray for delayed binding

c:

• Alan Kay is smiling somewhere

Patrick:

• late binding wins again!
• laziness is paying off
• Rakudo is close to having its own Setting written in Perl 6
• part of the repository
• probably won't happen by Frozen Perl this weekend
• have some documentation to write for that
• should have it by the next Rakudo release, sometime in February

c:

• finishing the draft Parrot support policy
• pretty aggressive, but what we discussed at PDS
• will be in the repository today

Nicholas:

• what's the schedule on Rakudo releases?

Patrick:

• I expect that they'll occur timed with Parrot releases
• but not simultaneous
• Parrot releases on the third Tuesday
• Rakudo will release the weekend after that
• this'll give us time to tie it to that specific release
• we'll continue the monthly release cycle
• for most of 2009, I expect many people won't want to play with the released version of Rakudo
• they'll want to play with the head version
• all of the cool features and bugfixes
• it'll track Parrot, but not necessarily Parrot's head
• it'll make sure you have a sufficient version of Parrot, but not necessarily the latest one
• January has shown that when Rakudo and Parrot are separated, changes to Parrot trunk can easily break Rakudo
• we update a file in the repository now
• we'll update that whenever something happens in Parrot that we need to update it with
• that version will always include at least a Parrot monthly release

Nicholas:

• Parrot's starting to get to the point of Perl 5
• changes can break CPAN modules

c:

• we need to be more aggressive about adding those tests to the core test suite

Sorry for not writing for so long. This time I've been burying myself not just in code, but also in conference preparation, travel and attendance. Anyway, I'm going to try and catch up a little bit here - more detailed posts about individual features to follow.

First, I'd like to thank Vienna.pm. After funding a great deal of my Rakudo hacking last year, they have kindly agreed to continue the arrangement into this year, which is funding me a day a week. I expect that due to attending workshops there will be some weeks I miss and others that I will do two days, but it should come out to a day a week on average. So, a big thanks to Vienna.pm! I plan to use some of the initial days to go through RT and try to cut down the number of tickets there, most of which are bug reports. It will be a nice complement to my Hague Grant, which is mostly focused on feature development (though implementing those has of course been closing existing tickets, and I've been doing other bits on RT tickets too - but having time I can dedicate to fixes and improving the quality of Rakudo in a wider sense is great).

I am writing this from Sophia in Bulgaria, where I've been attending the first Bulgarian Perl Workshop. It's been a wonderful time for many reasons - not least because of the hospitality of the Bulgarians I have met during my time here. Marian has been especially wonderful, taking me out the day after the conference to see the beautiful mountains and a stunning monastery. I enjoyed speaking too - the room was full and there were lots of good questions, which always makes it much more fun and helps me feel that people are getting it. So, to all who organized the conference and to all those I met and talked with - thanks for making this a great time.

My Hague Grant is going well. In the world of parametric roles, I've done a range of enhancements to make sure you can use type parameters as types in the places you'd expect, and written more tests, plus have done some minor fixes that were needed to let us have roles parameterized on parameterized roles, so you will be able to build nested typed data structures. I also implemented the "of" keyword, and made roles pun to classes if you tried to instantiate them. This actually puts me well ahead of schedule so far as parametric roles go. My remaining work for during February mostly consists of using it to make typed arrays and hashes work. I plan to implement these directly in Perl 6 so far as I can, with some bits of inline PIR here and there. They won't be usable until we have the Perl 6 prelude, but that is high on pmichaud++'s schedule to work on too, so I hope we'll have that before February is out.

The other big-ticket item I've now done is junction auto-threading. For now, we still have the custom code in place to thread operators, and auto-threading for built-in functions and methods does not yet work, but again once we get the Perl 6 prelude in place they will also Just Work based upon what I've already done and the custom code can go away. I've done various tests to make sure auto-threading with multis works out nicely, that we auto-thread over the invocant during method calls (to methods not defined in Junction). I will write a more detailed post on junction auto-threading shortly.

I've done a few other bits, too. The handles trait verb will now accept pairs, a class or role name, a regex or the Whatever *. (In fact, the rule is that it's just a smartmatch with the method name as the topic, so regex and * fall out of the same code, and I'm sure folks will come up with other delightful things to write there). I am missing the s/// variant, since we don't parse that yet in Rakudo and I'm not quite sure yet how to do it. But otherwise, that's the handles work about done too, I think.

I also did some improvements to let us write nested classes, though there's some way to go on that. Further, declaring a proto makes all subs of the same name not marked multi be multis, and this works for upgrading methods to multi-methods too when composing roles if there is a proto in the class (in fact, composing roles that had multis in them before didn't work properly, since a Parrot addition was needed; I did that as part of this work, and added Parrot tests for it as well as then doing the Rakudo bits on top). Finally, I've added redeclaration of types detection at compile time, plus a better error if you try do inherit from a non-existent class or do a non-existent role.

So, quite a list of things that have got done, which is nice. :-) And lightens the load a bit for me in February, so I'm optimistic that I am going to be able to complete my Hague grant on schedule. Well, hopefully I didn't just jinx it...

The Perl 6 design team met by phone on 28 January 2009. Larry, Allison, Patrick, Will, Jerry, and chromatic attended.

Larry:

• still working through various operator questions
• thinking about a better model for preventing unfortunate backtrackings
• current commit model is too simple-minded
• otherwise thinking about various questions people are asking me
• they're on the backburner, mulling in my subconscious
• heading up to Seattle this next week

Allison:

• cleaned up library loading
• generated Debian packages
• trying to get Parrot 1.0 into Debian
• working on documentation, especially make html
• decided to try a POD parser in Parrot
• in PGE, a full POD parser takes about four hours
• wrote the PCT AST nodes, but didn't write the action rules
• seems like kjs took a stab at those
• merged in half of the STRING refactors
• resolved a handful of tickets last night

Will:

• finished the release manager document through May
• ripping out a lot of deprecated items again
• seems like our list gets longer every release
• we really need to make a push to rip it out in February
• working on Tcl, on and off
• all of the details are on the partcl blog

Patrick:

• mostly making plans to move Rakudo to its new repository
• should have that all decided in the next few hours
• will make that happen, so that Parrot will make its move tomorrow with no trouble
• suspect that we'll work on that over the next couple of days
• responding to some questions
• have a new laptop, which is 33% faster at building Parrot than my desktop
• getting ready for Frozen Perl next week

Jerry:

• added portable NaN/Inf support to Parrot and Rakudo
• the 60 or so spectests which failed on non-Linux platforms now pass
• all tests pass for Parrot and Rakudo on Windows
• working a little on the infrastructure
• trying to get e-mail to Trac installed
• opened 14 tickets yesterday
• challenging others to join in on closing them
• S19 could use Larry's review

c:

• working on the support, release, and deprecation policies
• will submit that draft for review this afternoon
• have a couple of bugs to fix
• will close as many tickets as possible

Jerry:

• the Open Group's C99 model suggests inf or INF
• should we follow that or the dynamic language model of Inf?

Larry:

• I like the latter

Patrick:

• the Open Group says when you parse a string, it's case insensitive
• when you produce a string, it's all uppercase or lowercase

Larry:

• Perl 6 doesn't care what other standards groups say

Patrick:

• if we stringify infinity, we get Inf
• if we numify inf, do we get zero or infinity?

Larry:

• infinity

The Perl 6 design team met by phone on 21 January 2009. Larry, Patrick, Allison, Jerry, Nicholas, and chromatic attended.

Larry:

• working at the list of observations posted to p6l
• operators, precedence, associativity
• looking at rationalizing changes between the spec and STD.pm
• discovered a big bug in the latter
• it assumed that the lack of associativity indicated a unary function
• that doesn't jibe with the spec
• I tried adding associativity and it blew up spectacularly
• lots of red, green, and white
• I'm sure that's somebody's flag
• thinking about various requests for clarification
• still very busy at work and home

Patrick:

• had a lot of stuff going on this weekend
• not a lot to report
• mostly working on planning for moving Rakudo out of the repository
• where we'll move it to
• talking about the various aspects of that move
• I expect we'll make something happen by next Monday
• that'll free Parrot to do its move whenever it wants
• we'll keep the version of Parrot that we want in the Rakudo repository
• that's not a long-term answer
• we'll expect to run against an installed Parrot in the future

Allison:

• including it might be tough, copyright-wise
• can you include instructions for downloading it like the spectests?

Patrick:

• I don't want to complicate things by requiring a different VCS
• or figuring out what kind of downloader people have
• we'll point people to the real Parrot repository to work on that
• I don't think the monthly releases will be up to date enough
• we've had a lot of cases recently where Parrot changes have broken Rakudo briefly
• biggest challenge is deciding what to do with the spectests
• there've been a variety of discussions about that

Jerry:

• mostly disconnected from the net this past week, visiting family
• have some work squirreled away on my laptop
• made some S19 progress in defining the command-line parsing library
• have a rough outline and some pseudocode
• hopefully will commit that this week
• can move on from there

Allison:

• finished the patch review for installation
• applied the make install-related code
• made a few additional changes to get it working
• now it's mostly working
• there a couple of issues in library priority that still need changes
• gave a talk at UC Davis the other night
• otherwise trying to stay on top of the mailing list
• starting a couple of cleanups I didn't want to do before the release
• string and file sanity
• the change to get rid of extensionless library loading

c:

• released 0.9.0 yesterday
• someone's going to have to clean up a lot of bugs
• fear that's probably going to be me

Patrick:

• Larry, I really appreciate the changes to the standard grammar in the past week
• they look good
• they make my life easier

Larry:

• I'm still vaguely interested in simplifying things
• added a warning on using a for loop

Patrick:

• we'll get something like that in Rakudo too
• it'll be a common brain-o

The Perl 6 design team met by phone on 14 January 2009. Larry, Allison, Patrick, Will, Jerry, Jesse, Richard, and Nicholas attended.

Allison:

• spent the week working on pumpking stuff again
• merged in several branches that I and others had been working on
• did a lot of patch review
• planning on doing the migration to parrot.org today
• I'd said today because we had three days where we could figure it out; what works, and what doesn't, and delay it if necessary

Larry:

• been doing spec work, and answering questions
• things are hectic at work right now, so I don't have a lot of time for my true vocation
• keeping my nose above water on the mailing lists and IRC channels
• removed the old .contains method, that was standing in for the .exists modifier on hash lookups in a hash.
• mostly answering questions and hoping that someone else will clarify the specs for me, when I answer questions about functions and pod.
• trying to use my spec writing time for clarifying things that other people can't do themselves
• I have trips planned in April

Patrick:

• worked on getting the branch merged in that refactored variable handling in Rakudo
• got it done on Friday. It worked out well.
• ... though not for people who were relying on misfeatures of Rakudo
• I've been helping people by pointing out ways to fix it
• it's a stronger basis from which to continue
• passing 60 more tests than this time last week. 6233 now passing.
• we lost 30 when we merged the branch, but gained 90 back, so a net plus for the week
• I've closed a bunch of tickets, or put a note on that we can close when we have a test
• done over over 2 dozen. Still more that could be closed like that.
• it just takes time to find them. It feels good closing tickets that way.
• I've also been helping others
• I was going to read PGE refactors, but now figuring out what to do with Rakudo repository is a higher priority

Allison:

• it doesn't matter if Rakudo's repository moves, just that it's not in the same repository as Parrot.

Patrick:

• I'd rather not move it and then move it straight back.
• there have also been some discussions about moving Rakudo to git
• I don't want to go to the community and say "Oh, this week it's here" and then the next week "Oh this week's it here", and have the documentation on where to get Rakudo be constantly out of date

Allison:

• let's get you cc'd on the list discussion with the admins

Patrick:

• we will now be figuring out a Rakudo plan for this so that we can notify the Rakudo community about the changes coming up

Will:

• I have one task assigned for Parrot this week -- rip out all the deprecated items. There are about half a dozen left; a depressing number.
• trying to get volunteers to look through and remove what is just a hack and slash

Nicholas:

• nothing to report

Richard:

• I had dropped out of the calls about mid way last year because I didn't feel that I had anything to contribute
• before I dropped out around June 2008, we did a huge amount of TPF work on how it would improve things until I had things to say
• then I backed off, at least partly because in July 2008 my wife had a baby
• in the past month or so, I'm coming back on the radar
• we have a 5.10.1 release grant going on right now
• Dave working on it, Nick the grant manager

Nicholas:

• I watch him commit things. I don't know more more detail than that, as I've not communicated with him recently.

Richard:

• even an revised expected release date would be good
• when I was talking with him setting it up it was "late Jan, early Feb"
• would be good to know if there is updated information
• Also Hague grants. A lot of good things are happening about that.
• I took a trip last month to New York to see Ian, to say thanks, and give him an update. It was an excellent meeting. He is happy with the progress going on, feels respected as a donor, and is happy with the amount and level of communication.
• I'm looking into the legal details of splitting apart what is Parrot and Rakudo. Drawing up the assignment agreement with Roberta (the TPF lawyer)
• TPF got a nice donation from booking.com ($50,000) booking.com asked TPF to be vocal. Tell the world.
• they did not put a specific requirement on the donation. They said "we hope to support Perl 5.10 with this", but not the level of surety on it that I had with Ian on his donation.
• I'm sure that some 5.10 support will come out of that, but after that we have a general donation to work with. Could well be part of the grants through the grants committee. There is a growing desire for funding there. Even a couple of quarters there would not exhaust it, so we will figure out other good ideas for what to do with it.

Jesse:

• as mentioned last week, it's time for me to step back as project manager type person. Do we want a replacement project manager, or is it more a community organiser type person?

Patrick:

• all I did was write code last week, so I didn't have time to think

Jesse:

• we can't be having that!

Allison:

• I think we're okay without a project manager

Jesse:

• as long as everyone is okay with that, I'm happy not to foist someone else upon you
• I will update the world on my blog next week. It's likely to get flameage just because it contains the term "Perl 6".

Allison:

• "Oh no! Perl 6 is dead. It doesn't have a project manager!"

Jesse:

• I wonder if I can get to Reddit number one on that

Richard:

• maybe "The Perl 6 implementation efforts are so strong right now they're basically self managing to good effect."

Jesse:

• I might pop by the call in the future to see how you are

Larry:

• it would feel much better if you went out with a major rant

Richard:

• it is traditional

Jesse:

• it should be "career limiting"

Patrick:

• rant that the implementations are doing so well without your input

Allison:

• and "I'm just not useful any more"

Patrick:

• and rant how you've tried to kill it but it's [just too strong to die]

Jesse:

• I've enjoyed this. It's been fun and interesting, and I hope it's been helpful. At times it's been maddening, but that's true of any project.

Allison:

• thanks for everything that you have done

Jesse:

• thank you for actually making it happen

Missing a discussion on .trim and gilding the lily.

Nicholas:

• if I wanted PHP I know where to find it

Patrick:

• wasn't aware that .trim is not a Perl 5 built in

Larry:

• PHP has 3000+ functions, so we have a way to go yet
• seeking to strike the right balance

Larry:

• my question for the day "To what extent do unary hyperoperators descend into containers?" I think that they do, to some degree.
• also the exact definition of what .perl means.
• been doing a lot of thinking on that

Patrick:

• that's a good question to be thinking about, from a Rakudo implementor's position

Larry:

• that's why I might appear to be ignoring mailing lists

Patrick:

• can I .perl a sub?

Larry:

• you won't get the exact the same object back

Patrick:

• but a representation that compiles to the same sub?

Larry:

• I think it would be good if we could
• but at some point a lot of businesses are going to say "Oh, you just made it very easy to reverse engineer my sacred code".
• I don't think we can guarantee it, but whether it's strongly encouraged, but turn offable, or similar
• at least the types of code that are idempotent, or otherwise stateless such that they can be easily reconstituted
• in some ways we already have to be able to do that to save the state of the current language, as we have to save the current grammar and all the methods on it, to do prelude snapshots, or do an eval, without having to rebuild all from scratch
• I don't know where the balance point on that is

Patrick:

• sounds good. Aiming at the point I'm thinking of.

Larry:

• need to think about it
• do what's reasonable. not do doing something that will set the whole project back a whole year

Patrick:

• I mailed the list about pairs. Didn't spot a reply.
• if I iterate over a list of pairs, are the values of those pairs...?

Larry:

• those are references back to the original
• likewise pairs coming out of a hash should be references

Patrick:

• by "References" you meant the values, as the keys are immutable?

Larry:

• yes

Will:

• Tcl question
• for Parrot, I was going to have an attribute to save the high level source. It was going to return the text of the sub and let the user recompile it
• this is sane?

Patrick:

• I had that as a fallback, but wasn't what I really wanted to do

Larry:

• it's a good degenerate solution as a minimal solution that can serve as a backstop

Patrick:

• but that would mean that my PBC files would have the entire source code in them
• hence my question about .perl and subs was "Do we have to do that?"

Will:

• there's another language out there that needs to do that
• we could share infrastructure

Larry:

• you run into the Deparse problem
• what you see is after the optimiser got at the code
• it might be what you want, but it's not the original source

Jerry:

• is it possible that the spec could say that? The default is a sane default?

Patrick:

• you're forgetting that one of the Perl 6 mottoes is that it exists to torture implementation on behalf of the users

Larry:

• not so much that it never happens

Patrick:

• who defines that? I might have quit back in 2004.

Larry:

• with a rant preferably. :-)

Jerry:

• I've finished most of the technical details of S19. It needs a re-write. It doesn't read well.
• as far as a working copy goes (from my perspective, as the implementor) it's in a good place
• there may be some ambiguities, but I've moved onto the implementation
• next deliverable is a set of spec tests
• to implement them properly I'm building a test harness, so I'm coding before I can write the tests
• eager parsing, eager meaning .*?, as opposed to greedy, which would be .* behavior
• no one likes the terminology "eager"
• pulled it from S19
• didn't want to define something as non-greedy
• found "eager" in S5.

Larry:

• especially as in the rest of the language "eager" means "greedy"
• "frugal"?
• "parsimonious"?

Patrick:

• that was the term Mastering Regular Expressions uses
• lazy would be bad also
• yes, it's called Lazy

Larry:

• probably okay. Eager : Lazy :: Greedy : Parsimonious.
• that is how the rest of the language treats lists. "Eager" vs "Lazy".

Patrick:

• in the context of regular expressions, we'd call that ? qualifier lazy
• the association doesn't immediately come to me

Larry:

• it can be implemented with lazy lists. That's how Cursor.pm works.

Jerry:

• will take a stab at changing POD

Patrick:

• I'm going to be in S5, so I could

Larry:

• if Jeff Friedl uses that term too, that's good

Jerry:

• noticed that Larry weighed in on some issue relating to preludes that I'd mentioned in S19, so it looks like that part has been approved

Larry:

• well, I suggested it in the first place.
• I don't know if it makes *sense*. :-)
• maybe an alternate prelude doesn't make sense
• I don't think of preludes as actually preludes -- instead they're the surrounding lexical scope

Patrick:

• really we're waiting on the implementation so that we can see how it works in practice

Larry:

• I'm thinking of the same way an eval works
• the outer language is serving as a prelude for that eval
• it's the same thing, except that the current language can be frozen into the file, and then you're effectively starting up again from there

Patrick:

• it's layers, all the way down

Larry:

• well, all the way up

Patrick:

• the core compiler does an eval of the prelude, which brings a bunch of things into scope, which then does an eval of your code

Larry:

• it's more the parse of the eval. We use this to implement -n and -p
• it's not eval in the sense of recompiling each time through the loop.
• it's that eval does a sub-parse. That's what needs to be generalised
• Make good use of the ability to wrap compilations in one or more outer contexts. Whether we call it, prelude, or outer-lude
• what's the opposite of an interlude?

Jerry:

• environment variables also
• I considered a switch which let you set an environment variable
• this would let you do it on the same line for shells that don't provide such behavior

Larry:

• rn had one of those

Jerry:

• same as adding it in the prelude

Larry:

• except that environment variables are scoped dynamically
• another question about environment variables, which are essentially global
• can a dynamic scope override them?
• how easily within perl 6 code, just for that dynamic scope
• we speculated about connections between contextual variables and environment variables, or the globals

Jerry:

• I was under the impression that something was decided, and then changed

Larry:

• we can give that appearance :-)

Jesse:

• thank you everyone for the last few years. Enjoy your call next week.