Speeding up firewatir

My recent work is pure ajax single-page application. And now I'm trying to cover it with some tests. Yes, I'm not TDD-infected, but that's a story for another post. And I've tried Firewatir. I quickly encountered it's known issue of being slow sometimes.

After a bit of investigation it turned out to be lack of TCP_NODELAY on both sides of firefox control socket. It's surprisingly typical that programmers are not aware that Naggle's algorithm affects localhost-to-localhost sockets too. In this case short requests and responses were unnecessarily delayed in kernel because of that.

The most interesting thing was fixing this issue. It seems that (re)building JSSh extension that is firefox side of Firewatir power is not very convenient and quick process. So I made a funny hack instead.

In one of my earlier posts I described a piece of code that drives GDB from ruby to get backtrace from running ruby process. This time I decided to use same approach to set TCP_NODELAY on connected socket inside running firefox process. I extended old code and published it at http://github.com/alk/alk-ruby-gdb-hacks/blob/master/gdb.rb. After creating Firewatir instance you simply need to call
GDB.force_socket_nodelay($jssh_socket)


On biggest numbers

There's a quite long, but very interesting essay on big numbers. Here:

http://www.scottaaronson.com/writings/bignumbers.html.

Author describes math competition to write down a representation of as big as possible number in 30 seconds. It's quite interesting thing to read as it stretches your imagination.

The biggest joy was to read about 'Busy Beaver' numbers. Those are amazing. But there's one mistake IMO. While it's possible to prove that busy beaver numbers sequence grows faster than any other computable sequence, it doesn't let you win biggest number competition. It only says that for each 'opponent' sequence there exists some number N starting from which Busy Beaver sequence will be greater than that sequence. And you will still need to prove, that, say busy beaver sequence number 1111 is greater than Ackermann's number 1111. For example BB(4) is only 107, while Ackermann's 4th number is quite large - around 10E154.

It may be quite tricky to judge such competition. For estimating largest entries we can use floating point numbers for computation, but it seems that we can easily meet such big entrants that resulting floating point mantissa representation will exceed available computer memory! So we may need to use floating point number approximation for mantissas! It's not hard to imagine yet another level of floating approximation of mantissas.

Computation time can also be challenging and may require special methods. How about estimating A(1E1111) ? My math skills and available computation facilities do not allow me to get even estimation of that number in my entire lifetime. But it should be truly huge number.