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