Gray Soft / Tags / Parsing

Rich Methods

2015-05-23T05:18:20Z

Some APIs provide collections of dirt simple methods that just do one little thing.

This approach in less common in Ruby though, especially in the core and standard library of the language itself. Ruby often gives us rich methods with lots of switches we can toggle and half hidden behaviors.

Let's look at some examples of what I am talking about.

Get a Line at a Time

I suspect most Rubyists have used gets() to read lines of input from some kind of IO. Here's the basic usage:

>> require "stringio"
=> true
>> f = StringIO.new(<<END_STR)
<xml>
  <tags>Content</tags>
</xml>
END_STR
=> #<StringIO:0x007fd5a264fa08>
>> f.gets
=> "<xml>\n"
>> f.gets
=> "  <tags>Content</tags>\n"

I didn't want to mess with external files for these trivial examples, so I just loaded StringIO from the standard library. It allows us to wrap a simple String (defined in this example using the heredoc syntax) in the IO interface. In other words, I'm calling gets() here for a String just as I could with a File or $stdin.

As the last two calls show, gets() reads until it finds a "\n" and then returns the content read. Actually, that's what it does by default, but you can tell gets() what character to read to, if you prefer:

>> f.rewind
=> 0
>> f.gets(">")
=> "<xml>"
>> f.gets(">")
=> "\n  <tags>"
>> f.gets(">")
=> "Content</tags>"

When you're working with XML documents, newlines don't really mean much. You don't actually care where they are. What you do care about are tags. Reading from tag to tag is like reading one of those great books that skip the boring bits to give you interesting scene after interesting scene.

As you can see above, one tiny change to the gets() call, specifying the character to read to as the tag ending ">", can make this happen.

"But wait, there's more!"

>> f = StringIO.new("One\n\nTwo\n\nThree")
=> #<StringIO:0x007fd5a260efa8>
>> f.gets("")
=> "One\n\n"
>> f.gets("")
=> "Two\n\n"

The empty String ("") is a magic value for the character to read to, since it makes no sense as that value. This turns on paragraph mode and in that mode Ruby will read one paragraph at a time. For this purpose a paragraphs are defined as being separated by two consecutive newlines (or a blank line in word processor terms).

These aren't even all the features of gets(). It can do more. For example, you can provide an upper limit of bytes to read, to prevent wonky input from forcing your program to allocate the tons of memory to hold large Ruby String objects.

Let's look at another method.

`Hash` Merging

Many Ruby methods sneak their rich functionality in through the use of blocks. Deferring some decision to the caller by allowing them to provide custom code for handling it makes some methods crazy flexible.

To show what I mean, let's play with good old merge():

>> {a: 1, b: 2}.merge(c: 3, d: 4)
=> {:a=>1, :b=>2, :c=>3, :d=>4}

Most Rubyists run into examples like this pretty early in their studies. The code just returns a fresh Hash containing the keys and values of both the receiver and the Hash passed as an argument to merge().

How are ties handled?

>> {a: 1, b: 2}.merge(b: :two, c: 3)
=> {:a=>1, :b=>:two, :c=>3}

The Hash passed as an argument to merge() wins. Again, I doubt this is much of a surprise to anyone.

However, I don't think everyone knows that you can take control of this merging process. During a merge() any conflict will be passed to a block, if provided, and the block can return what to store in the new Hash:

>> {a: 1, b: 2}.merge(b: :two, c: 3) { |_, old, new| Array(old) + Array(new) }
=> {:a=>1, :b=>[2, :two], :c=>3}

You can throw away either item, log the conflict, combine them as I have done here, or do whatever else you can think of, all because merge() takes a block.

Can you guess how ActiveSupport implements reverse_merge!() now?

Easy Tokenizing

Let's do one last method with a rich interface (even though Ruby has many more):

>> "1,2,3".split(",")
=> ["1", "2", "3"]

This is another very common method. It turns a String into an Array by dividing up the contents everywhere the passed separator is encountered. I used a String separator above but a Regexp is also allowed:

>> "1, 2, 3".split(/\s*,\s*/)
=> ["1", "2", "3"]

This makes it easier to handle complex separators. For example, the Regexp above permits optional whitespace characters on either side of the comma.

But a Regexp can include capture groups. How are they handled?

>> "1, 2, 3".split(/\s*(,)\s*/)
=> ["1", ",", "2", ",", "3"]

Easy enough: the captured value(s) are returned with the separated contents.

The real question this raises for me is, "What the heck is this feature good for?" Well, one thing I have found over the years is that this usage of split() can make dividing some input into tokens pretty darn easy:

>> "<xml><tags>Content</tags></xml>".split(/(<[^>]+>)/)
=> ["", "<xml>", "", "<tags>", "Content", "</tags>", "", "</xml>"]

You can use this one feature as a backbone for a moderately complex parser. Mote does just that.

I made a video explaining how this parsing trick (and more) are accomplished in detail. You can use the coupon BLOGREADER for $3 off if you want to check it out.

"You can't parse [X]HTML with regex."

2014-09-19T17:02:46Z

The only explanation I'll give for the following code it to provide this link to my favorite Stack Overflow answer.

#!/usr/bin/env ruby -w

require "open-uri"

URL    = "http://stackoverflow.com/questions/1732348/" +
         "regex-match-open-tags-except-xhtml-self-contained-tags"
PARSER = %r{
  (?<doctype_declaration>
    <!DOCTYPE\b (?<doctype> [^>]* ) >
  ){0}
  (?<comment>
    <!-- .* -->
  ){0}

  (?<script_tag>
    < \s* (?<tag_name> script ) \s* (?<attributes> [^>]* > )
      (?<script> .*? )
    < \s* / \s* script \s* >
  ){0}
  (?<self_closed_tag>
    < \s* (?<tag_name> \w+ ) \s* (?<attributes> [^>]* / \s* > )
  ){0}
  (?<unclosed_tag>
    < \s*
    (?<tag_name> link | meta | br | input | hr | img ) \b
    \s*
    (?<attributes> [^>]* > )
  ){0}
  (?<open_tag>
    < \s* (?<tag_name> \w+ ) \s* (?<attributes> [^>]* > )
  ){0}
  (?<close_tag>
    < \s* / \s* (?<tag_name> \w+ ) \s* >
  ){0}

  (?<attribute>
    (?<attribute_name> [-\w]+ )
    (?: \s* = \s* (?<attribute_value> "[^"]*" | '[^']*' | [^>\s]+ ) )? \s*
  ){0}
  (?<attribute_list>
    \g<attribute>
    (?= [^>]* > \z )  # attributes keep a trailing > to disambiguate from text
  ){0}

  (?<text>
    (?! [^<]* /?\s*> \z )  # a guard to prevent this from parsing attributes
    [^<]+
  ){0}

  \G
  (?:
    \g<doctype_declaration>
    |
    \g<comment>
    |
    \g<script_tag>
    |
    \g<self_closed_tag>
    |
    \g<unclosed_tag>
    |
    \g<open_tag>
    |
    \g<attribute_list>
    |
    \g<close_tag>
    |
    \g<text>
  )
  \s*
}mix

def parse(html)
  stack = [{attributes: [ ], contents: [ ], name: :root}]
  loop do
    html.sub!(PARSER, "") or break
    if $~[:doctype_declaration]
      add_to_tree(stack.last, "DOCTYPE", $~[:doctype].strip)
    elsif $~[:script_tag]
      add_to_stack(stack, $~[:tag_name], $~[:attributes], $~[:script])
    elsif $~[:self_closed_tag] || $~[:unclosed_tag] || $~[:open_tag]
      add_to_stack(stack, $~[:tag_name], $~[:attributes], "", $~[:open_tag])
    elsif $~[:close_tag]
      stack.pop
    elsif $~[:text]
      stack.last[:contents] << $~[:text]
    end
  end
  stack.pop
end

def add_to_tree(branch, name, value)
  if branch.include?(name)
    branch[name]  = [branch[name]] unless branch[name].is_a?(Array)
    branch[name] << value
  else
    branch[name] = value
  end
end

def add_to_stack(stack, tag_name, attributes_html, contents, open = false)
  tag = { attributes: parse_attributes(attributes_html),
          contents:   [contents].reject(&:empty?),
          name:       tag_name }
  add_to_tree(stack.last, tag_name, tag)
  stack.last[:contents] << tag
  stack                 << tag if open
end

def parse_attributes(attributes_html)
  attributes = { }
  loop do
    attributes_html.sub!(PARSER, "") or break
    add_to_tree(
      attributes,
      $~[:attribute_name],
      ($~[:attribute_value] || $~[:attribute_name]).sub(/\A(["'])(.*)\1\z/, '\2')
    )
  end
  attributes
end

def convert_to_bbcode(node)
  if node.is_a?(Hash)
    name = node[:name].sub(/\Astrike\z/, "s")
    "[#{name}]#{node[:contents].map { |c| send(__method__, c) }.join}[/#{name}]"
  else
    node
  end
end

html = open(URL, &:read).strip
ast  = parse(html)
puts ast["html"]["body"]["div"]
  .find { |div| div[:attributes]["class"] == "container"      }["div"]
  .find { |div| div[:attributes]["id"]    == "content"        }["div"]["div"]
  .find { |div| div[:attributes]["id"]    == "mainbar"        }["div"]
  .find { |div| div[:attributes]["id"]    == "answers"        }["div"]
  .find { |div| div[:attributes]["id"]    == "answer-1732454" }["table"]["tr"]
  .first["td"]
  .find { |div| div[:attributes]["class"] == "answercell"     }["div"]["p"]
  .first[:contents]
  .map(&method(:convert_to_bbcode))  # to reach a wider audience
  .join

$ ruby html_parser.rb
You can't parse [X]HTML with regex. Because HTML can't be parsed by regex.
Regex is not a tool that can be used to correctly parse HTML. As I have
answered in HTML-and-regex questions here so many times before, the use of
regex will not allow you to consume HTML. Regular expressions are a tool that
is insufficiently sophisticated to understand the constructs employed by HTML.
HTML is not a regular language and hence cannot be parsed by regular
expressions. Regex queries are not equipped to break down HTML into its
meaningful parts. so many times but it is not getting to me. Even enhanced
irregular regular expressions as used by Perl are not up to the task of parsing
HTML. You will never make me crack. HTML is a language of sufficient
complexity that it cannot be parsed by regular expressions. Even Jon Skeet
cannot parse HTML using regular expressions. Every time you attempt to
parse HTML with regular expressions, the unholy child weeps the blood of
virgins, and Russian hackers pwn your webapp. Parsing HTML with regex
summons tainted souls into the realm of the living. HTML and regex go
together like love, marriage, and ritual infanticide. The &lt;center> cannot hold
it is too late. The force of regex and HTML together in the same conceptual space
will destroy your mind like so much watery putty. If you parse HTML with regex
you are giving in to Them and their blasphemous ways which doom us all to
inhuman toil for the One whose Name cannot be expressed in the Basic
Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the
sentient whilst you observe, your psyche withering in the onslaught of horror.
Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow [i]it is too
late it is too late we cannot be saved[/i]the trangession of a chi͡ld ensures regex
will consume all living tissue (except for HTML which it cannot, as previously
prophesied) [i]dear lord help us how can anyone survive this scourge[/i]using
regex to parse HTML has doomed humanity to an eternity of dread torture and
security holes [i]using rege[/i]x as a tool to process HTML establishes a brea[i]ch
between this world[/i]and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities,
but [i]more corrupt) a mere glimp[/i]se of the world of reg[b]ex parsers for HTML
will ins[/b]tantly transport a p[i]rogrammer's consciousness i[/i]nto a w[i]orl[/i]d of
ceaseless screaming, he comes[s], the pestilent sl[/s]ithy regex-infection wil[b]l
devour your HT[/b]ML parser, application and existence for all time like Visual
Basic only worse [i]he comes he com[/i]es [i]do not fi[/i]ght h[b]e com̡e̶s, ̕h̵i[/b]s
un̨ho͞ly radiańcé de[i]stro҉ying all enli̍̈́̂̈́ghtenment, HTML tags [b]lea͠ki̧n͘g fr̶ǫm ̡yo͟ur
eye͢s̸ ̛l̕ik͏e liq[/b]uid p[/i]ain, the song of re̸gular expre[s]ssion parsing [/s]will
exti[i]nguish the voices of mor[b]tal man from the sp[/b]here I can see it can you
see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful t[/i]he f[code]inal snuf[/code]fing o[i]f the lie[b]s of Man ALL IS
LOŚ͖̩͇̗̪̏̈́T A[/b][/i][b]LL IS L[/b]OST th[i]e pon̷y he come[/i]s he c̶̮om[s]es he
co[/s][b][s]me[/s]s t[i]he[/i]ich[/b]or permeat[i]es al[/i]l MY FAC[i]E MY FACE ᵒh god
n[b]o NO NOO̼[/b][/i][b]OO N[/b]Θ stop t[i]he an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨ[/i]e̠̅s[code]͎a̧͈͖r̽̾̈́͒͑e[/code]n[b]ot rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆
ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ T[/b]O͇̹̺ͅƝ̴ȳ̳ TH̘[b]Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝[/b]S̨̥̫͎̭ͯ̿̔̀ͅ

Doing it Wrong

2014-04-24T19:22:55Z

Continuing with my Breaking All of the Rules series, I want to peek into several little areas where I've been caught doing the wrong thing. I'm a rule breaker and I'm determined to take someone down with me!

My Forbidden Parser

In one application, I work with an API that hands me very simple data like this:

<emails>
  <email>user1@example.com</email>
  <email>user2@example.com</email>
  <email>user3@example.com</email>
  …
</emails>

Now I need to make a dirty confession: I parsed this with a Regular Expression.

I know, I know. We should never parse HTML or XML with a Regular Expression. If you don't believe me, just take a moment to actually read that response. Yikes!

Oh and you shouldn't validate emails with a Regular Expression. Oops. We're talking about at least two violations here.

But it gets worse.

You may be think I rolled a little parser based on Regular Expressions. That might look like this:

#!/usr/bin/env ruby -w

require "strscan"

class EmailParser
  def initialize(data)
    @scanner = StringScanner.new(data)
  end

  def parse(&block)
    parse_emails(&block)
  end

  private

  def parse_emails(&block)
    @scanner.scan(%r{\s*<emails>\s*}) or fail "Failed to match list start"
    loop do
      parse_email(&block) or break
    end
    @scanner.scan(%r{\s*</emails>}) or fail "Failed to match list end"
  end

  def parse_email(&block)
    if @scanner.scan(%r{<email>\s*})
      if email = @scanner.scan_until(%r{</email>\s*})
        block[email.strip[0..-9].strip]
        return true
      else
        fail "Failed to match email end"
      end
    end
    false
  end
end

EmailParser.new(ARGF.read).parse do |email|
  puts email
end

If you aren't familiar with StringScanner, it's a standard Ruby library that just wraps a String and tracks your current position in that String. You can then throw Regular Expressions at the wrapped String, like I did here with scan() and scan_util(). Whenever an expressions matches, your position is advanced past it. Future expressions will then be tested at the new position. A failed match has no effect on the position.

With that understanding, the example above should be pretty easy to follow. It just looks for the start of the emails list, works through each email in the list, and then ensures the list is closed properly. I take a block when you kick off the parse() and call it each time I find a matching email to facilitate iterating over the emails.

That's great to know, but it's not what I did. I said I parsed it with a Regular Expression. My real solution looked more like this:

#!/usr/bin/env ruby -wKU

ARGF.read.scan(/[^>\s@]+@[^\s@]+\.[^\s@<]+/) do |email|
  puts email
end

If you have any sense, you should be scared blind by this point. Fair enough, but let's talk it through. Then you can lynch me.

My Regular Expression just hunts through the data for something that roughly looks like an email address. It's super low tech.

There are also new violations in this example, for those keeping score:

My email-like expression doesn't match some valid emails
With two minor character exceptions, I'm ignoring the XML completely

Alright, it's time to actually address all of these violations that are piling up. Let's start with: don't validate emails with a Regular Expression.

I'm not.

Man, that was easy. One down.

No, seriously, I'm not. I'm just hunting for emails in some data. Perhaps the API validates them before it sends them down. Perhaps we will go on to validate the addresses after we have them, most likely by actually sending a message to the address. None of this is relevant to what I'm doing here. I'm just working with what I was given.

As always though, I would rather ask why this rule exists. What is it trying to protect me from? In this case, it's two things. First, it's difficult to match a well-formed email address. The specification is quite complex. I bet you could do it with a Regular Expression (I've never tried), but it's not going to be pretty.

Honesty, I think that's an argument in my favor. I don't worry about validating at all, because you shouldn't. I look for an email email-ish thing and leave validation to the code properly suited to the task.

On a related note, my email-like expression isn't perfect. It doesn't match the entire email specification. For example, james@localhost is a valid email address that I don't match. However, that address would be for a specific machine I couldn't send email to anyway. Given that, I'm inclined to call this a feature instead of a bug.

I'm not sure what the specification says about emails containing < or >, to be painfully honest. But they should be escaped in XML anyway, so I get a buy on that issue.

Parsing XML with a Regular Expression? Again, I'm going to argue that it never happened. We already decided that I ignored the XML, right? So I'm off the hook there.

Still, why is it that we are expected to use a real parser over anything else? Well, XML can be complicated, right? I mean, this XML is still a valid representation of the same list:

<emails>
  <email>
    user1@example.com
  </email>
  <email>
    user2@example.com
  </email>
  <email>
    user3@example.com
  </email>
  …
</emails>

A parser just handles differences like that for you. But you know what? So does my solution. Try it!

OK, but the XML could really change. Let's say it became this:

<users>
  <user>
    <first>User</first>
    <last>One</last>
    <email>user1@example.com</email>
  </user>
  <user>
    <first>User</first>
    <last>Two</last>
    <email>user2@example.com</email>
  </user>
  <user>
    <first>User</first>
    <last>Three</last>
    <email>user3@example.com</email>
  </user>
  …
</users>

Now that's an interesting change, because I think it's pretty unlikely that a parser-based solution wouldn't need updates to handle that. However, my solution still works just the same.

In fact, since I am ignoring the XML, I can handle non-XML data such as this boring text list:

user1@example.com
user2@example.com
user3@example.com
…

Not that my solution is perfect, of course. It wouldn't handle a CSV list without changes, for example. Still it does seem surprisingly flexible.

In the end though, it comes down to one point for me. If this thing breaks, I'm out a few minutes of work. It was very little effort to setup and it worked fine for our needs at the time. If that changes, I can always replace it.

This just didn't seem like a huge issue. Given that, I didn't want to spend a lot of energy on it unless I was sure it was needed. A solution should generally be in the same scale as the problem itself, in my opinion.

There's a Wrong Time for Everything

Let's move on to a separate issue.

You know how you should schedule all of that pesky background work for off-peak hours so you don't hassle the users? Well, I'm not very good at that either. Have a look at these two /etc/crontab entries from this application's server:

00 17 * * *  deploy  … rake payments:schedule_due …
30 20 * * *  deploy  … rake reports:email_admin_statistics …

These times are UTC, and if you adjust for that, the first one lands right around lunchtime where I live in the middle of Central Time (11 AM or 12 PM depending on Daylight Savings Time). That means I'm doing the busy work right in the middle of the day. In fact, I chose that time because I am in the middle of the U.S. and adjusting for the time zones around me should still make it mid-morning or mid-afternoon. I wanted to make sure it's in the middle of most users' days.

Why? Well, that first job triggers the submission of due payments. There are a few steps for that process, but it will generally be resolved within a couple of hours. That means, anything in the process requiring user attention, like a failed payment, should be found when they have a decent chance of being available to do something about it.

To further that goal, the second job kicks in mid-afternoon and sends me a report of how everything went today. If something does need addressing, I'm probably still at work to handle it. My users are probably still around too, should I need to discuss anything with them.

You get the idea. We do work on off-times so it doesn't bother our users. However, if that work might need to involve users, doing it on their time can totally make sense.

Serial Storage Violations

If I will violate parsing and processing laws, you just know my database usage has to be suspect. You're right.

One of the rules for relational data storage is that we shouldn't serialize a bunch of data into some field. One way we sometimes see that done in Rails is with code list this:

class Transaction < ActiveRecord::Base
  serialize :data
end

By default that will convert whatever Ruby object is assigned to data into YAML, for storage. Then, when you retrieve the record back, the data field will be restored to its (likely non-String) form. You could even arrange to have the serialization done in a binary format or whatever you like, YAML is just the default.

Why don't we want to store data like that? Mainly because it can make it difficult to impossible to query on. That's painful because we would be giving up one of the primary reasons to use a relational database in the first place.

Of course, there's always an assumption hidden in rules like this. This time it is: you will need to query by the serialized data.

In the example shown above, it's not going to happen. A Transaction object in that system records fields passed to the application in response to API calls. An API typically gives us quite a bit of data and we typically care about just a couple of fields. Of course, we may want that data someday. You never know.

To handle that, a Transaction is created for each API response. A Hash of all provided fields is stuffed into data and serialized into the database. Then the system goes on to access just the fields it cares about and ignore everything else, knowing it was tucked away for safe keeping.

If we do ever need to pull those Transaction objects, we sure as heck won't be doing it by data we ignored. We wouldn't know what that is to use it in a query. Instead, each Transaction is tied to the relevant related record with a separate foreign key field. We would have to query on that to have any kind of context.

Plus, we get a big bonus for using this approach. The API can change the fields they are giving us and that likely wouldn't affect anything. Going one step further, we could switch to a totally different API and this setup wouldn't need to change at all. In this case, not tying ourselves to specific fields gives us flexibility and only costs us what we don't need. It's a double win.

Yes, There's a Point

Rules are great. I love them and I hand them out as much as any other programmer. Most of the time, they will help you.

Programmers need to get into the habit of dissecting rules though. You always need to be asking, "Why are they telling me this?"

Once you understand the reasoning, you can follow the rule when it makes sense, but put it aside when it's not needed. That will open up all sorts of new options for you.

Ghost Wheel Example

2014-04-05T14:56:38Z

There has been a fair bit of buzz around the Treetop parser in the Ruby community lately. Part of that is fueled by the nice screencast that shows off how to use the parser generator.

It doesn't get talked about as much, but I wrote a parser generator too, called Ghost Wheel. Probably the main reason Ghost Wheel doesn't receive much attention yet is that I have been slow in getting the documentation written. Given that, I thought I would show how the code built in the Treetop screencast translates to Ghost Wheel:

#!/usr/bin/env ruby -wKU

require "rubygems"
require "ghost_wheel"

# define a parser using Ghost Wheel's Ruby DSL
RubyParser    = GhostWheel.build_parser do
  rule( :additive,
        alt( seq( :multiplicative,
                  :space,
                  :additive_op,
                  :space,
                  :additive ) { |add| add[0].send(add[2], add[-1])},
             :multiplicative ) )
  rule(:additive_op, alt("+", "-"))

  rule( :multiplicative,
        alt( seq( :primary,
                  :space,
                  :multiplicative_op,
                  :space,
                  :multiplicative ) { |mul| mul[0].send(mul[2], mul[-1])},
             :primary ) )
  rule(:multiplicative_op, alt("*", "/"))

  rule(:primary, alt(:parenthized_additive, :number))
  rule( :parenthized_additive,
        seq("(", :space, :additive, :space, ")") { |par| par[2] } )
  rule(:number, /[1-9][0-9]*|0/) { |n| Integer(n) }

  rule(:space, /\s*/)
  parser(:exp, seq(:additive, eof) { |e| e[0] })
end

# define a parser using Ghost Wheel's grammar syntax
GrammarParser = GhostWheel.build_parser %q{
  additive             =  multiplicative space additive_op space additive
                          { ast[0].send(ast[2], ast[-1]) }
                       |  multiplicative
  additive_op          =  "+" | "-"

  multiplicative       =  primary space multiplicative_op space multiplicative
                          { ast[0].send(ast[2], ast[-1])}
                       |  primary
  multiplicative_op    =  "*" | "/"

  primary              = parenthized_additive | number
  parenthized_additive =  "(" space additive space ")" { ast[2] }
  number               =  /[1-9][0-9]*|0/ { Integer(ast) }

  space                =  /\s*/
  exp                  := additive EOF { ast[0] }
}

if __FILE__ == $PROGRAM_NAME
  require "test/unit"

  class TestArithmetic < Test::Unit::TestCase
    def test_paring_numbers
      assert_parses         "0"
      assert_parses         "1"
      assert_parses         "123"
      assert_does_not_parse "01"
    end

    def test_parsing_multiplicative
      assert_parses "1*2"
      assert_parses "1 * 2"
      assert_parses "1/2"
      assert_parses "1 / 2"
    end

    def test_parsing_additive
      assert_parses "1+2"
      assert_parses "1 + 2"
      assert_parses "1-2"
      assert_parses "1 - 2"

      assert_parses "1*2 + 3 * 4"
    end

    def test_parsing_parenthized_expressions
      assert_parses "1 * (2 + 3) * 4"
    end

    def test_parse_results
      assert_correct_result "0"
      assert_correct_result "1"
      assert_correct_result "123"

      assert_correct_result "1*2"
      assert_correct_result "1 * 2"
      assert_correct_result "1/2"
      assert_correct_result "1 / 2"

      assert_correct_result "1+2"
      assert_correct_result "1 + 2"
      assert_correct_result "1-2"
      assert_correct_result "1 - 2"

      assert_correct_result "1*2 + 3 * 4"
      assert_correct_result "1 * (2 + 3) * 4"
    end

    private

    PARSERS = [RubyParser, GrammarParser]

    def assert_parses(input)
      PARSERS.each do |parser|
        assert_nothing_raised(GhostWheel::FailedParseError) do
          parser.parse(input)
        end
      end
    end

    def assert_does_not_parse(input)
      PARSERS.each do |parser|
        assert_raises(GhostWheel::FailedParseError) { parser.parse(input) }
      end
    end

    def assert_correct_result(input)
      PARSERS.each { |parser| assert_equal(eval(input), parser.parse(input)) }
    end
  end
end

The primary differences you should note from the above code and Treetop are:

I show two different ways to build the parser using Ghost Wheel: using a Ruby DSL and using a grammar syntax. I prefer the grammar syntax in this and, in fact, most cases. The Ruby DSL can be handy when you want the AST transformations to be true closures though.
Ghost Wheel builds on your regular expression knowledge. Note that the grammar syntax is regex-like and you can even match Regexp literals.
Ghost Wheel's AST transformations are more Lispish compared to Treetop's very object oriented syntax. I think they both have strengths in certain scenarios.

There's still plenty I want to do with Ghost Wheel, but maybe this will begin the process of getting the word out about it. Feel free to post questions here.