A number of useful conclusions and targets came from the Q2 2011 Parrot Developers Summit that happened yesterday. This post will contain a summary of the event and my take on what we'll be doing as a result. Props go out to kid51 for organizing an agenda for the meeting and keeping us more-or-less in line. Strict organization isn't vital for an irc meeting, but he did good job of making sure that our limited time was used effectively.
We started out reviewing the state of our previous roadmap goals.
The Deprecations-as-Data goal was substantially met. I love this goal because it has potential to make life easier for our users (especially Rakudo) by expressly delineating what features are going to need upgrading. A recent issue with nci and the 't' type demonstrates that we still have more room for improvement. (pmichaud and whiteknight discussed a proposed solution after the meeting, but it needs a little experimentation first.) My hope for data-based deprecations is that we end up with a better early warning system that alerts Parrot's users and gets discussions started before things break horribly. pmichaud's concern was that that the web tends toward passivity and that what's needed is active notification of pending and actual removals. I think this will be a boon.
whiteknight's IMCC Isolation goal is making excellent progress. pmichaud commented that it's had no negative impact on Rakudo's development, which is impressive given its scope and invasiveness. IMCC isn't yet an optional component, but it's quite possible to run libparrot without initializing IMCC at all. Excising it completely is quickly becoming a possibility. whiteknight has been doing a bang-up job and isn't showing any signs of slowing down.
The third goal is one that dukeleto and I have been working on, of getting M0 prototyped. dukeleto's working on the assembler and I've got the interpreter, both being written in Perl 5 with the binary M0 format (".m0b") being the only interaction between them. The punchline is that the interpreter is fully-implemented with stubs for all ops and the assembler is a couple weeks from being usable, depending on duke's tuits. On the one hand I'm a little disappointed that we don't have a fully usable prototype, but it is what it is. Even once both prototypes are "complete", there are several questions we need to get together with allison and/or chromatic to answer. Our M0 plan is to get the prototypes as complete as we know how and to have another meeting where we get all our questions answers, possibly even hacking the last few needed bits into the prototypes as we meet.
Once we moved away from the retrospective, pmichaud quickly asked what Parrot's plans were concerning Rakudo. He specifically asked if Rakudo should consider itself officially blessed in developing against master rather than a release (we said "yes"), and if we planned to use Rakudo for regular benchmarking. This second concern is especially important because Rakudo has seen some significant performance regressions in the last couple months, in spite of the introduction of the new generational mark & sweep GC. The expectation is that regular performance testing would have brought this to light sooner and that once it's in place, we'll be more conscious of how our changes affect Rakudo's performance. We've had a distinct lack of benchmarking in the last few months. I hope this is the first of many attempts to revitalize our efforts to improve performance.
On the same note, Codespeed (which runs speed.pypy.org) was mentioned as a possibility. I remember mentioning this in the past without effect, but hopefully the time was right at PDS. We didn't formally ask for someone to investigate it though. I hope it doesn't get dropped on the floor again.
The next PDS was scheduled for July 30th or 31st, which seems comfortably far away from any known conferences. whiteknight volunteered to set up a Doodle, which is proving to be a very handy tool for scheduling these things.
The next topic to come up with profiling. While working on Rakudo, pmichaud hacked out very quick and dirty sub-level profiler that immediately pointed out an important hotspot. This indicated to me that we need to up the game of the profiling tools that we provide as part of Parrot. whiteknight and I were on the same page, so one of our new roadmap goals is to dig into the current profiling runcore, find out what's keeping it from being useful and fix it. It currently depends on IMCC to get its information about the currently running code, so there's potential for much yak-shaving. On paper the goal is only to investigate. I hope we can get much more done. I love providing useful tools to people, so I'm glad to have a chance to redeem the profiling runcore. Unfortunately having whiteknight work on profiling will mean that he won't be spending as much time figuring out how to apply 6model to Parrot, but that's what it means to have priorities.
A third concern was raised by pmichaud, who said that it's difficult to gauge what Parrot's leadership thinks about certain issues. One of the triggers in this case was my rather foolish removal of the intiailization of Parrot's PRNG (pseudo-random number generation) using the system clock. At the time Peter Lobsinger made the reasonable-sounding argument that there's no single way to correctly do PRNG that will satisfy the needs of every possible use case. After too little thought, I decided to interpret that as meaning that it didn't matter that I'd changed Parrot's PRNG behavior because Rakudo should be doing what makes sense for them. This ended up being a bad idea that caused some pain for Rakudo, and while I eventually reinstated PRNG intialization from the system clock and later from the system entropy pool, it showed the need for a better-delineated interface to gather option from Parrot's developers as a whole. To this end, whiteknight and I will serve as a sort of ombudsmen for when technical decisions end up harming users and need to be appealed. I don't think we'll need to put on our ombusdmen hats often, but we'll be glad to have them when we do.
Breaks in compatibility are inevitable, but what whiteknight and I hope to achieve as ombudsmen is to make sure that users have a respectful ear and will get fair consideration for their problems. A disconnect between the needs of our users and our goals is very unhealthy and can only harm both parties.
Overall, it felt like a very productive and well-organized discussion. pmichaud did a great job of representing Rakudo's concerns and I think that the coming months will see several improvements in Parrot's process and tools to make it a better plaform for Rakudo to build on.