pacc logo

Feeding Again

So I think the cook() function, that produces the secondary grammar, is pretty much there. Now comes the tricky part. Somehow, I have to arrange for these two grammars to co-exist in a single file (shouldn't be too hard; that was part of the point of the _pacc object), with different boilerplate that calls each of them...

Or, how about simply writing a second .c file, and punting to the user to tie it all together? After all, we don't currently provide any support for getting the input in the first place, so it seems a bit odd to support extending it. And that way I could probably have it finished tonight, which is very appealing!

As expected, that produces a few "multiple definition" errors, although most of them are missing statics I think. Yup, which brings it down to just parse() itself. And with a bit of judicious sed, we're at the stage where whatever ends up in the text of the grammar node gets prepended to that name. But at the moment that's hardwired to "yy", and it's too late at night to fix that.

Of course, another thing that's necessary for this to work is for the first (full) grammar not to report any errors.

Last updated: 2015-05-24 19:45:24 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