David Vollbracht - Home

30 Days of Tech: Day 30 - Haskell Decompose

2008-07-01T02:48:00Z

Some time ago Tom, a friend, presented a math programming challenge to a me and a few others. The challenge was to create a function that when given a positive number would return a set of all the sets of positive numbers whose sum was the original number. He wasn’t so much interested in the result itself as he was in what sort of techniques were used in the implementation—memoization of course being a choice candidate for this problem. I was toying a lot with Haskell at the time, and since this was fundamentally a math problem, Haskell seemed well suited to the problem too.

Here’s what I came up with:


  module Decompose
    where

  import Data.List

  decompose = ((map decompose' [0..]) !!) where
    decompose' n = nub (map sort (decompositions n (floor ((toRational n)/2))))

  decompositions n 0 = [[n]]
  decompositions n m = nmCombinations ++ decompositions n (m - 1) where
    nmCombinations = [a ++ b | a <- (decompose (n - m)), b <- (decompose m)]

I was surprised at how short the Haskell solution was. If you run this through Hugs, you’ll see something like this:


  Hugs> :load "Decompose" 
  Decompose> decompose 5
  [[1,1,1,1,1],[1,1,1,2],[1,2,2],[1,1,3],[2,3],[1,4],[5]]
  Decompose> decompose 10
  [[1,1,1,1,1,1,1,1,1,1],[1,1,1,1,1,1,1,1,2],[1,1,1,1,1,1,2,2],[1,1,1,1,1,1,1,3],[1,1,1,1,1,2,3],[1,1,1,1,1,1,4],[1,1,1,1,1,5],[1,1,1,1,2,2,2],[1,1,1,2,2,3],[1,1,1,1,2,4],[1,1,1,2,5],[1,1,2,2,2,2],[1,2,2,2,3],[1,1,2,2,4],[1,2,2,5],[1,1,1,1,3,3],[1,1,2,3,3],[1,1,1,3,4],[1,1,3,5],[2,2,3,3],[1,2,3,4],[2,3,5],[1,1,4,4],[1,4,5],[5,5],[1,3,3,3],[3,3,4],[2,2,2,2,2],[2,2,2,4],[2,4,4],[1,1,1,1,6],[1,1,2,6],[2,2,6],[1,3,6],[4,6],[1,1,1,7],[1,2,7],[3,7],[1,1,8],[2,8],[1,9],[10]]

The only performance trick in here is indeed memoization, though that may not be obvious at first. It lies in the definition of decompose. The decompose function is really just a list of decomposition results for all positive numbers, indexed by the number being decomposed. Obviously this would be an infinitely long lost, but Haskell has no problem handling that—it just calculates elements of the list on demand. Since decomposing a number always involves decomposing all the numbers below it, the fact that you have to calculate the list out to the length of the original number being decomposed is not a hindrance, it’s actually an advantage!

30 Days of Tech: Day 29 - C, Ruby, & Threads, Oh My!

2008-06-30T03:07:00Z

When Philippe and I worked on SystemTimer together we went back and forth about how much to write in Ruby and how much to write in C. Writing purely at the C level gave us more control over what was happening in the Ruby process as we installed and cleared signal handlers and such, but working in Ruby produced far more readable code.

Ultimately we ended up writing a hybrid—Ruby code that calls C code that calls back into Ruby code for a few interesting bits. When I go back and look at the result now, I’m pretty happy with it. There was one trick we had to pull in our situation, however, to ensure everything went according to plan. Since we entered C code to perform low level operations with timers we felt we didn’t want our code to be interrupted by Ruby’s thread scheduling. We wanted to ensure the timer got set up properly without the chance of another thread being scheduled. At first this led is to try to write as much in C as possible, since we wouldn’t ever hit the Ruby thread scheduler. Eventually we realized we could clean up a bunch of C code by extracting Ruby methods. To prevent other threads from being scheduled, we simply extracted C functions to wrap the Ruby methods, like this one.


  static void install_ruby_sigalrm_handler(VALUE self) {
    rb_thread_critical = 1;
    rb_funcall(self, rb_intern("install_ruby_sigalrm_handler"), 0);
    rb_thread_critical = 0;
  }

The C function install_ruby_sigalrm_handler is called by another C function, and is quite readable in that context. If you’re reading the C code, you don’t even have to know it’s calling back to Ruby. All the C function does, however, is set rb_thread_critical and then call back into Ruby code. rb_thread_critical is the equivalent of Thread.critical in the Ruby API. When it is set, Ruby will not schedule another thread (except in a few cases documented with Thread.critical). Using this simple tool we were able to effectively blend Ruby and C code without worrying about our operations being preempted. Arigatoo, Matsumoto-san.

30 Days of Tech: Day 28 - lambda args

2008-06-29T03:08:00Z

The Ruby documentation for the lambda method (a.k.a. proc) says “Equivalent to Proc.new, except the resulting Proc objects check the number of parameters passed when called.” This is almost exactly right. There are, however, at least two cases where this turns out to be false.

The first is when the block passed to lambda does not have an argument list specified. The resulting Proc object will not check arguments in this case.


  def test_lambda_checks_arguments
    l = lambda {||}
    assert_raises(ArgumentError) {l.call(1)}
  end

  def test_lambda_doesnt_check_arguments_if_no_arguments_specified
    l = lambda {}
    assert_nothing_raised {l.call(1)}
  end

The two tests above prove that Proc#call doesn’t check arguments for a lambda proc with no arguments unless you specify that the proc takes no arguments by including an empty parameter list. This is not the only case where argument checking is not done for lambda procs, however.

If you pass a lambda proc to a method is a block (using &), this circumvents the argument checking that would normally take place, even when you specify a blank argument list.


  def test_lambda_doesnt_check_arguments_when_yielded_to_even_if_arguments_specified
    l = lambda {||}
    def yield_1_to; yield 1; end
    assert_nothing_raised {yield_1_to &l}
  end

The above test passes, even though one argument is yielded to a lambda proc that explicitly takes no args. I haven’t read the source yet, but my guess about what’s happening here is that Ruby converts the proc back to a normal block. Since blocks normally don’t check arguments, there’s no reason to expect the one here to either. Nonetheless, the result surprised me until I thought about it longer.

I categorize this as one of those Ruby oddities that for the most part doesn’t hurt you in practice. I don’t recall ever having run into a bug or debugging issue where not knowing about this hindered me. I do think that building knowledge about oddities like these is good practice though. It deepens your knowledge of Ruby in general, and every so often one small bit of knowledge will save you a chunk of time.

30 Days of Tech: Day 27 - Short Circuited Timeout

2008-06-28T03:30:00Z

Ruby’s timeout method operates by raising a exception, Timeout::Error. Timeout::Error inherits from Interrupt, SignalException, and finally Exception. In particular, it doesn’t inherit from StandardError, which means it isn’t caught by a default rescue clause with no exception class specified. When I first encountered this, I was annoyed that I had to explicitly catch timeout errors anytime I wanted to recover from errors in general, whether they were timeout errors or not. I realized something the other day that changed my opinion on this however.

Here’s the timeout method for Ruby 1.8.6.


  def timeout(sec, exception=Error)
    return yield if sec == nil or sec.zero?
    raise ThreadError, "timeout within critical session" if Thread.critical
    begin
      x = Thread.current
      y = Thread.start {
        sleep sec
        x.raise exception, "execution expired" if x.alive?
      }
      yield sec
      #    return true
    ensure
      y.kill if y and y.alive?
    end
  end

It operates by starting a thread, y that will raise an exception after sleeping. It raises the exception by calling x.raise, causing the exception be raised in thread x, which is the thread that called timeout—the one doing the work that needs to be timed out. That exception terminates the execution of the thread wherever it happens to be and starts propagating an exception up the stack. This exception is subject to the same handling as every other exception that might happen. It can caught be a rescue clause. In particular, it can be caught by a rescue clause that is within the block being subjected to the timeout


  require 'timeout'

  begin
    Timeout.timeout(1) do
      begin
        sleep 2
      rescue Exception => e
        puts "Caught #{e.inspect} within timeout" 
      end
    end
  rescue Exception => e
    puts "Caught #{e.inspect} at top level" 
  end

This produces the output Caught #<Timeout::Error: execution expired> within timeout. If Timeout::Error extended from StandardError, it would be caught by any generic rescue expression that would handle exceptions occurring at the point where the timeout error happened to be raised. This rescue clause may not even be in your application code—it could be in a library or the Rails framework, which could result in very hard to track down bugs. We can verify this is the case by specifying what type of error timeout should raise.


  require 'timeout'

  begin
    Timeout.timeout(1, StandardError) do
      begin
        sleep 2
      rescue => e
        puts "Caught #{e.inspect} within timeout" 
      end
    end
  rescue => e
    puts "Caught #{e.inspect} at top level" 
  end

The only differences here are that Timeout.timeout is passed the type of exception to raise, StandardError, and that the rescue clauses have be changed to omit the exception type. The output is essentially the same as before, Caught #<StandardError: execution expired> within timeout.

Incidentally, SystemTimer terminates the offending thread by raising an exception as well. If there is a rescue clause that handles Timeout::Error within the block given for either Timeout or SystemTimer, it could prevent the error from reaching handling code outside the timeout call. Fortunately the likelihood of encountering this scenario is minimized because Timeout::Error doesn’t inherit from StandardError. I haven’t hit a bug caused by this in practice yet. I’m sure if I had before I had thought through the situation it would have taken me a lot longer to figure out what was going on.

30 Days of Tech: Day 26 - Fixnum#object_id

2008-06-27T03:25:00Z

In Ruby every object has an object_id that uniquely identifies that object in that particular instance of the Ruby process. Ruby also treats integers as objects—they are instances of Fixnum. For efficiency reasons, though, Ruby implements integers internally as simple values. That is, it doesn’t allocate heap memory for every integer you use, it just passes the value around instead. So how does Ruby generate object ids for all these integers?

You may have never noticed, but all the object ids that you usually end up seeing are even.


  irb(main):011:0> Object.object_id
  => 110230
  irb(main):012:0> Object.new.object_id
  => 191490
  irb(main):013:0> nil.object_id
  => 4
  irb(main):014:0> "a_string".object_id
  => 177360

This is because Ruby is reserving all the odd numbers to be object_ids for Fixnums.


  irb(main):015:0> 1.object_id
  => 3
  irb(main):016:0> 2.object_id
  => 5
  irb(main):017:0> 3.object_id
  => 7
  irb(main):018:0> 4.object_id
  => 9

Not only are they reserved, they’re calculated using a simple formula! This allows Ruby to easily get back to the value from the id if you should ever ask for it.


  irb(main):022:0> ObjectSpace._id2ref(9)  
  => 4

And now if you ever see an odd (as in n % 2 = 1, not strange) object_id in some Ruby output somewhere, you’ll know immediately what the value of that object is!

30 Days of Tech: Day 25 - Gem dependency version

2008-06-26T01:27:00Z

RubyGems and I had a fight. It was about what version of net-ssh we wanted to have installed on my machine. RubyGems wanted the latest (2.0.2) and I wanted a 1.x version (1.1.4). Apparently net-ssh 2 has an issue with sshing into Fedora Core 4, which I needed it to do. Specifically I needed to use capistrano 1.4.1 to deploy an app to Fedora Core 4

This is something I’ve been doing regularly for some time, but ever since the MacBrick incident I haven’t needed these specific gems installed, so I was starting from scratch. Once I figured out what version of the gems I wanted, here was my first attempt: (I included --no-rdoc and --no-ri just to save time writing this post).


  $ sudo gem install net-ssh --version=1.1.4 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-1.1.4
    1 gem installed
  $ sudo gem install capistrano --version=1.4.1 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-2.0.2
    Successfully installed net-sftp-2.0.1
    Successfully installed capistrano-1.4.1
    3 gems installed

Clearly this didn’t work so well. Installing capistrano installed the latest version of net-ssh. But why? Capistrano’s gemspec for 1.4.1 says this


  ...
  s.add_dependency(%q<net-ssh>, [">= 1.0.10"])
  s.add_dependency(%q<net-sftp>, [">= 1.1.0"])
  ...

But net-sftp 2.0.1’s gemspec says it needs net-ssh 1.99.1. So we need to install specific version of both. So, attempt number two.


  $ sudo gem install net-ssh --version=1.1.4 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-1.1.4
    1 gem installed
  $ sudo gem install net-sftp --version=1.1.0 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-2.0.2
    Successfully installed net-sftp-1.1.0
    2 gems installed

Rats. Even though net-sftp 1.1.0 only specifies that it depends on net-ssh >= 1.0.0, RubyGems went ahead and installed the latest version anyway. It assumed that even though the dependency was satisfied, I want the latest version of net-ssh— exactly what I’m trying to avoid.

Armed with this information, I made one last ditch attempt.


  $ sudo gem install capistrano --version=1.4.1 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-2.0.2
    Successfully installed net-sftp-2.0.1
    Successfully installed capistrano-1.4.1
    3 gems installed
  $ sudo gem install net-ssh --version=1.1.4 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-ssh-1.1.4
    1 gem installed
  $ sudo gem install net-sftp --version=1.1.0 --no-rdoc --no-ri
    Bulk updating Gem source index for: http://gems.rubyforge.org/
    Successfully installed net-sftp-1.1.0
    1 gem installed
  $ sudo gem uninstall net-sftp net-ssh

    Select gem to uninstall:
     1. net-sftp-1.1.0
     2. net-sftp-2.0.1
     3. All versions
    > 2
    Successfully uninstalled net-sftp-2.0.1

    Select gem to uninstall:
     1. net-ssh-1.1.4
     2. net-ssh-2.0.2
     3. All versions
    > 2
    Successfully uninstalled net-ssh-2.0.2

Finally, by letting RubyGems install the latest version of net-ssh and net-sftp, then installing the versions I wanted, and the uninstalling the offending versions, I was able to get into a working state to deploy. Hopefully I’ll never run into this problem again. If you should be so unlucky, however, I hope this knowledge will help you.

30 Days of Tech: Day 24 - drubyall

2008-06-25T03:18:00Z

When we first started trying to use distributed DeepTest, we quickly ran into an issue with DRb servers not binding to the correct addresses. DRb does provide a way to bind to 0.0.0.0 to listen to all addresses, but there’s a downside to the way it does it. The url you provide to DRb to accomplish this must omit the hostname (e.g. druby://:0/). DRb then determines what hostname to report to clients by calling getaddrinfo with the empty hostname. Unfortunately for us getaddrinfo didn’t provide a hostname that could be used by our developer machines to connect to the DeepTest servers. For a brief moment we thought we were stuck.

When we looked into how DRb handles protocols, however, we realized we could simply add a protocol that would accept a hostname as part of the url and use it to report the DRb url to clients when needed. For listening on the network, however, the protocol always binds to 0.0.0.0. By registering this protocol (which we called drubyall since it listens on all interfaces) you can use it in any DRb url, which is pretty handy. Although it wasn’t nice that we ran into the problem, it was very nice that DRb gave us an easy out to extending its communications layer.


  module DeepTest
    class DRbBindAllTCPSocket < DRb::DRbTCPSocket
      def self.parse_uri(uri)
        if uri =~ /^drubyall:\/\/(.*?):(\d+)(\?(.*))?$/
          host = $1
          port = $2.to_i
          option = $4
          [host, port, option]
        else
          raise(DRb::DRbBadScheme, uri) unless uri =~ /^drubyall:/
          raise(DRb::DRbBadURI, 'can\'t parse uri:' + uri)
        end
      end

      # Open a server listening for connections at +uri+ using 
      # configuration +config+.
      def self.open_server(uri, config)
        uri = 'drubyall://:0' unless uri
        host, port, opt = parse_uri(uri)

        if host.size == 0
          host = getservername
        end

        DeepTest.logger.debug("Listening on port #{port}, all addresses.")
        soc = TCPServer.open('0.0.0.0', port)          
        port = soc.addr[1] if port == 0
        uri = "druby://#{host}:#{port}" 
        self.new(uri, soc, config)
      end
    end
  end

  DRb::DRbProtocol.add_protocol DeepTest::DRbBindAllTCPSocket

30 Days of Tech: Day 23 - DearSoul

2008-06-24T02:11:00Z


  class DearSoul
    def self.new(first, last)
      ObjectSpace.define_finalizer(allocate, proc {|id|
        puts "Goodbye, #{first}.  We'll miss you." 
      })
    end
  end

  DearSoul.new("George", "Carlin")

30 Days of Tech: Day 22 - Class#to_proc

2008-06-23T02:58:00Z

Here’s a little hack for Ruby classes that comes from a project.


  class Class
    def to_proc
      method(:new).to_proc
    end
  end

If you’ve ever used map (a.k.a. collect) to create a bunch of objects you might be familiar with code that looks something like this.


   value_list.map {|v| Something.new(v)}

With Class#to_proc this can be simplified to


  value_list.map(&Something)

This works very well for map, but I haven’t seen Class#to_proc become useful in any other situation to date. Even changing map to collect changes my opinion of it’s expressiveness. I don’t know that Class#to_proc is pulls its weight in our situation, but I just like the map statement above too much to give it up.

30 Days of Tech: Day 21 - Object Literals

2008-06-22T03:33:00Z

You can do object oriented programming in both Ruby and Javascript. I think most people would agree that Ruby is “more” object oriented than Javascript, whatever subjective judgement they’re using. One thing that’s interesting to me, though, is that Javascript has a syntax for literal objects built in where as Ruby does not.

Javascript is prototype based, which means that every object that’s created actually just copied from another object. The object being copied is called the “prototype”, and forms a sort of factory for creating new objects. But then were do the prototype objects come from? If all objects are created from prototypes, shouldn’t the prototypes be created from other prototypes? Javascript sort of sidesteps this issue a bit—it’s only half prototype based. All objects in Javascript are really just hashes and Javascript has a syntax for writing hash literals. That means you can create an object in Javascript just by creating a hash and skip the whole prototype business.


  var counter = {
    count: 0,
    increment: function() {this.count +=1},
    decrement: function() {this.count -=1}
  };

This is a perfectly good counter object in Javascript. If you wanted to create a similar object in Ruby, the most straightforward way would be simply to create a class.


  class Counter
    def initialize
      @count = 0
    end

    def increment
      @count += 1
    end

    def decrement
      @count -= 1
    end
  end

  counter = Counter.new

There’s nothing wrong with this implementation at all. Every so often, though, I run into a situation where I just want to roll an object with 1 or 2 methods inline rather that creating a class. The class usually ends up outside the method, at best, if not in a separate file. In general this is good separation, but if the code is very simple it is sometimes more clear to simply see it in the context of the method that needs it. There is a roundabout way of achieving this in Ruby.


  counter = Object.new.instance_eval do
    @count = 0

    def increment
      @count += 1
    end

    def decrement
      @count -= 1
    end

    self
  end

I don’t think this buys you very much. It’s not very intention revealing, which means a new person reading it may spend as long understanding why it’s written like this as they would looking at up a separate class. Wouldn’t it be nice if Ruby supported a syntax to clean this up at least a bit? Maybe something like


  object counter
    @count = 0

    def increment
      @count += 1
    end

    def decrement
      @count -= 1
    end
  end

Well, we can’t quite make it there without extending the syntax, but we can make a reasonable facsimile.


  def object(&block)
    object = Object.new
    object.instance_eval(&block)
    object
  end

  counter = object do
    @count = 0

    def increment
      @count += 1
    end

    def decrement
      @count -= 1
    end
  end

If you find yourself working in a system that demands a lot of object literals for some reason, I’m sure you’ll want something of the sort. Also, if you’re working on such a system, I fear for your soul…

30 Days of Tech: Day 20 - Unmixed Methods

2008-06-21T03:36:00Z

mixology is a Ruby extension implemented by some of the Something Nimble collaborators. In short, it allows you to add modules to Objects (much like Ruby’s extend), but in such a way that they can also be removed. Mixology refers to these operations as mixin and unmix. If you want to know more about Mixology and the people behind it, here is a good resource. For the purposes of our discussion, here’s a simple example:


  irb(main):001:0> require 'rubygems'; require 'mixology'
  => true
  irb(main):002:0> module A
  irb(main):003:1> def foo; puts "bar"; end
  irb(main):004:1> end
  => nil
  irb(main):005:0> o = Object.new
  => #<Object:0x4f2b8>
  irb(main):006:0> o.foo
  NoMethodError: undefined method `foo' for #<Object:0x4f2b8>
          from (irb):6
  irb(main):007:0> o.mixin A
  => #<Object:0x4f2b8>
  irb(main):008:0> o.foo
  bar
  => nil
  irb(main):009:0> o.unmix A
  => #<Object:0x4f2b8>
  irb(main):010:0> o.foo
  NoMethodError: undefined method `foo' for #<Object:0x4f2b8>
          from (irb):10

We can see that after o.unmix A the foo method is no longer accessible on the object o. But is there any way we could end up executing the foo method anyhow? It turns out there is. Let’s look at this example:


  irb(main):001:0> require 'rubygems'; require 'mixology'
  => true
  irb(main):002:0> module A
  irb(main):003:1> def foo; puts self.inspect; end
  irb(main):004:1> end
  => nil
  irb(main):005:0> o = Object.new
  => #<Object:0x4d1ac>
  irb(main):006:0> o.mixin A
  => #<Object:0x4d1ac>
  irb(main):007:0> o.foo
  #<Object:0x4d1ac>
  => nil
  irb(main):008:0> foo = o.method(:foo)
  => #<Method: Object(A)#foo>
  irb(main):009:0> o.unmix(A)
  => #<Object:0x4d1ac>
  irb(main):010:0> o.foo
  NoMethodError: undefined method `foo' for #<Object:0x4d1ac>
          from (irb):10
  irb(main):011:0> foo.call
  #<Object:0x4d1ac>
  => nil

In this second example we can see that even though foo can’t be invoked through the object (since module A is no longer mixed in), Ruby has no problem invoking the method using the Method object that was grabbed before unmixing A. So yes, we can access foo if we should absolutely need to. There is one gotcha with this technique, however—even though we are in foo, no other methods from A are available!


  irb(main):001:0> require 'rubygems'; require 'mixology'
  => true
  irb(main):002:0> module A
  irb(main):003:1> def called_as_method_object
  irb(main):004:2> puts "got in, executing method_no_longer_available" 
  irb(main):005:2> method_no_longer_available
  irb(main):006:2> end
  irb(main):007:1> 
  irb(main):008:1* def method_no_longer_available
  irb(main):009:2> raise "Will never make it" 
  irb(main):010:2> end
  irb(main):011:1> end
  => nil
  irb(main):012:0> o = Object.new
  => #<Object:0x366dc>
  irb(main):013:0> o.mixin A
  => #<Object:0x366dc>
  irb(main):014:0> method = o.method(:called_as_method_object)
  => #<Method: Object(A)#called_as_method_object>
  irb(main):015:0> o.unmix A
  => #<Object:0x366dc>
  irb(main):016:0> method.call
  got in, executing method_no_longer_available
  NameError: undefined local variable or method `method_no_longer_available' for #<Object:0x366dc>
          from (irb):5:in `called_as_method_object'
          from (irb):16:in `call'
          from (irb):16
          from :0

The implication of this is significant. If the code in called_as_method_object becomes complicated, you can’t even perform extract method to refactor it! Given that this technique is obscure to begin with and has this major limitation, I recommend you not use it if at all possible. That being said, you may find yourself in a situation where it’s the best option available, at least for the moment. I mean, how else would I come up with this stuff?

30 Days of Tech: Day 19 - instance_eval & Method#to_proc

2008-06-20T03:58:00Z

Ruby has instance_eval that accepts a block and executes it with self set to the receiver of instance_eval. Ruby also has a method called method that returns a Method object representing a callable method on an object. Method objects, in turn, have a method called to_proc which allows them to be converted to blocks. These are all facts I knew when the day began, but never before had this question occurred to me: what happens when you pass the result of Method#to_proc into instance_eval? What is self? The answer surprised me actually…


  def test_method_must_take_one_argument_for_instance_eval
    instance = Class.new {def take_no_args; end}.new
    begin
      Object.new.instance_eval(&instance.method(:take_no_args))
      flunk "No ArgumentError was raised" 
    rescue ArgumentError => e
      assert_equal "wrong number of arguments (1 for 0)", e.message
    end
  end

  def test_argument_to_method_for_instance_eval_is_receiver_of_instance_eval
    instance = Class.new {def return_argument(o); o; end}.new
    obj = Object.new
    assert_equal obj, obj.instance_eval(&instance.method(:return_argument))
  end

  def test_self_within_instance_eval_is_original_instance
    instance = Class.new {def return_self(o); self; end}.new
    assert_equal instance, Object.new.instance_eval(&instance.method(:return_self))
  end

The first test was the one that surprised me. An ArgumentError being raised would certainly not have been my first guess about what was going to happen. The fact that the error is raised, however, is due to the answer to the “what is self?” question. It turns out that self is left as the object that the method is from—i.e. the block isn’t really evaluated in the context of the instance that received instance_eval. This seems reasonable, since methods must be executed on instances of the classes they are defined for. Allowing instance_eval to change self for a method would break this rule. What is interesting, however, is that a sort compromise has been struck. Instead of setting self to the receiver of instance_eval, the receiver is passed to the method as an argument. Thus if you really need to pass a method object off to some code that is doing instance_eval, you’ll still have access to the object that received the instance_eval message, just in case you need it. I haven’t ever hit this in practice, so I’m not sure whether I’d rather have access to the object or not in general, but I can understand why one might. If you find yourself butting up against this scenario, however, I would encourage you to examine why you’re using Method#to_proc and instance_eval together in the first place.

30 Days of Tech: Day 18 - Ajax Defined JS

2008-06-19T03:56:00Z

If you’re using prototype.js for Ajax and updating your page with HTML that defines new javascript functions, you’re likely to encounter issues. One solution is to pull the function definitions out of the HTML to a javascript file that is loaded when the page first loads. More often than not this is the correct solution. However, understanding the problem is quite instructive and leads to another solution that can be used in a pinch when pulling the function out is not an option. ...

To set the stage, let’s suppose we have a Rails application with a view that has a button. When that button is clicked, an Ajax request is made that results in another button being added to the page. The new button, in turn, triggers a call to a javascript function that happens to also be defined in the response to the Ajax request. Let’s see what happens…

index.rhtml:


  <html>
    <head>
      <%= javascript_include_tag :defaults %>
    </head>
    <body>
      <h1>Click the Button!</h1>

      <button onclick="<%= remote_function :url => {:action => 'new_button'},
                                           :update => 'new_button_target' %>">
        Get New Button
      </button>

      <div id="new_button_target"></div>
    </body>
  </html>

new_button.rhtml:


  <h2>Here's a new button!</h2>

  <script type="text/javascript">
    function prove_function_defined() {
      alert("You called?");
    }
  </script>
  <button onclick="prove_function_defined()">Call Function</button>

Loading the index page in Safari we see what we expect:

Clicking the button seems to work fine too:

But when we click the new button we get no alert. Instead we get this:

Usually the first reaction here is to assume that the javascript in the Ajax response is never evaluated. Unfortunately the problem isn’t so simple. We can prove the javascript is evaluated by adding a simple alert.


  ...
  <script type="text/javascript">
    alert("Really, I'm getting defined!");
    function prove_function_defined() {
      alert("You called?");
    }
  </script>
 ...

Now when we click the “Get New Button” button an alert is shown:

The function definition directly follows the alert that shows up, so the function must be getting defined. If so, where is it? We already know it isn’t directly accessible from the onclick on our button. If we dig far enough down into prototype.js, we find that the answer lies in how the javascript from the Ajax response is evaluated.


  Element.Methods = {
    ... 
    update: function(element, content) {
      ...
      element.innerHTML = content.stripScripts();
      content.evalScripts.bind(content).defer();
      ...
    },
    ..
  };

The update function here is the function that prototype calls to update the new_button_target div in index.rhtml. I’ve eliminated the irrelevant parts here to highlight the two lines that matter. Prototype strips out the script tags before setting the innerHTML property of the element. It then sets a timeout (the call to defer) causing the browser to invoke the evalScripts function a little later and continues on it’s merry way. So to understand where our function is being defined, we need to look at evalScripts.


  evalScripts: function() {
    return this.extractScripts().map(function(script) { return eval(script) });
  }

evalScripts extracts the script tags from the html fragment and then calls eval on each one of them. Now we finally come to the crux of it—eval evaluates the script passed to it in the current context, which is within the evalScripts function. Unfortunately for us, javascript allows functions to be defined as part of the local scope of a another function, much like local variables. So our function is being defined, but local to a particular execution of evalScripts. As soon as evalScripts returns, our function is lost. Oh no!

This is where we would probably decide to just pull the function out of the HTML being rendered for the Ajax response and make sure it’s loaded when index.rhtml was loaded, but we might run into a situation where this is highly inconvenient. If we find ourselves in such a situation, we can use our knowledge of javascript functions, variables, and scopes to worm our way out. In javascript functions are nothing more than variables that hold function objects. In fact, the syntax for defining a function in javascript is little more than syntactic sugar. We could just as easily assign a variable to a function object ourselves. Furthermore, assignments within a function in javascript create a global variable if you do not include the var keyword, which would make it local. Therefore we can force our function to be defined globally simply by changing the code like this.


  ...
  <script type="text/javascript">
    prove_function_defined = function() {
      alert("You called?");
    }
  </script>
  ...

Now when we reload the index page, click on the first button and then the second we get the behavior we want!

Whew… all that javascript hurts my head. I’m going to go lay down for awhile. Have a good night!

30 Days of Tech: Day 17 - Nesting

2008-06-18T03:12:00Z

ruby-doc.org describes Module.nesting as “the list of Modules nested at the point of call.” What does this really mean? ...

ruby-doc.org describes Module.nesting as “the list of Modules nested at the point of call.” What does this really mean?


  $top_level_nesting = Module.nesting
  module M1
    $level_1_nesting = Module.nesting

    module M2
      $level_2_nesting = Module.nesting
    end
  end

  module M1::M2
    $re_opened_nesting = Module.nesting
  end

  global_variables.select {|v| v =~ /nesting/}.sort.each do |v|
    puts "#{v}: #{eval(v).inspect}" 
  end

Can you guess what this script outputs?


  $level_1_nesting: [M1]
  $level_2_nesting: [M1::M2, M1]
  $re_opened_nesting: [M1::M2]
  $top_level_nesting: []

In most of the cases it is straightforward, but $re_opened_nesting might surprise you. You’ve reopened the M2 module, which is was defined within M1, but the nesting doesn’t reflect this relationship. The reason is that the module was opened using M1::M2 as the module name, rather than reopening M1 and then reopening M2 from within M1. This point is perhaps more clear looking at this example.


  module M1
    module M2
    end
  end

  M3 = M1::M2
  M3.name #=> "M1::M2" 

  module M3
    Module.nesting #=> [M1::M2]
  end

In this case the module M1::M2 is assigned to a new constant M3 at the top level. This assignment does not change the identify of the module – the name is still M1::M2. When the module is reopened via the M3 constant, it’s more clear why there is only one entry in Module.nesting. When a module is opened using the module keyword, Ruby adds it to the current nesting list. It doesn’t matter whether the name that was originally used to define the module was nested under another module or not – it’s the use of the module keyword that causes the nesting to change.

Most of the time you won’t care about what Module.nesting is, but there is a case that really matters if you re-open classes and modules to add extensions or monkey patch code. When Ruby looks up the value of a constant, it uses the nesting to determine which constant to use.


  A = 1

  module M1
    A = 2

    module M2
      puts "A at #{Module.nesting.inspect}: #{A}" 
    end
  end

  module M1::M2
    puts "A at #{Module.nesting.inspect}: #{A}" 
  end

The output of the snippet above is


  A at [M1::M2, M1]: 2
  A at [M1::M2]: 1

You can see that there are two different constants called A, one nested inside M1 and one at the top level. When M1::M2 is reopened, one might expect the reference to A to evaluate to the value defined within M1, but instead the top level constant is used. If you ever encounter any unexpected effects dealing with constants when you’re reopening classes nested within modules, keep Module.nesting in mind and it may help you figure out what is going on.

30 Days of Tech: Day 16 - Line Animation

2008-06-17T03:10:00Z

Here’s a little something pulled out of one of my personal projects. It’s a class to help with single line animations on the command line. You construct it with an output device (something supporting <<, like STDOUT) and a list of objects (components). When you tell it to draw, it blanks out the current line and then draws it by converting the list of components to a string and writing it to the display. ...


  class LineDisplay
    def initialize(out, components)
      @out, @components = out, components
    end

    def draw
      @out << "\r" << " " * @current_length << "\r" if @current_length
      string = @components.join
      @current_length = string.length
      @out << string
      @out.flush
    end
  end

If you combine altering the components that the line display holds references to with calling draw repeatedly from a loop, you can perform a nice little animation, such as this


  class Spinner
    STATES = ["|", "/", "-", "\\"]

    def initialize(state, direction)
      @state, @direction = state, direction
    end

    def step
      @state = (@state + (1 * @direction)) % STATES.length
    end

    def to_s
      STATES[@state]
    end
  end

  components = []
  0.upto(3) do |starting_state|
    components << " " 
    components << Spinner.new(starting_state, 1)
  end

  components << " Weee!!!!" 

  3.downto(0) do |starting_state|
    components << " " 
    components << Spinner.new(starting_state, -1)
  end
  spinners = components.select {|o| Spinner === o}

  display = LineDisplay.new(STDOUT, components)

  loop do
    display.draw
    sleep 0.15
    spinners.each {|s| s.step}
  end

The last 5 lines of the code above are where the real magic happens. display.draw redraws the line, sleep pauses to control the animation framerate, and spinners.each {|s| s.step} makes the spinners spin! Put it all together and it looks something like this


   - \ | / Weee!!!! / | \ -

but more, well, animated. Try it for yourself!