|parrotcode: A plan for Parrot|
|Contents | Project Information|
ROADMAP - A plan for Parrot
As of this writing, there is no one place in which all remaining parrot work is documented. There are various TODO files, the RT queue, comments in the source code and the documentation. This document is a first pass at unifying this information and providing a single point of reference for anyone interested in the current state of the parrot, whether they are developers looking for items to work on, or external users looking for an idea of when they can expect a release.
This document is not meant to contain all the metadata regarding particular tasks, but merely provide a summary of the tasks.
This document is now becoming a roadmap, because the Architect is deep in a weeklong mindmeld with the Pumpking and the results are being encoded in this document, among others.
For a high level overview of parrot milestones, please see: http://www.perlfoundation.org/gc/grants/2005-p6-proposal.html
Parrot 0.4.1 was released on Jan. 8th, 2006. For a list of new and fixed feature see NEWS.
The remaining tasks are broken down into the following categories, roughly listed in the order through which a task might progress.
Each task has certain metadata associated with it which must be tracked. Eventually all metadata should be stored in RT at https://rt.perl.org/rt3/
These are pending design decisions which must be made before any code can be written to implement them. Note - DESIGN is a special kind of documentation task, but due to the nature of this kind of documentation, it deserves to be broken out into its own category.
Any item, whether visible to parrot users or hidden behind an API, that has already been designed (but not implemented) belongs here.
Any items which have been implemented but don't work as expected.
Any items which are specific to a particular platform or require special attention for cross-platform compatibility.
Any items pertaining to source, API, or user level documentation.
Parrot currently ships with several partial language implementations. Any tasks which are specific to those languages, or affect cross-language compatibility will be listed here.
[[What does this item mean, exactly? --Chip]]
The intention was to comb through the various sources of things to be done and collate them in some fashion. At the time of that writing, none of the tasks documented in those directories were documented in a central area. Something a little nicer than grep -r 'XXX', but that would certainly do for a start. See also "BROKEN" in docs --Coke
[NOTE: this does not currently work. Why? --committer]".
PDDs are not exceptions to this rule! Fix them when they're wrong. Delete them when they're obsolete. (Never delete docs lightly, though. Check first with someone who should know.)
http://xrl.us/gvfw (Link to groups-beta.google.com)
Section 1 of that email needs a decision from the Architect.
(Note: Whatever tech we use to implement transcendental math should at *worst* compile to function calls under JIT. And I'll consider making exceptions for the transcendantal math if someone can show me why.)
I expect PIR will still let you pretend they're opcodes, though, to avoid immediate howls of outrage. (But only silicon-based life forms write PASM, so we're not worried about that.)
The key change learns a lesson that Perl 5 only half learned: Lexical values may be dynamic, but their names and scopes are known at compile time. It's just silly to add '$x' to a newly created pad at runtime, over and over and over, every time the same scope is entered. Silly.
So the names and scopes will be static data attached to the subroutine, while the data will be in dynamically created pad entries.
Think of a pseudohash: the static data are like the index hash, which can be shared and immutable; the storage slots are like the rest of the array, which can be mutable even when the index hash isn't.
struct PMC_EXT. PDD04
Ok. In the long run I expect a multi-stage config system. First is to get miniparrot built and running, then Parrot core. Extensions like gdbm could be configured at that point or even in a third step.
[[What's an EDA? --Coke]]
$0, based on recent (January 2005) mailing list activity.
load_bytecodedoes not search the library path to load the file. "core.ops" in ops
cmod. "math.ops" in ops
loop: dec I0 inc I1 # or add, sub, ... if I0, loop
isn't handled correctly on JIT/i386.
Parrot_destroycurrently leaks most of the memory that it is supposed to free. embed.pod
This document should eventually be obsoleted by use of the RT ticketing system, except to the extent that it documents things that show promise but have not yet been committed to. Every task that is actually ready to be done should be documented in RT, and reports generated based on that information.
As for the future development, it has been pointed out that RT is not the best system for handling such things (though it does have the advantage of being available). The main point is to have single point of contact to help volunteers check (and update) the status of issues important to them.