Dan Speaks

When your javascript unit tests contain an error JsUnitTest reports the error message but doesn’t show the stack trace. If you want to see the stack trace you can put this code somewhere (I suggest in the test that has the error):

JsUnitTest.Unit.Testcase.prototype.error = function(error, test) { throw error; }

It will stop the test run and pass the error to the browser. You can then view the stack trace in your browser development tool (eg FireBug).

After reboots ssh-agent stops remembering my password, leaving me to type it in everytime. Annoying since I made a really long password as per the suggested practice in most of the tutorials. I worked out that this had something to do with the fact that two ssh-agent process where running. The one I started explicitly as a cronjob on reboot and one that seems to have something to do with gnome. I turns out that the gnome one works just fine. I didn’t need to setup up my own so remove from cron, rm from .bashrc, ensure . ~/.ssh-agent does not happen anywhere, logout login and we are away.

this is one way. But if you have already done

wget http://..../rubygems-x.y.z.tgz
tar -xvf ...
cd ..
sudo ruby setup.rb

and you had previously been using the ubuntu rubygems from apt-get, then you will likely get this error:

uninitialized constant Gem::GemRunner (NameError)

Fix by

sudo rm /usr/bin/gem
sudo ln -s /usr/bin/gem1.8 /usr/bin/gem.
mv /var/lib/gem/1.8 /usr/lib/ruby/gem/1.8

Sometimes after apply updates to my ubuntu desktop via the package manager the nvidia driver seems to get ‘lost’. This article describes a solution. My variation on that theme is:

sudo aptitude search linux-restricted-modules

have a bit of a look at what is available. For me, this last time I needed:

sudo aptitude install linux-restricted-modules-2.6.22-15-generic

Then

 sudo apt-get install nvidia-glx

?

http://www.nvidia.com/Download/index.aspx?lang=en-us

download driver

stop x server

sudo /etc/init.d/gdm stop (for gnome)

sudo sh

start x server

sudo /etc/init.d/gdm start (for gnome)

UPDATE:
Everthing listed above is crap. The solution (thanks to PmDematagoda is

sudo vi /etc/default/linux-restricted-modules-common
...
  DISABLED_MODULES="nvidia_new nv"
...

restart

I’ve just run into a problem where I created an infinite loop by aliasing a method an then redefining the original method.

class String
  alias old_stem stem
  def stem
    # impl not shown
  end
end

If this code is run twice (most probably because the file is loaded twice) then the second time the alias will make old_stem refer to my new definition of stem, creating an infinite loop. Why was the file loaded twice? Because I had a (unnecessary) circle loop which meant that the file in question (’a') required file b; file b required file a via a different path (eg ‘foo/a’). Ruby require will reload the same file twice if they are referred to using different paths, even if the expanded path is the same (see ruby’s require doesn’t expand paths)

My solution in the case is to remove the circle loop as it was cruft that I should have already removed. A more general and explicit solution (courtesy of ruby forum) is:

alias_method(:link_to_original, :link_to) unless method_defined?(:link_to_original)

Jay Fields describes some interesting ways of redefining methods in Ruby. The last one was most interesting to me, particularly considering recent explorations into alternate mocking techniques. You can use this technique to redefine a method an then later reinstate the previous behaviour. Don’t know if it will ever be really useful, but I thought it was cool nevertheless.

class PrintHey
  def do
    puts "hey"
  end
end

PrintHey.new.do

unsuprisingly prints “hey”

module PrintDoDeeDo
  def do
    super
    puts "do dee do"
  end
end

extended_ph = PrintHey.new.extend(PrintDoDeeDo)
extended_ph.do

prints “hey”
“do dee do”

module Reinstate_PrintHey
  def do
    @print_hey_do ||= PrintHey.instance_method(:do).bind(self)
    @print_hey_do.call
  end
end

extended_ph.extend(Reinstate_PrintHey).do

prints “hey”. back to the original behaviour.

Yesterday I wanted to mock this method:

class HtmlFromUrl
  def get_page
    #download page from web
    ...
  end
end

It gets called here (in HtmlFromUrl.new):

class WebPage
  def html
    @html ||= HtmlFromUrl.new(url)
  end
end

I didn’t want to use a traditional mock object. I want to test that an object of the correct class was created in the ‘html’ method (this method is actually much more complicated than what is shown above) but I didn’t want to actually download a page from the web. This is the way I ended up doing this:

Object.mock(HtmlFromUrl, :get_page, %Q{"<html><head/><body><p>content</p></body></html>"})

and later

Object.unmock

This is the basis of the mock method
class Class
def mock(klass, method_name, new_method_body)
mock_class = Class.new(klass)
mock_class.class_eval(%Q{
def #{method_name.to_s}(*args)
#{new_method_body}
end})
set_constant(klass.name, mock_class)
end
end

The creates a new anonymous class that inherits from the class we wish to mock, defines the method that we want to mock and sets the old class constant name to refer to the new class. Seems to work pretty well, code and tests here

I switched over to ubuntu linux from windows xp about 6 months and soon after noticed a problem with VIM. The single repeat (”.”) command would not complete immediately. Instead it would take about 1 sec or until I pressed another key. A quick search for a solution turned up nothing; I decided that I would just put up with it…. until today.

Today I am going to fix it, my confidence is boosted after discovering this command

vim -N -u NONE -U NONE

which runs vim with out any .(g)vimrc customizations (or plugins) and

vim -V2

which runs in debug log mode. The problem does not occur when running vim -N -u NONE -U NONE but it does still occur when I run normal vim with all the lines in my .vimrc and .gvimrc commented out. So I guess the problem is in some plugin that I’ve installed….

Didn’t get anything particularly useful out Vim -V and tried to do some profiling using :prof start from within vim but this didn’t produce any output, I think that It might be more for plugin developers than plugin users. So I renamed ~/.vim/plugin; problem goes away! Turns out that a plugin that I don’t use, BlockComment uses .c and .C as commands. When I pressed ‘.’ BlockComment was forcing vim to wait for bit to see if a ‘c’ came along next. I think that its a pretty fucked way of doing things but I guess I you can’t really be too critical to someone putting their work out there for the benefit of the rest of us.

When I setup my linux box I went through a phase of just installing a bunch of plugins that sounded useful without really looking into them in too much depth (or even getting in the habit of using them). I’m going to be a bit more conscious of the plugins that I install in the future.

Previously I’ve run into problems subclassing ruby strings. This time its arrays. In both cases the root of the problem is that some methods for built in classes create new objects or object duplicates and the class of these objects is not always what you would like them to be. In the case of arrays the ‘[]’ method returns a new object of the same class with the selected elements. Normally the object will be of the class ‘Array’ but the object is a subclass of Array then the new object’s class will be this subclass. However, when the object is created the normal initializer is not called. This means that any instance variables the subclass may define are set to nil. This can lead to unexpected results. The solution is to redefine the ‘[]’ method in any Array subclasses that contain instance variables:

class MyArray < Array
  attr_reader :label
  def initialize(label, array=[])
    super(array)
    @label = label
  end

  def [](first, size=nil)
      return super(first) if size == nil
      self.class.new(label, Array.new(super(first, size)))
  end
end

An alternative is to just return an array:

  def [](first, size=nil)
      return super(first) if size == nil
      Array.new(super(first, size))
  end

The “class << self" idiom in ruby creates a special metaclass for the current class. The data held in the instance variables defined within this metaclass is not shared by subclass of the current class. If you want to share data between sub and super classes use a @@ variable.

 class A
    class << self
      def set_value(v)
        @value = v
      end

      def value
        @value
      end
    end
  end

  class B < A
    set_value(5)
  end

  class C < B
  end

  puts B.value
      > ‘5′
  puts C.value
      > ‘nil’

whereas

 class A
    @@value = nil

    class << self
      def set_value(v)
        @@value = v
      end

      def value
        @@value
      end
    end
  end

  class B < A
    set_value(5)
  end

  class C < B
  end

 puts B.value
     > ‘5′
  puts C.value
      > ‘5′