Perplexinomicon

You know how it is. You’re trying to download some files, a bunch of ‘em, and you could use your web browser, in fact, you sort of have to because that’s how they are stored?

But that will take forever.

Enter wget, a handy little http browser that will download entire directories, including subdirectory structures.

For example, there’s a book (still unpublished) on network theory and the immune system here: http://www.physics.ubc.ca/~hoffmann/ni.html

18 chapters, 18 links, four of which are broken. Tough job… unless you use wget. If you use wget, the command wget -r http://www.physics.ubc.ca/~hoffmann/book/ downloads the whole directory and snags those lost chapters.

Several revisions and changes have passed since my last post. This is not a good thing. I went to visit the folks in MS, last weekend. I was hoping to get a lot done, but really, I ended up just flailing.

After a conversation with my advisor, I think I have a better grip on how to write a discrete event simulator just in general. The diff between revision 14 and 15 for the main sim function is pretty extreme.

17 lines out.
3 lines in.

That’s a fairly major change in philosophy, considering that the entire class is less than 60 lines. Why are such short classes so damn hard to write?

In any case, the repository is here: http://simhoc.hg.sourceforge.net:8000/hgroot/simhoc

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.