Changes between Version 3 and Version 4 of PackfileTasklist

Timestamp:

12/30/10 08:56:17 (11 years ago)

Author:

cotto

Comment:

add notes about potential and actual gci tasks in this area

PackfileTasklist

@@ -6 +6 @@
  - 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_*
+ - 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
  - ~~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.
+ - 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.
  - 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.
 
 
@@ -21 +24 @@
  - 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.
  - 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...