Virtual Developer Summit - Sunday, April 11th 2010

Jonathan Worthington jonathan at jnthn.net
Sat Apr 10 01:49:15 UTC 2010


Allison Randal wrote:
> In keeping with the tradition established (in one previous supported 
> release), we're holding a virtual developer summit on #parrot 
> (irc.parrot.org) Sunday, April 11th at:
>
> 7:30pm UTC
> 8:30pm UK
> 3:30pm US Eastern
> 12:30pm US Pacific
>
> We'll be talking about the long-term roadmap (mainly 2.6 and 3.0), 
> development priorities, as well as a checkin our current development 
> procedures. We'll plan for about 2 hours, with the earlier time spent 
> on roadmap items, and the remainder on general discussion.
>
> I you have questions or comments but can't make it to the virtual 
> summit (it is rather short notice), please pass them along to someone 
> who plans to be there.
>
On Sunday I'm flying to Russia to give some Perl 6 talks; it'll be 
11:30pm there and I have a talk the following morning, and that combined 
with the travel means I probably can't make this. :-( Here's some quick 
input from the Rakudo side of things.

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.

* 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. :-(

* 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.

* 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...

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

Looking beyond Rakudo *...

* The NFG strings GSOC proposal being accepted and completed would be 
wonderful.

* 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.

* 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.

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.

Thanks,

Jonathan



More information about the parrot-dev mailing list