Perplexinomicon

So in my compilers class I’m supposed to write a recursive descent parser for the WAE grammar. To remind you, this grammar looks like this:

WAEStart ::= WAE SEMI
WAE ::= num | {+ WAE WAE} | {- WAE WAE} | {with {id WAE} WAE} | id


I’ve created this in python, using the PLY parser. That code has scoping issues, and is available on google code. I’ve also built this using treetop, with some modifications on the unary minus (a new rule, WAE::= -WAE , and that’s available from google code, bitbucket, and github.

But I also wanted to try to build both a recursive descent parser and possibly a packrat parser by hand, and maybe using a combinator, so I’m working on another version of this grammar using rparsec. I chose rparsec because I needed a lexer with simple, easy to understand, useful output. Possibly, there are a dozen rubygems that solve this problem, but rparsec is the one in “Practical Ruby Programming”, so that’s the one I used.

I also wanted to test out the pygments tool, which is a syntax highlighter that converts code for display in various formats. So, using pygments, my lexer looks like this:

require 'rubygems'

require 'rparsec'

module WAEParser
  include RParsec
  extend RParsec::Parsers

  Id = regexp(/[a-z]/)
  Num = number.token(:number)

  Reserved = Keywords.case_sensitive(%w{with exit})
  Ops = Operators.new(%w{+ - \{ \} ;})

  Lexer = longer(Id.token(:id) , Reserved.lexer) | Num |  Ops.lexer

  Lexeme = Lexer.lexeme << eof
end

The method Lexeme.parse(string) produces the array of tokens.

So the latest problem that came up is that a given node cannot transmit and receive simultaneously. You would think that this would be easy to solve in a discrete event simulation of a wireless ad hoc network. For example, you might do this:

1. Find all the packets you will simulate this round
2. Find all the senders of those packets
3. Set some flag to forbid them from recieving

And yeah, you can do that. The problem is, there are at least three kinds of packets. Virtual packets are symbolic, and have no meaning outside of reporting/administrative functions. They aren’t simulations of something, they are part of the simulation. But because the event queue needs packets, they exist. Actually, the event queue doesn’t need packets, now that I think about it. The event queue needs objects, and doesn’t care if those objects are packets or pachyderms. But I have to handle pachyderms, in that case.

The second kind of packet is an internal message from one part of a node to another. But you know, now that I think about it, I’m looking at this wrong. Only packets create sender conflicts. The other things aren’t packets, and they don’t need to be packets. Definitely food for thought.

Hmm… if I put my other classes in with the “Packet” class, that is, in the same file, then that file really becomes the events file, that is, the file where we define what types of messages get put on the event queue…

For some reason, I get the awful feeling that I’m programming in Ruby, but I’m actually still programming in AppleScript, or worse, in Java. Like I’m just not grokking what I could be doing here.

Wow. It’s easy to get behind in the blogging.

The bathroom project really sucked a lot out of me, to be honest. I was up at about 3 am on sunday, having put in fifteen or so hours building, moving… and I totally screwed up the toilet drain. Meaning that I’m either going to have to add about an inch of flooring in that section, or get incredibly creative with a fix.

This is not a good thing. Once PVC is set, it is set. And it occurs to me that I may not want to do the refinance anyway.

Anyway, the latest has been creating an output file and doing some fairly major refactoring in simpleHoc. My notes from a few days ago for changeset 12 say

serious refactoring. Altered the receieve packet method, it now takes a packet and then places a packed directly to the event queue, rather than back to the run_sim method in the queue. Added an output function in the Hocnode Factory class for reporting purposes.

I’m not sure about this. This is a side effect, and I try to avoid side effects. On the other hand, this makes some sense. The packet queue object calls the receive packet method, the receive packet method returns a packet to the packet queue. So it both is a side effect, in that the function that I’m calling does not return a value, but instead does something to a data structure belonging to another object. On the other hand, it isn’t a side effect, because from an object standpoint, one object sends an object and gets an object back.

Overthinking the aesthetics of your software is a productivity killer. So its ugly… does it work? Then its pretty enough, learn your lessons and move on.

This weekend, I have to install a sink and a toilet and a tub in my upstairs bathroom… that project needs to move forward ASAP. At the moment, I’m sick, which I just realized. Not surprisingly, I seem to have a cold of some kind.

Which is bad, I need to be at reasonable capacity this week.

Today, I rewrote the packet_queue to behave a little better and I think to use better ruby style. The new code looks like this


def run_sim(endTime)
   until @pheap.empty? || @pheap.first.timestamp > endTime
     @moment = @pheap.first.timestamp
     @packetlist = []
     until @pheap.empty? || (@moment != @pheap.first.timestamp)
       @packetlist.push(@pheap.shift)
     end
     @neighborhoods = Hash.new
     @packetlist.each {|x| puts x.sender}
     @packetlist.each {|x| @neighborhoods[x] = x.sender.get_neighbor_nodes(x.sigma)}
     collision_detect(@neighborhoods, @packetlist)
     @tlist = Hash.new
     until @packetlist.empty?
       @pak = @packetlist.shift
       @tlist[@pak] = []
       @neighborhoods[@pak].each {|x| @tlist[@pak] = @tlist[@pak] + x.translist}
     end
     @tlist.each_key{|key| @tlist[key].each{|x| @packetlist.push(x.receive_packet(Packet.new(key.timestamp, key.sender, key.sigma)))}}
     @packetlist.each{|x| put_packet(x)}
   end
end