Changes between Version 8 and Version 9 of PackfileTasklist

Show
Ignore:
Timestamp:
01/19/11 08:17:13 (4 years ago)
Author:
cotto
Comment:

various updates

Legend:

Unmodified
Added
Removed
Modified
  • PackfileTasklist

    v8 v9  
    44 - Don't differentiate between "initial" packfiles and others. We should initialize the interpreter properly, and load all packfiles in through a common interface 
    55 - Break up src/packfile/api.c into a series of smaller files, by separating out functions that work on similar things 
     6   - e.g.? 
    67 - Allocate Packfile structures through the GC fixed size allocator, not mem_sys_alloc and friends 
    78 - Don't use PARROT_EXPORT for anything (with *very few* exceptions) in src/packfile/*. This subsystem should be private and should not be used by external utilities 
    89 - Rename subsystem API functions to Parrot_pf_*' 
    9    - This would make a good gci task. 
    1010 - Don't differentiate between PBC_LOAD and PBC_INIT functions in a packfile 
    1111   - Pending deprecations TT #1895, TT #1896 
     12   - Is this still a good idea?  It seems to be a hairier yak than originally envisioned. 
    1213 - ~~The PackFile structure should keep track of the current PBC_MAIN function, and not rely on storing a reference to it in CURRENT_CONTEXT(interp). This way we can query the main function of any packfile at any time~~ 
    13  - Packfile functions should not write to Parrot_io_printf or Parrot_io_eprintf directly. Functions should throw exceptions on error, or print errors to an error buffer so an embedding application and choose where to send it.  
    14   - NOTE: Using exceptions for error reporting is now a gci task. 
    15  - break compile_or_load file into two functions, one that loads a .pbc file, and one that compiles a PIR function. Deprecate the later. 
     14 - ~~Packfile functions should not write to Parrot_io_printf or Parrot_io_eprintf directly. Functions should throw exceptions on error, or print errors to an error buffer so an embedding application and choose where to send it. ~~ 
     15   - mostly done, though there's some dump-related code that uses Parrot_io_printf 
     16 - ~~break compile_or_load file into two functions, one that loads a .pbc file, and one that compiles a PIR function.~~ Deprecate the later. 
     17   - Happily, the support policy doesn't apply to internal functions like these. 
    1618 - Parrot_load_language is an HLL function. it belongs in src/hll.c or similar, not in src/packfile/api.c 
    17    - This might make a good gci task. 
    1819 - Move pragma-related and sub-related functions into a new file: src/packfile/execute.c 
    1920 - Move Code for different kinds of segments into separate files: src/packfile/annotation_segment.c, src/packfile/debug_segment.c, src/packfile/constant_segment.c, etc 
     
    3637 - All dump-related functions should move to src/packfile/packdump.c 
    3738 - These functions should not output to stdout. Either add to a STRING, a StringBuilder, or some kind of new PackfileDumpVisitor 
    38    - Once we decide, this would be a good gci task. STRING should be fine as a start.  We can optimize to StringBuilder later as needed. 
     39   - STRING should be fine as a start.  We can optimize to StringBuilder later as needed. 
    3940 - These functions should not be part of struct PackFile_funcs 
    4041 - Actually, do these functions belong in src/packfile/* at all, or in frontends/pbc_dump/*? Or, do they belong as PMC methods? 
    41    - PMC methods makes sense to me (cotto), but that means we need to get the PMCs working... 
     42   - PMC methods makes sense to me (cotto), now that we have the Packfile PMCs (mostly?) working... 
    4243 
    4344= Freeze/Thaw =