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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
