PACT: Adjusting the schedule

I appear to be continuing my weekly blogging every 14 days. Ah, well. My progress has been fairly intermittent as I work out this whole "getting sleep with a newborn around", but I'm starting to make real progress again. Today's blog will discuss what I've done in the last couple weeks and an updated schedule for the next month.

My progress can be split into a few topics: syntax highlighting, style changes, bug fixes, test helpers, and tests themselves.

Syntax Highlighting

While not strictly part of my GSoC project, I have been spending a lot of time inside Vim editing Winxed files. The limitations of Vim's Winxed highlighting started to bug me until I remembered that I was the person who wrote the highlighting! My fork of whiteknight's winxed-highlight now allows vim to highlight a wider variety of winxed syntax:

Style Changes

I decided to do some things to take advantage of more Winxed features. I updated the build system to create "header files" for less Winxed warnings (via Rosella). Updating PACT to use them removes some duplication (and even more in the tests, but that was removed prior to getting committed). Finally, winxed provides a $load directive that acts like load_bytecode inside an anonymous init function, so I decided to use that instead of doing the same by hand.

I also decided the "PACT/Packfile" looked better than "pact/packfile" so recapitalized everything.

Bug Fixes

The process of writing tests pointed out several mistakes I had made:

Test Helpers

In the spirit of DRY, I moved a lot of common things for tests into a central file:


With all of that done, PACT finally gained some tests!

The first test file t/00-sanity.t makes sure things are the way the other tests expect them to be. It's nice to have things like referring to required classes and the helper functions tested before getting into anything serious.

The second test file t/02-decompile/01-empty_sub.t tests the result of decompiling the most basic PIR sub I could think of:

.namespace [] # workaround for IMCC bug
.sub 'empty_sub'

(There seems to be something strange going on with calling IMCC from inside the test and loading Rosella. The namespace directive avoids the bug but doesn't affect the tests.)

Those three lines of PIR generate: 2 PMC constants, 4 string constants, and 3 ops. That becomes 9 PACT nodes:

  • PACT.Packfile
    • 2 PMC constants
      • Empty FIA for PCC
      • The empty_sub Sub
    • 4 string constants
      • A random null string (from IMCC somewhere?)
      • '(file unknown)' because IMCC doesn't know where it came from
      • 'parrot' for the parrot namespace
      • 'empty_sub' for the sub name
    • The root PACT.Namespace
      • A parrot PACT.Namespace (for the parrot 'HLL')
        • The empty_sub PACT.Subroutine, containing:
          • A PACT.Debug annotation with the file name
          • A PACT.Label for PC 0
          • A PACT.Op for set_returns, containing:
            • A PACT.Constant.Reference to the empty FIA
          • A PACT.Label for PC 2
          • A PACT.Op for returncc

The test checks that all of that is true. This is possibly a slightly fragile test, but it makes sure that Decompile is doing its job and producing exactly what I expect. Due to the amount of things the test checks, it is vulnerable to fairly minor changes in IMCC, but that's the nature of the game. Further tests can test individual features knowing that the overall framework seems to work.


I haven't yet discussed this with cotto or whiteknight, but this is what I'm thinking will happen over the next couple weeks:

August 1 Unit Tests / Disassembly Output: Write unit tests to test disassembler and data structures. I have already designed an assembly language, so use it for disasm.

August 8 Basic Packfile Creation: Skip parsing, head straight to creating Packfiles. I expect this to be slightly hazard prone. Work in TDD style, writing a test for a packfile and then seeing if it works.

August 15 Suggested 'pencils down' date / Parsing: Parsing the language should be fairly simple, and hooking it up to the proven working packfile output should also be easy. (Knock on wood.) There will probably be missing features and code it can't generate, but it should be a good proof of concept.

August 22 Firm 'pencils down' date: Code cleaning and documentation. The goal is to get it to a point where it's fairly obvious where new features can be added.