develooper Front page | perl.perl6.internals | Postings from October 2002

Parrot 0.0.9

Thread Next
Steve Fink
October 23, 2002 09:27
Parrot 0.0.9
Message ID:
I suppose I ought to try to wrap up a release one of these days. I've
been thinking about the possibilities, but I'm not sure about the
current state of a couple of things. And what I'd most like to see
right now is some stabilization. So I'll list my current thinking:

Prerequisites for 0.0.9 release
* Reclaim the tinderbox!
  - requires the multiarray.pmc memory allocation problem to be fixed
    (Josef is looking into this)
  - requires sprintf* to work on PPC. (Brent -- what's the status?)
* Warnings reduction
  - I doubt we can make it to zero warnings for all platforms, but we
    really need to at least get things like gcc3 on the sparc down to
    a reasonable state
* JIT trace/restart() failure
  - Leo's analysis of the situation is correct.
  - If nobody beats me to it, I'll probably work on this the next time
    I get a chance to do actual coding.
* Patch backlog
  - Artificial goal: I want the list of pending patches to be smaller
    than one screenfull before I release. Fortunately, I have a large

Possible (feature/architectural) goals for 0.0.9
* PMC cleanup
  - Leo did a huge amount of work on this, but there are a few things left:
  - array.pmc still autocreates something called "PerlUndef"
  - the various unions should probably be coalesced into one
  - I think the variable/value distinction Dan was talking about may
    require some changes, but I haven't been paying attention to that
    discussion (as in, I read it, but not closely enough to understand
    what anybody's talking about yet)

* PMC method invocations (written in C)
  - This is just something I think we really really need in order to
    build on top of, but I don't know the current state here either.
  - I say "(written in C)" because eventually we want to be able to
    write PMC methods in Parrot (and have them JITted etc.), but
    that's further off

* Keyed access
  - Another discussion that's gone over my head. Leo has a scheme to
    dramatically reduce the number of instructions, at the cost of
    requiring a couple of opcodes for keyed accesses; Dan says that
    lots of instructions are no big deal and pushing forward with the
    status quo is better.
  - Either way, the current keyed support isn't complete.

* Bytecode format
  - We need lots of bits of metadata:
    - Source filenames/line numbers
    - Debugging information
    - Stratospheric rehydrocalibration amplifiers for the .NET people
      (er... or something; I can't remember what they needed)
    - A couple of other things I had written down in a notebook I left
      at work
  - Juergen Boemmels, the guy who gets his name constantly mangled by
    us 7-bit ASCII throwbacks, has a good start on the underlying
    support for this. Leo liked it, so it must be good.
  - I still don't understand why we can't write our own
    serializers/deserializers for ELF or some other standard format,
    and will periodically keep whining about it until someone explains
    it to me in a way I can understand. (I'm still quite happy to have
    the current packfile format extended in the meantime, though it
    would be very nice if the assembler could follow IMCC's lead and
    use the packfile.c API.)

* Exceptions
  - I haven't been paying much attention to developments on this,
    although I know Brent went through and cleaned up a bunch of stuff
    so that at least exceptions will be thrown when they should be.
  - Dan was also working on some of that design stuff he does. Is this
    close enough to reality to squeeze into this release?

That's all I can think of for now. Please, if you know more about the
state of any of these things, can you reply with an update? I plan to
make a release as soon as we can finish any one of these five feature
goal ideas. (Unless something else is close enough to completion, in
which case I'll hold off for that.)

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About