Virtual Developer Summit - Sunday, April 11th 2010

[Allison Randal]

On 4/10/10 2:49 AM, Jonathan Worthington wrote:
> Allison Randal wrote:
>> In keeping with the tradition established (in one previous supported
>> release), we're holding a virtual developer summit...

The summit was a great success! Thanks to all who participated, both in 
advance and on the day. chromatic volunteered to write a general 
summary, but I'll go ahead and respond to the advance posts. You can 
find the full IRC archives at:

http://irclog.perlgeek.de/parrot/2010-04-11#i_2218733

> Things Leading up to Rakudo *:
>
> * Memory usage has improved dramatically of late - thanks for that. It's
> still highish, but at least just high and not insane.

There was a great deal of enthusiasm about this progress.

> * We really, really need the error reporting (line numbers etc) stuff
> sorting out. The PIR line numbers are often somewhat off. On the
> annotations, I did actually have it working well at some point, but it
> seems things have regressed. :-( I also went to some effort to make sure
> we always ran t\op\annotate.t as a "special case" on a normal "make
> test" in that we also compiled it to a PBC and ran it - because it
> matters. While the way I did it maybe wasn't the neatest - I got such
> comments at the time and said improvements were welcome - the right
> answer was NOT to just rip out what I'd set up. Now it appears that it
> fails a couple of the tests when you pre-compile it to PBC. :-(

This is being actively worked on now (it's one of the development 
priorities for this week). The biggest hitch mentioned in the meeting 
was the testing framework, with several suggestions for how to proceed.

We really need a broader solution for running all our PIR tests as 
precompiled PBC tests (and also for running them against an installed 
Parrot), but for now, just getting regression tests in place for these 
failures is good progress.

Could you elaborate on any error reporting failures beyond line numbers?

> * Getting block exit handlers in place would also be good - I'm not too
> up on exactly what's needed, but I think others may well be. If they're
> there shortly, we can probably make decent use of that in Rakudo * to
> get temp variables in place. I can probably work out and help on the
> details of what's needed if there's somebody willing to work on this.

This is a feature needed by multiple languages, but as a start we need 
to work out in more detail what Rakudo needs and make sure that subset 
works. Parrot already has handler semantics for events, exceptions, etc, 
so this is an extension, rather than a wholly new feature.

There's an active branch for this work, waiting for more details on the 
needed functionality.

> * I'm probably about to run into some issues on lexical bits and
> BEGIN/INIT time, but maybe for now I can just use the HLL mapping to
> have some custom solution there for Rakudo, and Parrot can borrow back
> the model if it likes (I believe Pm and Allison have discussed the
> "proto-lexpad" approach before now and it may be desirable for Parrot
> overall, but for now it may well fall foul of the deprecation cycle even
> if I were to JFDI). Will flag up anything I run into, anyway...

Refactors to lexicals are definitely on the radar. Patrick and I have 
talked about them, though the "proto-lexpad" description isn't familiar. 
I don't know if it's a later name added to the same concept, or a 
further development in the concept.

Basically, we need to sit down with the Rakudo team and gather the 
details of what you need, and make it happen.

> * Generally, all performance and memory consumption improvements will be
> most welcome.

Also several good ideas for making further progress here.

> Looking beyond Rakudo *...
>
> * The NFG strings GSOC proposal being accepted and completed would be
> wonderful.

The proposal looks good, and it's high on the list. The general 
consensus is to wait to see if it's accepted.

> * After Rakudo *, I expect to be looking to get some of the parallelism
> features of Perl 6 in place, and help us move from ideas to concrete
> spec there. I expect to do the initial research and implementation of
> this on a platform that has a mature and stable threading implementation
> rather than Parrot; I doubt Parrot will have that together before I need
> it (though feel free to give me a pleasant surprise :-)). Support for
> parallel programming is an important part of Perl 6, and thus perhaps
> also an important thing for Parrot.

There's a GSoC proposal here, but it's more of an experimental alternate 
approach to parallelism. Again, we hope that makes it in the funded 
list, but it's not likely to immediately address your problems.

Threads do work in Parrot now, but they're limited. We discussed whether 
to tackle GC or concurrency as the next big project task, and decided on 
GC. Partly that's because GC stands to give us substantial performance 
gains, and partly because the biggest problem with Parrot's current 
threads is the fact that the current GC doesn't handle concurrency well.

So, we're looking at substantial GC work starting now, and substantial 
concurrency work in the summer.

What would be useful to have from the Rakudo team is a list of the 
features that you need.

> * I expect that we'll be moving away from using the Parrot Class and
> Object PMCs. Ideally, I want to have some pure-prototype PMC (aka SMOP's
> KnowHOW) and implement ClassHOW and RoleHOW (in NQP) and in terms of that.

Individual languages creating their own PMCs for their object models is 
entirely expected and was part of the original design.

In the meeting we talked (again) about adding a core Prototype PMC with 
semantics for prototype-based languages, as a starting point untile they 
develop their own, and then as either a parent class for their or an 
example of how to integrate

> That immediately brings up the issue of HLL interop. When I first helped
> work on the OO stuff in Parrot, I tried hard to deal with the issue of
> interoperating object systems. Parrot has evolved away from what I had
> envisioned in that area. I initially had seen PMCs and high level
> Objects as two different "universes" that could interoperate through the
> VTABLE API (and you could cheat within a universe), and people could
> follow that pattern to implement other object systems. Minor tweaks
> would just be a subclass of the Class/Object PMC, and anything that
> wasn't one would be generically considered "different" and delegated to.
> PMCProxy inheriting form Class was not my original plan, and doing so
> scuppered what I had in mind. Now I've no idea what the plan is in this
> area, since the focus seems to have instead been on unifying objects and
> PMCs, and I've not seen much thought on things that fall outside of
> those. It's something to have on the radar anyway. I don't have the
> energy to try and provide answers here (nor motivation - I've already
> done this lot once), but I'd be very happy to know what they are.

I can see how you'd read that from the current desire to minimize the 
differences between PIR-level and C-level PMCs, but that change is not 
motivated by blessing "one true" object model.

The plan is still as it has been, for the different languages to 
interoperate via the VTABLE API. That is, as long as the 
class-like/object-like PMCs provide the interfaces to instantiate an 
object when requested from a class (even if the "class" and "object" are 
actually the same variable), to set and fetch attributes on the object, 
to call methods on the object, to introspect into the class 
characteristics from the object (again, even if the "class" and "object" 
are actually the same variable), etc. they will all be able to interact 
without knowing the internal details of each other's object models.

The PMCProxy that you and I prototyped together was a good start in 
allowing C-level PMCs to participate in that larger set of 
interoperability, but not enough. The problems we're trying to solve 
there are specific to that implementation (even more specifically, the 
limitations of C-level PMCs in the first place), not a general problem 
with interoperability.

Allison