Sunday, May 15, 2011

Thoughts on the PDS

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.

Sunday, May 1, 2011

M0ving Forward

dukeleto and I shared a hotel room at LinuxFestNorthwest and had a great opportunity to talk about M0 after our respective talks.  We went over the state of the spec and what the best forward might be.  We also tried to look at what the future M0-based Parrot workflow will look like and how we can get there, though we got distracted before the crystal ball was delivered.

First, dukeleto mentioned that M0 is less discoverable than it needs to be, especially for a project that we expect to become Parrot's new foundation.  He suggested that we write a document that someone can read to get a clear 10,000 foot view of M0 and how its pieces fit together, a glossy brochure of sorts.  This could be either an introductory section in the M0 spec or a separate document.  The important thing is to have something we can point people at so that dukeleto and I aren't the only ones who can readily articulate what M0 is and where M0 is headed.

We also made some updates to the spec to make getting values from the variables table less confusing.  This is fairly minor in the scheme of things, but so is Perl's "say".

Last of all, we hammered out a plan for how get a working M0 prototype assembler and interpreter.

atrodo has been very valuable in providing his prototype Lorito implementation, both in his documentation and in the way he's had to bring assumptions to the surface to get a runnable interpreter.  His implementation differs from the spec in a number of ways (many of which are because it predates the spec), but it's been helpful in those places because it shows us what we want by counterexample.  The next (brief) stage was a set of prototype PIR dynops of M0 I hacked together.  This was great to get some runnable code that was close to the spec, but it very quickly ran into the impedance mismatch between the high level of PIR and the low level of M0.  The effort on the m0 prototype dynops wasn't wasted, but they've reached the limit of their usefulness.

The next step we've decided to take is to implement a separate prototype M0 assembler and interpreter.  dukeleto is be working on the assembler and I'll do the interpreter, both based on the M0 spec in the m0-spec branch on GitHub.  The only interface between the two will be M0's binary representation, so we can easily change one without needing to modify the other.  We're trying to converge on the structure of both the interpreter and assembler, but we expect this to the last prototype rather than a final implementation.   We'll also be writing tests against both the interpreter and assembler which we can later use against any future implementations.

dukeleto has started hacking in the m0-prototype branch in src/m0 and managed to get some very basic tests passing before he went to sleep.  We'll both be using Perl 5.10 as an expedient, since we don't expect these projects to serve as more than prototypes.  As a temporary measure one of us will need to hand-generate a couple simple bytecode files to verify that the assembler is working correctly.  These files will live in t/m0 in the branch.  The test code will be a minimal hello world program and a slightly more complex multi-chunk M0 program to help iron out inter-chunk interaction.  We haven't decided on what the complex example will be yet.  This is a part of the spec we'll need to work on as we come to understand what implementation makes the most sense.

Overall, rooming together at LinuxFestNorthwest has been very helpful in moving M0 forward.  Both of us have used the opportunity to bounce ideas off each other and to get the M0 train out of the station.  We're still a couple stages (and probably one more face-to-face meeting with allison and/or chromatic) away from a final implementation, but we can see the light at the end of the igloo, and it's looking pretty good.

There are a couple things that still need to get done.  In the interest of trying to keep them from getting dropped on the floor, they are:

  • Map out what a future m0 workflow will look like, what we need to do now to make it possible.
  • Make M0's roadmap and status more discoverable by making a glossy brochure that will communicate the idea effectively to someone who hasn't heard of M0 before.