pacc logo

A new bug

Unfortunately, there are too many projects in this world, and pacc has been neglected for too long. However, I have been looking at one of those other projects recently, in fact, the one that convinced me I needed to write pacc in the first place! A new bug has turned up. (Hooray?)

The code in dexpr() that deletes expr nodes from a feeding grammar assumes (indeed, asserts) that an expr node will have an older sibling. But that may not be the case. Consider this rule:

List ← i:Item l:List → { cell_cons(i, l) }
     / ε → cell_nil

It produces this AST:

rule 168: List
  type 167: Cell *
  alt 166:
    seq 161:
      bind 153: i
        call 152: Item
      bind 155: l
        call 154: List
      expr 160:  cell_cons(i, l)
        coords 159: 15 25
        ident 158: cell_cons
        ident 157: i
        ident 156: l
    seq 165:
      expr 164: cell_nil
        coords 163: 16 12
        ident 162: cell_nil

So dexpr() can eliminate the node expr 160 by updating the next pointer in node bind 155. But to eliminate expr 164, we need to update the first pointer in seq 165. That's easy enough to fix, just keep a pointer to the parent in dexpr too, and use that if there is no elder sibling.

Oh darn, I just implemented the fix, but I'm supposed to make a test case first. Sorted.

Last updated: 2015-05-24 19:51:22 UTC


Porting and packaging

One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging. Read More...

Release relief

Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...

See more news articles