Permalink
Switch branches/tags
Commits on Nov 28, 2010
  1. Update version to 0.5.1

    dmajda committed Nov 28, 2010
  2. Update CHANGELOG

    dmajda committed Nov 28, 2010
Commits on Nov 20, 2010
  1. Make sure quoting functions output only ASCII characters

    dmajda committed Nov 20, 2010
    This patch prevents portability problems. In particular, it fixes a
    problem where "SyntaxError: Invalid range in character class." error
    appeared when using command-line version on Widnows (see GH-13).
    
    Port of commit aeb2cb4 from master.
Commits on Nov 14, 2010
  1. Bump version to 0.5+

    dmajda committed Nov 14, 2010
  2. Remove two unused variables

    dmajda committed Nov 14, 2010
    Port of commit c8836c0 from master.
  3. Fix incorrect variable name on two places

    dmajda committed Nov 14, 2010
    Port of commit 088c78e from master.
Commits on Jun 10, 2010
  1. Updated version to 0.5

    dmajda committed Jun 10, 2010
  2. CHANGELOG: Fix 0.5 release date

    dmajda committed Jun 10, 2010
  3. README.md tweaks

    dmajda committed Jun 9, 2010
Commits on Jun 9, 2010
  1. Updated CHANGELOG

    dmajda committed Jun 9, 2010
  2. README.md: Fix example code

    dmajda committed Jun 9, 2010
  3. Improve README.md

    dmajda committed Jun 8, 2010
Commits on Jun 8, 2010
  1. Implement semantic predicates

    dmajda committed Jun 8, 2010
  2. Start rule of the grammar is now implicitly its first rule

    dmajda committed Jun 8, 2010
    Before this change, the start rule was the one named "start" and there
    was an option to override that. This is now impossible.
    
    The goal of this change is to contain all information for the parser
    generation in the grammar itself.
    
    In the future, some override directive for the start rule (like Bison's
    "%start") may be added to the grammar.
  3. Reset generated variable names for each rule parsing function

    dmajda committed Jun 8, 2010
    Little change in the source grammar now does not change variables in all
    the generated code. This is helpful especially when one has the
    generated grammar stored in a VCS (this is true e.g. for our
    metagrammar).
  4. Implement initializers

    dmajda committed Jun 8, 2010
Commits on Jun 7, 2010
  1. Fix incorrect comment

    dmajda committed Jun 7, 2010
  2. Move lot of stuff in generated parsers into the |parse| method

    dmajda committed Jun 7, 2010
    We want to have the rule parsing functions inside the |parse| method
    because we want them to share a common environment. In the future,
    initializers will be executed in this enviromnent and thus functions and
    variables defined by them will be accessible to the rule parsing
    functions.
    
    Moving various private properties from the parser object into the
    |parse| method was not strictly necessary, but it was a natural step
    after moving the functions.
  3. Use labeled expressions and variables instead of $1, $2, etc.

    dmajda committed May 31, 2010
    Labeled expressions lead to more maintainable code and also will allow
    certain optimizations (we can ignore results of expressions not passed
    to the actions).
    
    This does not speed up the benchmark suite execution statistically
    significantly on V8.
    
    Detailed results (benchmark suite totals):
    
    ---------------------------------
     Test #     Before       After
    ---------------------------------
          1   28.43 kB/s   28.46 kB/s
          2   28.38 kB/s   28.56 kB/s
          3   28.22 kB/s   28.58 kB/s
          4   28.76 kB/s   28.55 kB/s
          5   28.57 kB/s   28.48 kB/s
    ---------------------------------
    Average   28.47 kB/s   28.53 kB/s
    ---------------------------------
    
    Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
Commits on May 31, 2010
  1. Formatted all grammars more consistently and transparently

    dmajda committed May 23, 2010
    This is purely cosmetical change, no functionality was affected
    (hopefully).
  2. Replace ":" after a rule name with "="

    dmajda committed May 23, 2010
    I'll introduce labelled expressions shortly and I want to use ":" as a
    label-expression separator. This change avoids conflict between the two
    meanings of ":". (What would e.g. "foo: 'bar'" mean?  Rule "foo"
    matching string "bar", or string "bar" labelled "foo"?)