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
screen.
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.)
