Version 9 (modified by cotto, 4 years ago)

various updates

Miscellanea and General Cleanup

  • 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_*'
  • 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.
    • 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
  • 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
  • Public packfile functions in src/packfile/api.c should be named Parrot_pf_*. Probably best to do this task after unrelated items are removed from that file first.
  • Parrot_load_language should be moved/renamed to src/hll.c:Parrot_hll_load

Sub Pragmas

  • :immediate and :postcomp are behaviors of the compiler only, not behaviors of libparrot. Never act on these from inside libparrot
  • :immediate and :postcomp are the same thing and should not be differentiated. Remove one of the redundant entries from pbc_action_enum_t. Keep the behavior of PBC_IMMEDIATE.
  • remove PBC_PBC, it does not appear to do anything, or doesn't do anything different from PBC_MAIN.
  • :main should not be a sub pragma anymore, and should not be executed through PackFile_fixup_subs. There should be a function/method to query the packfile to obtain a reference to the :main sub, and that sub should be returned and invoked normally. Remove PBC_MAIN from pbc_action_enum_t
  • pbc_action_enum_t should be private to the src/packfile/ subsystem. PackFile_fixup_subs should be replaced with three functions to perform specific duties: Parrot_pf_get_main, Parrot_pf_execute_load_funcs, and Parrot_pf_execute_init_funcs.
    • Actually, consider functions Parrot_pf_get_main, Parrot_pf_get_load_funcs and Parrot_pf_get_init_funcs to return a Sub or list of Subs depending on the circumstance. This way we can chose when/where/how to execute these subs. The PackFile should probably not be in charge of executing these.

Segment Dump Operations

There are utilities for dumping the contents of a Packfile. These need help:

  • 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
    • 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), now that we have the Packfile PMCs (mostly?) working...

Freeze/Thaw

  • Deprecate VTABLE_freeze and VTABLE_thaw. Replace with VTABLE_visit
  • Rename VTABLE_thawfinish to VTABLE_visit_finish

Portable PBC

  • Define new PBC encoding format for inter-host communication (network PBC)
    • optimize for portability and size, not encode/decode ease
      • protobuf varint/zig-zag encoding for ints where possible
      • network order for fixed size objects
      • UTF-8 for unicode
  • Provide mechanism for opting-in to network PBC (default is host PBC)
  • Remove complicated, now-unecessary host-to-host decode logic (pf_items.c)