Changes between Version 8 and Version 9 of PackfileTasklist

Timestamp:

01/19/11 08:17:13 (11 years ago)

Author:

cotto

Comment:

various updates

PackfileTasklist

@@ -4 +4 @@
  - Don't differentiate between "initial" packfiles and others. We should initialize the interpreter properly, and load all packfiles in through a common interface
  - Break up src/packfile/api.c into a series of smaller files, by separating out functions that work on similar things
+   - e.g.?
  - Allocate Packfile structures through the GC fixed size allocator, not mem_sys_alloc and friends
  - 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
  - Rename subsystem API functions to Parrot_pf_*'
-   - This would make a good gci task.
  - Don't differentiate between PBC_LOAD and PBC_INIT functions in a packfile
    - Pending deprecations TT #1895, TT #1896
+   - Is this still a good idea?  It seems to be a hairier yak than originally envisioned.
  - ~~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~~
- - 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. 
-  - NOTE: Using exceptions for error reporting is now a gci task.
- - break compile_or_load file into two functions, one that loads a .pbc file, and one that compiles a PIR function. Deprecate the later.
+ - ~~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. ~~
+   - mostly done, though there's some dump-related code that uses Parrot_io_printf
+ - ~~break compile_or_load file into two functions, one that loads a .pbc file, and one that compiles a PIR function.~~ Deprecate the later.
+   - Happily, the support policy doesn't apply to internal functions like these.
  - Parrot_load_language is an HLL function. it belongs in src/hll.c or similar, not in src/packfile/api.c
-   - This might make a good gci task.
  - Move pragma-related and sub-related functions into a new file: src/packfile/execute.c
  - 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
@@ -36 +37 @@
  - All dump-related functions should move to src/packfile/packdump.c
  - These functions should not output to stdout. Either add to a STRING, a StringBuilder, or some kind of new PackfileDumpVisitor
-   - 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.
+   -  STRING should be fine as a start.  We can optimize to StringBuilder later as needed.
  - These functions should not be part of struct PackFile_funcs
  - Actually, do these functions belong in src/packfile/* at all, or in frontends/pbc_dump/*? Or, do they belong as PMC methods?
-   - PMC methods makes sense to me (cotto), but that means we need to get the PMCs working...
+   - PMC methods makes sense to me (cotto), now that we have the Packfile PMCs (mostly?) working...
 
 = Freeze/Thaw =