docs/ROADMAP.pod

   1 # Copyright (C) 2005-2006, The Perl Foundation.
   2 # $Id$
   3
   4 =head1 NAME
   5
   6 ROADMAP - A plan for Parrot
   7
   8 =head1 PURPOSE
   9
  10 There is no single place in which all remaining parrot work is documented.
  11 There are various TODO files, the RT queue, comments in the source code and
  12 the documentation. This document is a first pass at unifying this information
  13 and providing a single point of reference for anyone interested in the current
  14 state of the parrot, whether they are developers looking for items to work on,
  15 or external users looking for an idea of when they can expect a release.
  16
  17 This document is not meant to contain all the metadata regarding particular
  18 tasks, but merely provide a summary of the tasks.
  19
  20 For a high level overview of parrot milestones, please see:
  21 L<http://www.perlfoundation.org/gc/grants/2005-p6-proposal.html>
  22
  23 =head1 RELEASE POLICIES
  24
  25 The following conditions must be met in order to release a new Parrot version:
  26
  27 =over 4
  28
  29 =item All bugs which cause Parrot to dump core must be addressed
  30
  31 This is the B<highest> priority.
  32
  33 =item Fix all bugs tied to the given milestone
  34
  35 =back
  36
  37 =head1 CURRENT RELEASE (0.4.6)
  38
  39 Parrot 0.4.6 was released on August 8th, 2006. For a list of new and fixed
  40 feature see L<NEWS>.
  41
  42 =head1 OVERVIEW
  43
  44 The remaining tasks are broken down into the following categories, roughly
  45 listed in the order through which a task might progress.
  46
  47 =head2 METADATA
  48
  49 Each task has certain metadata associated with it which must be tracked.
  50 Eventually all metadata should be stored in RT at L<https://rt.perl.org/rt3/>
  51
  52 =head2 DESIGN
  53
  54 These are pending design decisions which must be made before any code can be
  55 written to implement them. Note - DESIGN I<is> a special kind of documentation
  56 task, but due to the nature of this kind of documentation, it deserves to be
  57 broken out into its own category.
  58
  59 =head2 TODO
  60
  61 Any item, whether visible to parrot users or hidden behind an API, that has
  62 already been designed (but not implemented) belongs here.
  63
  64 =head2 BUGFIX
  65
  66 Any items which have been implemented but don't work as expected.
  67
  68 =head2 PORTABILITY
  69
  70 Any items which are specific to a particular platform or require special
  71 attention for cross-platform compatibility.
  72
  73 =head2 DOCUMENTATION
  74
  75 Any items pertaining to source, API, or user level documentation.
  76
  77 =head2 HIGH LEVEL LANGUAGES
  78
  79 Parrot currently ships with several partial language implementations. Any tasks
  80 which are specific to those languages, or affect cross-language compatibility
  81 will be listed here.
  82
  83 =head1 ISSUES
  84
  85 =head2 METADATA
  86
  87 =over 4
  88
  89 =item *
  90
  91 To be included: docs/pmc, docs/resources, docs/*.pod, anything in SVN not in
  92 docs, RT. (That is, quite a bit.)
  93
  94 [[What does this item mean, exactly?  --Chip]]
  95
  96 The intention was to comb through the various sources of things to be done and
  97 collate them in some fashion. At the time of that writing, none of the tasks
  98 documented in those directories were documented in a central area.  Something a
  99 little nicer than grep -r 'XXX', but that would certainly do for a start.
 100 See also L<docs/BROKEN.pod> --Coke
 101
 102 =back
 103
 104 =head2 DOCUMENTATION
 105
 106 =over 4
 107
 108 =item *
 109
 110 Eliminate dead documentation.  Let historians dig through our subversion
 111 history.  We look forward toward successful deployment.
 112
 113 =item *
 114
 115 When docs and code disagree, they must be brought into agreement immediately.
 116 At the I<very> least, appropriately mark docs that are apparently wrong but may
 117 eventually become right, e.g.: "C<[NOTE: this does not currently work.  Why?
 118 --committer]>".
 119
 120 PDDs are not exceptions to this rule!  Fix them when they're wrong.  Delete
 121 them when they're obsolete.  (Never delete docs lightly, though.  Check first
 122 with someone who should know.)
 123
 124 =item *
 125
 126 Document project goals and priorities, based on Chip's talk to APW as found at
 127 L<http://feather.perl6.nl/~chip/Chip_APW.sxi> or
 128 L<http://feather.perl6.nl/~chip/Chip_APW.pdf>.
 129
 130 =item *
 131
 132 L<memory_internals.pod> has a question about whether or not string reuse is
 133 limited to a single user or multiple users.
 134
 135 =back
 136
 137 =head2 DESIGN
 138
 139 =over 4
 140
 141 =item *
 142
 143 MMD Roundup 2, from the mailing list:
 144
 145 L<http://xrl.us/gvfw> (Link to groups-beta.google.com)
 146
 147 Section 1 of that email needs a decision from the Architect.
 148
 149 =item *
 150
 151 Design the standard library to replace all those opcodes that should never have
 152 been opcodes in the first place, e.g. the IO and transcendental math features.
 153
 154 (Note: Whatever tech we use to implement transcendental math should at *worst*
 155 compile to function calls under JIT.  And I'll consider making exceptions for
 156 the transcendantal math if someone can show me why.)
 157
 158 I expect PIR will still let you pretend they're opcodes, though, to avoid
 159 immediate howls of outrage.  (But only silicon-based life forms write PASM, so
 160 we're not worried about that.)
 161
 162 =item *
 163
 164 Finish event and IO specification.
 165
 166 =item *
 167
 168 Finish specification of return continuation and sub being called slots in
 169 interpreter, with introspection
 170
 171 =item *
 172
 173 Spec out bytecode metadata system and introspection/modification system
 174
 175 =item *
 176
 177 Specify what we need to serialize continuations
 178
 179 =item *
 180
 181 Solidify design for Truly Evil speed hack for fast regex/string matching
 182
 183 =item *
 184
 185 Describe the behavior of the serialization functions. (freeze, thaw,
 186 thawfinish, visit). L<PDD02>
 187
 188 =item *
 189
 190 Describe the behavior of C<share>. L<PDD02>
 191
 192 =item *
 193
 194 Describe the components of a C<struct PMC_EXT>. L<PDD04>
 195
 196 =item *
 197
 198 Define what bits of the Parrot internals should be exposed as part of the
 199 Parrot API for extension writers.
 200
 201 =back
 202
 203 =head2 TODO
 204
 205 =over 4
 206
 207 =item *
 208
 209  requester: leo
 210
 211 Ok. In the long run I expect a multi-stage config system. First is to get
 212 miniparrot built and running, then Parrot core. Extensions like gdbm could be
 213 configured at that point or even in a third step.
 214
 215 =item *
 216
 217 IO: Add IO tables, right now IO's just float around.
 218
 219 =item *
 220
 221 Finish PMC for IO object
 222
 223 =item *
 224
 225 IO's "stdio" layer: buffering, seek/random access, shared streams, thread safe
 226
 227 =item *
 228
 229 Copy-on-write IO stacks
 230
 231 =item *
 232
 233 Make IO layer cache the vtable calls to the next layer.
 234
 235 =item *
 236
 237 IO Filters
 238
 239 =item *
 240
 241 IO mmap support
 242
 243 =item *
 244
 245 Bottom level socket/pipe/process support in API
 246
 247 =item *
 248
 249 UTF layers (or should we not bother and do as a filter?)
 250
 251 =item *
 252
 253 Sample programs and test suite
 254
 255 =item *
 256
 257 AIO - On many platforms we must fake async IO, are we doing a background
 258 thread/interp or an inline event queue function that is called every N ops?
 259
 260 =item *
 261
 262 Get digest (probably SHA1) added to bytecode segments
 263
 264 =item *
 265
 266 Speed up the OrderedHash implementation
 267
 268 =item *
 269
 270 Rearchitect internals for the string specifications.
 271
 272 =item *
 273
 274 To PerlClass or not to PerlClass, that is the question. The class hierarchy
 275 should be reworked (e.g. Boolean->PerlInt->Scalar).
 276
 277 =item *
 278
 279 Configuration - missing tests for processor features
 280
 281 =item *
 282
 283 Configuration - duplication, e.g. nvsize/numvalsize
 284
 285 =item *
 286
 287 Tests - ~1/3 of opcodes are uncovered by tests
 288
 289 =item *
 290
 291 IO - Async core isn't there yet, even though it is rumoured to be.
 292
 293 =item *
 294
 295 Overflow detection/promotion to bigint/float types.
 296
 297 =item *
 298
 299 Fill in the remaining functions from the EDA, verify that the test suite still
 300 passes, integrate the library into the rest of Parrot, provide PMC types and
 301 suitable opcodes.  Conversion to and from Parrot strings, conversion to and
 302 from floating point types, sprintf output of bignumbers. L<PDD14>
 303
 304 [[What's an EDA? --Coke]]
 305
 306 =item *
 307
 308 Implement the Parrot equivalent of Perl 5's C<$0>, based on recent (January
 309 2005) mailing list activity. [[ 33923 ]]
 310
 311 =item *
 312
 313 The debugger needs to clone the interpreter to "allow people to play into the
 314 debugger and then continue the normal execution of the program."
 315 L<src/ops/debug.ops> (DONE). TODO - rewrite debugger.
 316
 317 =back
 318
 319 =head2 BUGFIX
 320
 321 =over 4
 322
 323 =item *
 324
 325 You can add parents to a class with children and objects, and attributes to a
 326 class with children or objects. This is silently allowed and quietly corrupts
 327 the child classes and instantiated objects.
 328
 329 =item *
 330
 331 building miniparrot is broken
 332
 333 =item *
 334
 335 GC issue (copying collector) - immobile strings/buffers get freed during GC.
 336
 337 =item *
 338
 339 Memory leak - PIO subsystem leaks file handles (ParrotIO structures)
 340
 341 =item *
 342
 343 Memory leak - string_to_cstring returns a malloced string, which isn't freed
 344 everywhere
 345
 346 =item *
 347
 348 Memory Leaks - imcc is currently leaking Unit structures and possibly more
 349
 350 =item *
 351
 352 JIT - 64 bit integers on 32 bit machines don't work
 353
 354 =item *
 355
 356 JIT - parrot register inspection is incomplete (P-regs)
 357
 358 =item *
 359
 360 This sequence:
 361
 362    loop: dec I0
 363          inc I1       # or add, sub, ...
 364          if I0, loop
 365
 366 isn't handled correctly on JIT/i386.
 367
 368 =item *
 369
 370 C<Parrot_destroy> currently leaks most of the memory that it is supposed to
 371 free. L<embed.pod>
 372
 373 =back
 374
 375 =head2 PORTABILITY
 376
 377 =over 4
 378
 379 =item *
 380
 381 Portable fcntl() replacement for platforms without it
 382
 383 =item *
 384
 385 See L<PORTABILITY>. Test suite should have no failure on supported platforms.
 386
 387 =item *
 388
 389 Tests - src/tests are not supported on all platforms
 390
 391 =item *
 392
 393 ParrotIO uses integral file descriptors, which may not be portable.
 394 L<src/ops/io.ops>
 395
 396 =item *
 397
 398 conversion ops for machines without 1/2/4 byte integer data types
 399
 400 =item *
 401
 402 32 bit pointer/64 bit integer and vv.
 403
 404 =item *
 405
 406 dynamic library loading
 407
 408 =back
 409
 410 =head2 HIGH LEVEL LANGUAGES
 411
 412 =over 4
 413
 414 =item *
 415
 416 Items in languages/tcl/TODO must be completed.
 417
 418 =item *
 419
 420 Get python bytecode translator done
 421
 422 =item *
 423
 424 Pass the pie-thon test suite.
 425
 426 =back
 427
 428 =head1 FUTURE
 429
 430 This document should eventually be obsoleted by use of the RT ticketing system,
 431 except to the extent that it documents things that show promise but have not
 432 yet been committed to.  Every task that is actually ready to be done should be
 433 documented in RT, and reports generated based on that information.
 434
 435 =head1 BUGS (in this document)
 436
 437 As for the future development, it has been pointed out that RT is not the best
 438 system for handling such things (though it does have the advantage of being
 439 available). The main point is to have single point of contact to help
 440 volunteers check (and update) the status of issues important to them.
 441
 442 =cut