NAME 
ROADMAP - A plan for parrot 1.0 and beyond.
PURPOSE
Describe the work that is remaining to release parrot 1.0, including both user-visibile features and internals.
This document is intended to be a high level overview of remaining areas of work. For more detailed information about remaining tasks, see https://rt.perl.org/rt3.
It also contains information about future direction after 1.0.
LAYOUT
Each task is associated with a major release of parrot. Additionally, each task will refer to its current state, and a link to any documentation regarding the task (i.e. something on Launchpad, RT, or in the repository, or on the wiki). Tasks with no supporting documentation will be marked [Unspecifed].
1.0
TBD.
2.0
Build System
- Eliminate perl5 build requirement. [Unspecified]
Parrot currently requires perl5 to build. Eventually we wish to eliminate this requirement.
NOTE
The contents of this file are outdated and must be reviewed. See RT #48611.
UNREVIEWED CONTENT
There is no single 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.
For a high level overview of parrot milestones, please see: http://www.perlfoundation.org/parrot_grant_from_nlnet
RELEASE POLICIES
The following conditions must be met in order to release a new Parrot version:
- All bugs which cause Parrot to dump core must be addressed
- This is the highest priority.
- Fix all bugs tied to the given milestone
RELEASE HISTORY
For a list of previous releases see parrothist.pod. For a list of new and fixed features in each release see ../NEWS.
OVERVIEW
The remaining tasks are broken down into the following categories, roughly listed in the order through which a task might progress.
METADATA
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/
DESIGN
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.
TODO
Any item, whether visible to parrot users or hidden behind an API, that has already been designed (but not implemented) belongs here.
BUGFIX
Any items which have been implemented but don't work as expected.
PORTABILITY
Any items which are specific to a particular platform or require special attention for cross-platform compatibility.
DOCUMENTATION
Any items pertaining to source, API, or user level documentation.
HIGH LEVEL LANGUAGES
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.
ISSUES
METADATA
- To be included: docs/pmc, docs/resources, docs/*.pod, anything in SVN not in docs, RT. (That is, quite a bit.)
[[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.
DOCUMENTATION
- Eliminate dead documentation. Let historians dig through our subversion history. We look forward toward successful deployment.
- When docs and code disagree,
they must be brought into agreement immediately.
At the very least,
appropriately mark docs that are apparently wrong but may eventually become right,
e.g.: "
[NOTE: this does not currently work. Why? --committer]". - Document project goals and priorities.
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.)
DESIGN
- MMD Roundup 2, from the mailing list:
- Design the standard library to replace all those opcodes that should never have been opcodes in the first place, e.g. the IO and transcendental math features.
- Finish event and IO specification.
- Finish specification of return continuation and sub being called slots in interpreter, with introspection
- Spec out bytecode metadata system and introspection/modification system
- Specify what we need to serialize continuations
- Solidify design for Truly Evil speed hack for fast regex/string matching
- Describe the behavior of the serialization functions. (freeze, thaw, thawfinish, visit). PDD02
- Describe the behavior of
share. PDD02 - Describe the components of a
struct PMC_EXT. PDD04 - Define what bits of the Parrot internals should be exposed as part of the Parrot API for extension writers.
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.)
TODO
requester: leo
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. [[ 33923 ]]BUGFIX
- You can add parents to a class with children and objects, and attributes to a class with children or objects. This is silently allowed and quietly corrupts the child classes and instantiated objects.
- building miniparrot is broken
- GC issue (copying collector) - immobile strings/buffers get freed during GC.
- Memory leak - PIO subsystem leaks file handles (ParrotIO structures)
- Memory leak - string_to_cstring returns a malloced string, which isn't freed everywhere
- Memory Leaks - imcc is currently leaking Unit structures and possibly more
- JIT - 64 bit integers on 32 bit machines don't work
- JIT - parrot register inspection is incomplete (P-regs)
- This sequence:
loop: dec I0
inc I1 # or add, sub, ...
if I0, loop
isn't handled correctly on JIT/i386.
Parrot_destroy currently leaks most of the memory that it is supposed to free. embed.podPORTABILITY
- Portable fcntl() replacement for platforms without it
- See "draft/pdd01_overview.pod" in pdds. Test suite should have no failure on supported platforms.
- Tests - src/tests are not supported on all platforms
- ParrotIO uses integral file descriptors, which may not be portable. "ops/io.ops" in src
- conversion ops for machines without 1/2/4 byte integer data types
- 32 bit pointer/64 bit integer and vv.
- dynamic library loading
HIGH LEVEL LANGUAGES
- Items in languages/tcl/TODO must be completed.
FUTURE
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.
BUGS (in this document)
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.
