The Perl 6 design team met by phone on 10 February 2010. Larry, Patrick, Will, Jerry, and chromatic attended.
Will:
- working on simplifying Parrot's build process
- trying to remove an invocation of Perl 5 for every compilation
- it's old and a waste of many things
- hope to have that removed by the end of the week
Jerry:
- the new #ps time should help me to attend
- looking forward to a Parrot/Rakudo workshop, possibly at YAPC::NA
- already working on artwork
- would like to get the command-line done for Rakudo *
- lacking tuits
- need some time with Patrick over the next few days
- weekends should free up after next week
Larry:
- refined the specified semantics of bitwise operators
- changed ugly
**() special form to prefix:<||> by analogy to prefix:<|>, and relationship of ** to *.
- STD now accepts prefix
|| for slice interpolation
- deleted old p5=> that masak++ noticed
- added explicit copyright notices to STD files
- spruced up error message on -> in postfix position (either pointy block or Perl 5 method dereference)
- mostly just served as Chief Resident Oracle on IRC
Patrick:
- had a nice vacation in Florida
- didn't have as much hacking time, due to plane delays
- should get back to coding later today
- working on the Rakudo hackathon in Copenhagen on March 6 and 7
- core hackers session on 8th and 9th there
- looking forward to that
c:
- fixed a couple of bugs
- did a bit of optimization
- wrote out a GC optimization plan
- wrote plan for a sweep free GC
- think we can get those both going in the next week
Jerry:
- noticing a lot of new branches and removals and new things in Parrot recently
- are these following the roadmap?
- are people going off on their own?
Will:
- the deprecation stuff is all documented and seems reasonable
- Andrew's discussion today is new stuff, but a reasonable discussion to have
- I'm working on cleanup stuff
- having a roadmap and trying to force people to stick to it is always... impossible
- people will work on what they find shiny or what blocks them
- if it's not on the roadmap, it's okay if it's not hurting the project
Jerry:
- we've changed our deprecation cycle
- was that change enough to unstick people to do something?
- was it beneficial to our users and our core developers?
Will:
Jerry:
- still not a lot of mailing list discussion
- how is Parrot meeting Rakudo's goals for the Rakudo * release?
Patrick:
- as it stands today, it's adequate for what we need
- if it weren't, you'd be hearing about it
- the next thing for us is performance
- any performance improvements are welcome
- the biggest thing there is GC, and that's an area of focus
- no big pushes I need to make lately
- have noticed Andrew's desire to remove some Parrot features
- they're useful from an HLL perspective
- I do worry about changes to core Parrot divorced from HLL concerns
- I don't know who's going to be the traffic cop for those changes
- I don't have time to do it
Will:
- based on the discussion in channel today
- making Parrot leaner, faster, smaller may not necessarily jive with keeping the features as they exist now
- he's not trying to remove features
- he's trying to get the same effect with a faster Parrot
Patrick:
- I agree with those motives
Will:
- even if we do rewrite things, they have to work more or less as they do right now
Patrick:
- reviewing the roadmap from December....
- GC work is happening
- no one seems to work on subroutine leave semantics
- Stephen Weeks is the best one to look at that
- performance is our biggest need right now
- but the -ng branch performs better for various reasons
- has anyone built -ng against the latest Parrot?
Will:
- I think Vasily has checked his branches against Rakudo
- not sure if that was against -ng
Patrick:
- master and -ng are pretty close together in terms of the Parrot core
- we'll make -ng the master branch very soon
- unless I get bogged down on iterators again
