Skip to content
Commits on Aug 16, 2012
  1. @Benabik
  2. @Benabik

    disasm: Piles of comments

    Benabik committed
    It would be good if someone else looking at this code had
    some idea what everything was supposed to do.
  3. @Benabik
  4. @Benabik
Commits on Aug 9, 2012
  1. @Benabik

    disasm: Show Keys

    Benabik committed
  2. @Benabik

    disasm: Separate out displaying op argument

    Benabik committed
    I'm about to reuse it to display Key contents
  3. @Benabik

    disasm: Move printing of type

    Benabik committed
    I'd like to remove all the PACT types from the constant output, so
    lets let each type handle displaying the type.
  4. @Benabik

    disasm: switch from say(a + b) to say(a, b)

    Benabik committed
    Lets me remove a lot of string() conversions
  5. @Benabik
  6. @Benabik

    Store and print multisigs

    Benabik committed
    Involves updating Packfile.Subroutine to store the sig and disasm to
    print it.
  7. @Benabik

    disasm: Catch up with the new Subroutine world

    Benabik committed
    This tracks labels based on Subroutine identity instead of name, which
    is far more reliable.  This also means that we handle labels for
    multis correctly now!
  8. @Benabik

    Packfile.Decompile: Use Subroutine in constants

    Benabik committed
    Instead of using the raw Sub, store a Packfile.Subroutine built from
    it.
  9. @Benabik

    Packfile.Subroutine: Build from a core Sub

    Benabik committed
    This also stores the Sub inside the Subroutine for future reference.
Commits on Aug 7, 2012
  1. @Benabik

    disasm: Print multi candidates

    Benabik committed
    Oh, it does it wrong, but it at least shows them
  2. @Benabik
  3. @Benabik

    Packfile.Key: use int for types

    Benabik committed
    Fixes calling the wrong multi constructor
  4. @Benabik

    Packfile.Decompile: Initial multi handling

    Benabik committed
    Appears to collect multi candidates properly
  5. @Benabik
  6. @Benabik
  7. @Benabik
  8. @Benabik

    disasm: Initial assembly output

    Benabik committed
    Probably more intelligible than the dumper output.
  9. @Benabik

    Packfile.Decompile: subs don't have get_bool

    Benabik committed
    I wanted to check for null anyway
Commits on Jul 27, 2012
  1. @Benabik

    Test PACT.Packfile.Constant

    Benabik committed
  2. @Benabik
  3. @Benabik

    Some tests for PACT.Packfile

    Benabik committed
  4. @Benabik
Commits on Jul 24, 2012
  1. @Benabik

    Test Decompiling a (basically) empty sub

    Benabik committed
    This is in t/02-decompile because I realized I probably want some
    tests for the basic packfile data structures in 01-packfile/
  2. @Benabik
  3. @Benabik

    t/common: Add decompile function

    Benabik committed
  4. @Benabik
  5. @Benabik

    Packfile: dump oplibs

    Benabik committed
  6. @Benabik

    Decompile: Don't try to pop things off a null sub

    Benabik committed
    It doesn't work very well.  Managed to avoid this one in manual
    testing by having an :immediate sub in there so there was dead code
    before the first sub.
    
    First bug caught by writing tests.  How exciting.
  7. @Benabik

    disasm: Use Winxed $directives

    Benabik committed
  8. @Benabik

    t/common: Central compile function

    Benabik committed
    Takes in PIR, outputs a Packfile.  Going to be doing this a lot so
    would rather not write those three lines over and over again.
  9. @Benabik

    Packfile.Decompile: use $load directive

    Benabik committed
    It's clearer than writing my own init function, and matches the
    style I'm using for tests.
Something went wrong with that request. Please try again.