Re: Patches that will come...

On Mon, Aug 23, 2004 at 09:22:07AM +0200, [email protected] wrote:

> > > 1) creating a Ponie::Parrot that allows access to Parrot internals from Ponie:

> > > 2) allows building Ponie PMCs inside Ponie source tree, without putting
> > >    them in parrot/classes

> > > 4) allows calling from Perl to Parrot (only plain subroutines, objects to come)
> >

>   Is the current roadmap somewhere? Are there any plans I should
> know of before re-starting coding?


Sorry about the delay in responding. My time and energy is getting sucked up
by the insides of work code, leaving little for anything perl related.
(eg observe the progress on 5.8.6). The ponie hours bank is building up a
good balance, but I'm not sure when I'll be able to withdraw it. :-(


The roadmap *currently* looks like this draft:

------------------------------------------------------------------------------
1: Data (about 3 months?)

 Dynamic PMCs
 Data structure rearranging into something sane for PMCs (from perl5 layout)
 Full PMC hierarchy

 Refcounting => GC

 Convert arrays,pads,hashes,stashes to something native PMC

2: Magic

 tie
 overload
 other (%ENV, %SIG etc)

3: Simplify ops
   (Perl5 ops have a lot of logic in them. Parrot puts the logic into vtables
    So need to migrate the perl5 logic into the perl5 PMCs)

together 3 months? Might be better to do 3 before 2, except that I think we
need overloading done the parrot way before we can usefully simplify ops.

3: Runloop.
Migrate the runloop from perl5 ops to parrot ops, and therefore to parrot
bytecode.

We think that this actually doesn't need a huge prior knowledge of the perl
core, as it is relatively self contained.

3 months?

So as 3+3+3 == 12, we can get this done in a year.

This gets us to a ponie that can run perl5 as parrot bytecode. Said bytecode
would be generated by perl, probably by a custom B module walking the perl
optree. eval would be messy. Slow, but functional.

What next?

Convert perl parser to emit bytecode directly (or PIR, or Leo's AST stuff)

3 months?

Unify IO with parrot's IO

3 months?

Replace regexps with however perl6 is doing perl5 compatibility regexps.
(What's the plan for how perl5 compatibility regexps are implemented by
perl6?)


I think that these 3 are sufficiently independent that they can be done
in parallel. Until then, I'm not sure how easy it is to parallelise any
tasks.
------------------------------------------------------------------------------


The problem I find is that quite often I start work on the first logical task
and then discover something important that I've missed, or didn't know needed
doing. And because of this it's very difficult to parallelise tasks on the
main line.


The patch you say you have to allow building of dynamic PMCs in place would
be very useful (as it's at the top of the list).

The calling from parrot to perl and back doesn't sit on that roadmap, but I
think is actually useful (and won't rapidly get thrown away, which is always
my fear for the fate of other people's work) because it will make ponie far
more useful for people to start experimenting with parrot, parrot assembler
and other things in parrot. And ponie being useful will lead to interest,
which is never bad :-)

I'm not sure how the array stuff fits in - my problem is that it might
rapidly become irrelevant when the refcounting/GC mess is resolved.

I don't think that parrot has a make install target yet does it? ponie doesn't
have one, because parrot didn't.

What ponie also can't currently do is build on Win32. I don't have access
to any Win32 machine with a compiler, and even if I did I don't have the
knowledge of how Windows development works to get things done correctly,
so unfortunately this is stalled. Steve Hay had a valiant attempt at making
it work, but it got the better of him. [mmm, I'm really good at selling this,
aren't I? :-)]


As I see it the other things that parallelise nicely, won't be wasted effort,
and give quick benefits are actually

a: working on fixing parrot bugs, improving parrot portability and filling out
   the bits of parrot currently missing
b: contributing tests to the Phalanx Project.
   (which ultimately will act as a large acceptance test suite for ponie)
c: Testing ponie with whatever modules you use, particularly XS based modules,
   and particularly modules that aren't on CPAN.


Problem with (c) right now is that it would really help if ponie had an
install target.

Nicholas Clark