Data Noise - Home

ruby-debug basics screencast

2007-05-10T04:59:00Z

Brian Donovan shows the basics of using ruby-debug. This is very nice addition to my already outdated tutorial. He also announced that his next screencast will cover debugging of a Rails application.

One the same note, the next version of Rails comes with the native ruby-debug support. The relevant changeset is here.

ruby-debug version 0.9.1 has been released!

2007-04-03T06:14:00Z

Installation

As usual:

    $ sudo gem in ruby-debug

Changes

This is mainly a maintenance release, which includes several important bugfixes related to frame calculations.

In particular,

Installation

As usual:

    $ sudo gem in ruby-debug

Changes

This is mainly a maintenance release, which includes several important bugfixes related to frame calculations.

In particular,

All native (implemented in C) methods that take a block will create a new frame. What that means is that in the following code in order to reach line 2:
```
1  (1..10).each do |i|
2    puts i
3  end
4  ...
```
you have to step into the each method. The next command will move you to line 4 skipping the block.
The next command is now 'true' step-over operation. Which means that in the following code:
```
1 def f; 1 end
2 def b; 2 end
3 f; b
4
```
if you are on line 3 you have to call next command twice in order to move to line 4.

Previous change has a subtle side effect when you are debugging ERB templates. You probably already know that you can do that, right? Just set a breakpoint somewhere in your template:

$ rdebug ./script/server 
./script/server:2 require File.dirname(__FILE__) + '/../config/boot'
[-3, 6] in ./script/server
   1  #!/usr/local/bin/ruby
=> 2  require File.dirname(__FILE__) + '/../config/boot'
   3  require 'commands/server'
(rdb:1) break list.rhtml:1
Set breakpoint 1 at list.rhtml:1


(rdb:1) cont
...
Breakpoint 1 at list.rhtml:1
script/../config/../app/views/bug/list.rhtml:1 <% @title = "Task List" -%>
[-4, 5] in script/../config/../app/views/bug/list.rhtml
=> 1  <% @title = "Task List" -%>
   2  <center>
   3  <% if @list_action and session['filter'] -%>
   4  <div id="filter">Applied filter:&nbsp;
   5  <select name="filters" onchange="javascript:filterChanged(this);">


(rdb:6) next
script/../config/../app/views/bug/list.rhtml:2 <center>
[-3, 6] in script/../config/../app/views/bug/list.rhtml
   1  <% @title = "Task List" -%>
=> 2  <center>
   3  <% if @list_action and session['filter'] -%>
   4  <div id="filter">Applied filter:&nbsp;
   5  <select name="filters" onchange="javascript:filterChanged(this);">
   6    <option value="all">-- Show All --</option>


(rdb:6) eval @title
"Task List"

and the debugger will stop at the first line of list.rhtml template file when Rails renders it.

Stepping through your template works relatively well. The only problem is that sometimes ERB generates several instructions for a single line of template code, so that you have to use next command several times in order to move to the next line. That is where you can find the force (+) modifier for step and next commands useful. What that means is that next+ and step+ commands will force the debugger to move to another line.

Disclaimer: If you find yourself debugging your templates too often, consider revisiting your development approach. Your code does not belong there. Also, Ruby provides top-of-the-art unit-test libraries for you. Use them!

And, finally, starting from this version you can pass the cont-inue command a numerical parameter which makes the debugger to continue until it reaches a specific line of code. This is sort of 'Run to Cursor' command found in modern GUI debuggers.

Enjoy.

acts_as_sphinx plugin

2007-03-23T06:39:00Z

We can't imagine a web site without at least a rudimentary search functionality. What a frustration when we shop for a particular product or looking for an answer on a community web site and can't find exactly what we are looking for. The search is the paramount for any online business. If a customer can't find a product she's looking for, she would go somewhere else and you lose a sale.

Unfortunately, most of the databases don't provide full-text search capabilities or provide a minimal support which is not enough in most of the cases.

There are several options for Ruby developer to choose from. First of all is wonderful Ferret. This library rocks! I've already written an article of how to use it to index your ri database. It provides a very reach API that is based on Apache Lucene library. And it is considered the one of the fastest implementations of IR library out there. So, if you really need to add a functionality that goes beyond plain search capabilities, like adding the highlighting to your search results, using a specific analyzer, or keeping the real data along with your index, you should definitely consider this library. The integration becomes even simpler, because of the work being done by Jens Kramer with his acts_as_ferret plugin. There is also very informative and detailed article by guys from RailsEnvy blog.

But there is another solution for the same problem and, from my prospective, it is much easier to use and install.

Introducing sphinx

Sphinx is being developed by a Russian programmer Andrew Aksyonoff. It's a general purpose IR library. What makes it so special is the incredible, jaw-dropping speed of searching and indexing. There are several posts written by developers of MySQL Performance Blog that advertise sphinx as a powerful search engine software. In this post they describe how sphinx is being used in one of their commercial projects. I've been using it in one of my projects for several months already and it proved to be very fast and stable.

What makes it so fast, I think, besides of cause the genius of Andrew, is that sphinx provides the tradeoff of the available functionality in favor of speed. There is just not so much you can tweak with the provided API. But, mind you, the API covers more than 95% of all cases that you need for a general purpose search functionality required by most web sites. Also the latest versions come with the "extended" search mode, that moves this library closer to its competitors.

OK, in order to use it, you need to install it first. Let's see how we do it:

Installation procedure

You can download it from the Andrew's website.

$ wget http://www.sphinxsearch.com/downloads/sphinx-0.9.7-rc2.tar.gz

Use the standard installation procedure.
```
$ ./configure && make && sudo make install
```
By completing these steps you have installed three applications:
- searchd is a daemon process that serves incoming search requests.
- indexer is an application that builds your index.
- search is an application for testing your queries.
In order to make it all work you need to create a configuration file.

Sphinx configuration file

I'm going to demonstrate how to create an example configuration file based on a simple database called mydatabase that has two tables: products and brands. products table has a foreign key to brands table.

First of all, we define a data source for our index:

    source products
    {
        type                = mysql
        sql_host            = localhost
        sql_user            = root
        sql_pass            = myrootpwd
        sql_db              = mydatabase
        sql_sock            = /tmp/mysql.sock

        sql_query           = \
         SELECT products.id, products.name, brands.name, products.description \
         FROM products INNER JOIN brands ON products.brand_id = brands.id
    }

You can use either Mysql or Postgres databases. There is also an option to use plain files for your datasource, please refer to the sphinx documentation. The type parameter defines what type of the database you are using and the rest of sql_* parameters define how to access your database. The sql_query parameter provides a query which sphinx will be using for indexing. As you can see, our data has four fields. The first field must always be the document id, which sphinx returns as the result of a query. All other three fields will be used in your searches and you can assign a specific relevance weight to each of them.

Now we define our index itself:

    index products
    {
        source          = products
        path            = ../sphinx/products

        # morphology
        morphology          = stem_en
    }

Here we specify the data source for our index that we previously defined and where to store index files. Optionally, you can set several other attributes. Here, for example, I decided to use a particular morphology algorithm. For more options, consult the sphinx documentation.

In our last step, we provide options for the indexer application and searchd server:

    indexer
    {
        # memory limit
        mem_limit           = 32M
    }

    searchd
    {
        address             = 127.0.0.1
        port                = 3312
        log                 = ../log/searchd.log
        query_log           = ../log/searchd_query.log
        read_timeout        = 5
        max_children        = 30
        pid_file            = ../log/searchd.pid
        max_matches         = 1000
    }

These are more or less self-explanatory. You can find the whole configuration file here: sphinx.conf. Move this file to your <rails-app>/config directory.

Introducing acts_as_sphinx plugin

You can install this plugin by running this command from the top directory of your Rails application:

    $ ./script/plugin install http://svn.datanoise.com/acts_as_sphinx

This plugin extends your ActiveRecord model classes by adding sphinx search methods. This plugin uses sphinx.rb API library developed by Dmytro Shteflyuk that now is included with the sphinx package. Read Dmytro's post for more details about it.

Here is how you use this plugin:

We create a model class for each of our tables:

$ ./script/generate model product
$ ./script/generate model brand

Since we defined products index in our configuration file, we are going to extend the corresponding Product model. Open app/model/product.rb and modify it as follows:
```
class Product < ActiveRecord::Base
   belongs_to :brand
   acts_as_sphinx
end
```
acts_as_sphinx macro modifies our Product class and introduces two methods: Product.ask_sphinx and Product.find_with_sphinx. By default, it uses the name of the table associated with the model class as the name of the index. So in this case, Product.find_with_sphinx will be using our products index. Refer to acts_as_sphinx source code for the detailed documentation of these methods.
Now we need to prepare our index data. acts_as_sphinx introduces several rake tasks in sphinx: namespace:
- sphinx:index - creates/rebuilds all indexes defined in <rails-app>/config/sphinx.conf file. Note that searchd daemon must be stopped when you run this task!
- sphinx:start - starts searchd daemon using settings from <rails-app>/config/sphinx.conf file
- sphinx:stop - stops searchd daemon
- sphinx:rotate - rebuilds all indexes and sends searchd daemon a signal to read new index files. Note that searchd must be running when using this task!
This way, in order to build our initial index data, we use these commands:
```
$ make sphinx
$ rake sphinx:index
```
OK, we are ready to start sphinx server:
```
$ rake sphinx:start
```

Now let's test our new search engine:

$ ./script/console
>> res = Product.find_with_sphinx 'ipod'
=> ...
>> res.total
=> 3
>> res.time
=> "0.00"

Basic query functionality

find_with_sphinx method takes all parameters that you can pass to ActiveRecord::Base#find method plus a special :sphinx key. This key points to a hash of sphinx specific parameters. These are some of them:

:mode defines the search mode (:all, :any, :boolean, :extended)
:limit restricts result to a specified number of objects, default is 20
:offset returns results from a specific offset, default is 0
:page can be used instead of :offset option to specify the page number
:index overrides the default index name
:weight is an array of weights for each index component (used in the relevance algorithm)

For example, to make product and brand names more preferable than the product description:

    Product.find_with_sphinx query, :sphinx => {:width => [100, 100, 50]}

Pagination with acts_as_sphinx

It's quite easy to use Rails pagination with this plugin. Following the example from acts_as_ferrent article:

add to your app/controllers/application.rb:

    PER_PAGE = 10 unless defined? PER_PAGE

    def pages_for(size, options = {})
      default_options = {:per_page => PER_PAGE}
      options = default_options.merge(options)
      Paginator.new self, size, options[:per_page], (options[:page] || 1)
    end

add to app/controllers/product_controller.rb:

    @products = Product.find_with_sphinx query, :include => :brand,
      :sphinx => {:limit => PER_PAGE, :page => @page}
    @product_pages = pages_for @products.total, :page => @page

and you are good to go.

Index live updates

This is probably not a good idea to update your index on every change to your model objects. That's why acts_as_sphinx doesn't provide any callback methods. Instead, I would recommend to schedule your index updates once or several times a day depending on your needs. It all depends on your particular case, the size of your database, and the frequency of updates. If you have a huge database you can use main+delta update schema as described in the sphinx documentation. Personally I am using cron job to rotate my index every three hours using

    $ rake sphinx:rotate

command.

Also sphinx provides a very nice feature where you can partition your index and serve each part from a separate server. In order to query all this parts at the same time you define an index of a special distributed type. This way you can have the main infrequently modified index on one server and keep deltas on another. Once again, refer to the sphinx documentation for more information.

Conclusion

Sphinx library is a very powerful tool and useful addition to your website.

TextMate and Quick Searches

2007-03-19T18:16:00Z

I've been using TextMate since probably the first public version. At least my license dialog shows October 6th 2004, Serial Number #60. And, oh boy, I've been a happy user. I can't declare that this is the best editor out there, and I don't want to start another editor vs war. I've been using Vi(m)/emacs for such a long time that I can't even remember and I'm not going to give up on them just yet. But I can say that TextMate is definitely a unique piece of software that sets a high mark for other editors to follow.

I think the most innovative feature of this editor is the way it represents the document structure with scopes. Everything else is built around this structure: shortcuts, snippets, commands, code highlighting, etc. This very feature makes it so much easier to customize your editor, than anything I've seen so far. (Whatever I've tried I couldn't make mmm-mode package work for me).

Another thing that I'd love to have from any editor is a desktop integration. Don't get me wrong, I'm an avid terminal and CLI proponent, but I've access to the most powerful desktop out there and it would be sad if I can't enjoy it when I'm writing my documents. And TextMate allows me enjoying both of these worlds.

OK, enough of TextMate praises, there are still some areas where this editor needs some love. One of them is the search capability. The regular and incremental searches are fine, I'm talking about the Find in Project search. First of all, it's quite slow and it used to take a lot of your RAM. Second of all, I've found that in about 95% of all cases, I need to search in a particular directory of my project. So I did what everyone else does, I created my own command, which I am about to share with you.

Enjoy.

Entering fixtures with TextMate

2007-03-16T02:24:00Z

Probably the most boring task when writing Rails test cases is entering new fixtures. With a little help from TextMate this process can be made more pleasant.

Open Bundle Editor and create a new command.
Name it, for example, 'rails: new fixture'
Use this script as the command body:

Probably the most boring task when writing Rails test cases is entering new fixtures. With a little help from TextMate this process can be made more pleasant.

Open Bundle Editor and create a new command.
Name it, for example, 'rails: new fixture'

Use this script as the command body:

#!/usr/local/bin/ruby
require ENV['TM_SUPPORT_PATH'] + "/lib/exit_codes"
unless ENV['TM_FILEPATH'] =~ /\/test/
  TextMate.exit_show_tool_tip  "you're not in the context of a rails project"
  exit 1
else
  rails_dir = $`
  tbl_name = File.basename(ENV['TM_FILEPATH'], '.yml')
end


require 'rubygems'
require 'active_record'
eval "class #{tbl_name.classify} < ActiveRecord::Base; end", TOPLEVEL_BINDING
model = tbl_name.classify.constantize


conf = YAML.load(File.read(rails_dir + "/config/database.yml"))
db_conf = conf['development']
ActiveRecord::Base.establish_connection db_conf


unless model.table_exists?
  TextMate.exit_show_tool_tip  "there is no table called #{tbl_name}"
  exit 1
end


columns = model.columns.map{|clm| clm.name}
puts '${1:fixture_name}:'
idx = 2
columns.each do |c|
  puts "  #{c}: ${#{idx}}"
  idx += 1
end
puts '$0'

Use None for the Command Input
Use Insert as Snippet for the Command Output
Activation should be set to Tab Trigger with the fix as the activation sequence.
Source Selector must be set to source.yaml

Now, when the command is created, open your fixture file and enter fix followed by Tab key. TextMate will insert the template your new fixture with all column names specified. You can enter values for the first column and move to the next one by pressing Tab key.

ruby-debug version 0.8 has been released!

2007-03-15T20:17:00Z

This is mostly a maintenance release. The major change is that ruby-debug has been split in two parts:

ruby-debug-base gem contains the debugger core API written in C. Use this gem if you want to create your own interface to the debugger and don't want to depend on changes to the ruby-debug CLI. The API is considered somewhat stable.
ruby-debug gem depends on ruby-debug-base and provides CLI interface.

This is mostly a maintenance release. The major change is that ruby-debug has been split in two parts:

ruby-debug-base gem contains the debugger core API written in C. Use this gem if you want to create your own interface to the debugger and don't want to depend on changes to the ruby-debug CLI. The API is considered somewhat stable.
ruby-debug gem depends on ruby-debug-base and provides CLI interface.

The idea is that if you are working on an integration with ruby-debug and find that the command set provided by ruby-debug is too limited for your purposes, you create a new gem and make it depended on ruby-debug-base. The only requirement is that you provide and register Debugger.handler like so:

    class MyHandler
      def at_line(context, file, line)...

      def at_breakoint(context, breakpoint)...

      def at_catchpoint(context, exception)...

      def at_tracing(context, file, line)...
    end
    Debugger.handler = MyHandler.new

The handler implements four callback methods that are invoked by the debugger. Each method receives the current context (Debugger::Context) as the first parameters. Please refer to the rdoc bundled with ruby-debug-base gem for the description of debugger API and consider ruby-debug gem as an example of such interface implementation.

One interesting example of such alternative interfaces could be the DBGP protocol that is becoming common in the field of dynamic languages.

MacFuse and Ruby fusefs extension

2007-03-09T21:22:00Z

Lately I've been playing with MacFuse project and all I could say is that this is a fantastic effort of bringing the well-known user-space(fuse) file system to the OSX land. The latest versions of fuse work well with FreeBSD and MacFuse extends this functionality to OSX platform.

My goal was to make Ruby's fusefs extension play along with it. The major stumbling point was that MacFuse requires using the new fuse API, so I had to make several modifications to fusefs in order to make it possible at least to compile it.

OK. If you are a braveheart type and not afraid that it might damage your computer, these are the steps you need to do in order to install this extension:

Download the latest version of MacFuse and use the installer that it comes with.
Check out my version of fusefs from http://svn.datanoise.com/fusefs-osx and use the standard procedure of installing Ruby extensions:
```
$ svn co http://svn.datanoise.com/fusefs-osx
$ cd fusefs-osx
$ make
$ sudo make install
```

That's about it. Now you can start playing with examples located in <fusefs-osx>/sample directory. When you are at it, I'd like you to take a look at one of my personal toys - the remote DRb-based file system. It is located in <fusefs-osx>/sample/drb directory and that's how you use it:

On the remote side (a Windows box will do just fine) start the drb server:
```
$ ruby ./sample/drb/drbfs_server.rb ~/shared
druby://myhost:7777
```
The script takes the name of a directory you want to share. When the script is started, it'll print the URL you have to use when you mount your DRb filesystem on the client side.
On the client side, mount DRb file system:
```
$ ruby ./sample/drb/drbfs.rb mount/ druby://myhost:7777
$ ls mount
```
The client script takes the name of a directory you want to mount to and the URL of the server from the step one.

Enjoy and don't forget to read <fusefs-osx>/OSX.txt for the important API changes.

Conditional tail

2007-03-03T19:42:00Z

So many times while watching log files I wanted to find a command that combines tail with grep filtering functionally. The Unix command repository is huge and I'm pretty sure you can do it without resorting to a scripting language. But having spent several minutes googling for this functionality to no avail, I decided to bring Ruby to the rescue.

At first I thought that I had to port File::Tail Perl module to Ruby, but I found that it has been done already by Florian Frank. He has even provided a convenient way of installing it:

    $ sudo gem install file-tail

OK, the rest was as obvious as this:

    $ cat tailg
    #!/usr/bin/env ruby

    require 'rubygems'
    gem 'file-tail'
    require 'file/tail'


    if ARGV.size != 2
      $stderr.puts "Usage #$0 <regexp> <log-file>"
    end

    begin
      File.open(ARGV[1]) do |log|
        log.extend(File::Tail)
        log.interval = 2
        log.backward(10)
        log.tail { |line| puts line if line =~ /#{ARGV[0]}/ }
      end 
    rescue Exception
    end

    $./tailg 'products' /var/log/searchd_query.log
    [Sat Mar  3 13:39:40 2007] 0.000 sec [all/0/rel 3 (0,9)] [products] NOA
    [Sat Mar  3 13:39:44 2007] 0.000 sec [all/0/rel 22 (0,9)] [products] lauren
    [Sat Mar  3 13:40:09 2007] 0.000 sec [all/0/rel 22 (9,9)] [products] lauren

tailg command accepts two parameters: a regexp to filter for interesting lines and a log file itself.

ruby-debug 0.7 released

2007-02-02T05:46:00Z

I'm happy to announce that ruby-debug 0.7 is available now.

This is mostly a bugfix release. It also has many internal changes that greatly improve the debugger performance. It is so much faster now, that sometime I don't even notice that I'm using it when I start mongrel with rdebug script. The list of changes includes:

Frame class has been removed and instead a preallocated block of memory is used to keep frames information. This change has decreased the number of object being created.
Another major change involves the fact that the debugger by default doesn't create Binding object for each frame. This is a very expensive operation and it's been the major source of performance problems. Instead, ruby-debug keeps references to the live Ruby's data structures that store information about the local context (ruby_scope). It's still possible to restore the old behavior by using --keep-frame-binding option, or Debugger.keep_frame_binding = true.
New set command has been introduced. You can use help set command to see what options are available.

Enjoy, and please report any problem you find!

ruby-debug 0.6.1 Released

2007-01-27T05:08:00Z

ruby-debug 0.6.1 has been released!

    $ sudo gem install ruby-debug

ruby-debug is a C extension that implements the fast Ruby debugger.

Changes

Significant performance improvements.
Bug fixes.

Profiling with Shark

2007-01-27T04:47:56Z

Lately I ran into an article talking about a new Ruby debugger called Cylon. Developers of Sapphiresteel IDE have achieved remarkable results. The article stays that their debugger implementation imposes only 20% of an overhead over the standard Ruby interpreter. This is very impressive! I decided to try the same benchmark with ruby-debug and, to tell you the truth, I was kind of disappointed. It's time to profile...

I've read several articles describing Shark, the tool with comes with CHUD toolkit from Apple. I've never used it before, but I've heard that it's quite powerful tool.

First of all, I decided to use Rails application I've been working on lately as a test-bed for measuring the performance. I started it under ruby-debug using rdebug script:

    $ rdebug ./script/server

When my application was up and running I launched Shark.

Notice that on the main screen I selected my running ruby process from the dropdown menu. There are several profiles available, but the default Time Prifile is exactly what I needed. It's possible change several options in the config pane, but I decided that defaults would work for me well.

Then I simply pressed Start button and started using my application while Shark was sitting in the background collecting profiling information.

In thirty seconds Shark presented me with the following screen:

Well, that's nice. It loaded the symbol table successfully, and I can see the call stacks as well. At the bottom of the screen you can select top-down or bottom-up view. It just worked and it don't have to recompile my Ruby and ruby-debug with some special compiler directives or do some other magic.

But wait a minute, I didn't expect to see my debug_event_hook function somewhere at the bottom of the list. All I could see was memory management functions along with garbage_collect function. It means that there are a lot of objects being created somewhere, which triggers so much of a garbage collection overhead. Also I saw my lovely debug_event_hook function right there in the call stack of garbage_collect method.

Let's see if I can get more info about it. Right-clicked on debug_event_hook function and selected Focus Symbol debug_event_hook. Shark made my function the root of the call tree and removed call stacks that do not contain my function.

OK, that's better. Now I double-clicked on debug_event_hook function call stack and Shark displayed this screen:

Wow! Notice these two lines 522 and 523. I didn't expect that they are going to impose so much of a performance overhead. Now it's clear, there are too many String objects being created and most of the time these objects are not referenced after this function returns.

Ok, I started one of my favorite text editors and in a couple of hours and several similar iterations I've got this picture:

Now, this is much better! There is no garbage_collect in sight and most of the time debug_event_hook spends in searching for the current thread info. I could probably change the algorithm and data structure that I use in order to keep this information, but it's already good enough. Now my benchmarks show that instead of 300% of the overhead, ruby-debug imposes only 90%. It's still slower than Cylon though and it would be good to know about the implementation details of Cylon debugger.

When you are profiling, you need to know when to stop! And I'm going to repeat it: premature optimization is the root of all evil. It makes your code more obscure and should be used with discretion.

And the bottom line is. Shark is very powerful tool. It's free and very easy to use.

Post-mortem debugging

2006-12-20T22:38:00Z

ruby-debug 0.5.1 has been released! The installation as usual:

    $ sudo gem install ruby-debug

Below is the list of changes:

Post-mortem debugging

First of all, what the heck is post-mortem debugging? Let's say you run a script and instead of the expected result you get an exception trace. Wouldn't it be great if we can roll back to the point where this exception is raised and explore the state of your program (possibly, by moving up and down the frame stack)?

Note that it is different than setting a catch point. By setting a catch point you activate the debugger when an exception (of a specific class) is about to be raised and it doesn't matter whether it's going to be handled later in the code or not. In the post-mortem case you know that an exception's been raised and not handled as expected.

Now I'm going to demonstrate several ways of using this feature, starting from the simplest:

Using rdebug script

You run your application with rdebug and use -m command line option:

    # rdebug -m script_name

For example,

    $ cat t.rb 
    def t1
      raise 'test'
    end
    def t2
      t1
    end
    t2

    $ rdebug -m t.rb 
    ./t.rb:1: def t1
    (rdb:1) c
    ./t.rb:2: raise 'test'
    (rdb:post-mortem) l=
    [-3, 6] in ./t.rb
       1  def t1
    => 2    raise 'test'
       3  end
       4  def t2
       5    t1
       6  end
    (rdb:post-mortem)

Notice the new post-mortem prompt. It indicates that at this point you can't use any stepping commands other than [cont]inue. All other commands are still available, so you can [eval]uate an expression in this context, move up* and *down the stack, etc.

Explicit activation of post-mortem debugging

You can activate the post-mortem mode with Debugger.post_mortem method from your script:

    $ cat t.rb 
    require 'rubygems'
    require 'ruby-debug'

    Debugger.start
    Debugger.post_mortem

    def t1
      raise 'test'
    end
    def t2
      t1
    end
    t2

    $ ruby t.rb 
    t.rb:8: raise 'test'
    (rdb:post-mortem) l=
    [3, 12] in t.rb
       3  
       4  Debugger.start
       5  Debugger.post_mortem
       6  
       7  def t1
    => 8    raise 'test'
       9  end
       10  def t2
       11    t1
       12  end
    (rdb:post-mortem)

Note of caution: Debugger.post_mortem method installs a special at_exit hook. So if your application exits by calling Kernel#exit! method, the debugger is not activated! Be careful.

Local post-mortem debugging

All previous examples describe the case when an application exits without handling an exception. What happens if we've got a peculiar block of code that is not supposed to raise any exceptions, yet, contrary to all expectations, it still does. Debugger.post_mortem method accepts a block of code and activates the post-mortem mode when it executes it.

    $ cat t.rb 
    require 'rubygems'
    require 'ruby-debug'

    Debugger.start

    def t1
      raise 'test'
    end
    def t2
      t1
    end

    begin
      Debugger.post_mortem do
        t2
      end
    rescue
      debugger
      puts 'handled'
    end

    $ ruby t.rb 
    t.rb:7: raise 'test'
    (rdb:post-mortem) l=
    [2, 11] in t.rb
       2  require 'ruby-debug'
       3  
       4  Debugger.start
       5  
       6  def t1
    => 7    raise 'test'
       8  end
       9  def t2
       10    t1
       11  end
    (rdb:post-mortem) c
    t.rb:19: puts 'handled'
    (rdb:1) l=
    [14, 23] in t.rb
       14    Debugger.post_mortem do
       15      t2
       16    end
       17  rescue
       18    debugger
    => 19    puts 'handled'
       20  end
    (rdb:1) c
    handled

    $

Notice that the debugger is still activated when we finished with post-mortem breakpoint.

Source code reloading

Another feature that has been implemented in the latest versions is the source code reloading. This feature is very useful when you debug your Rails application in development mode. You start your application, you make some changes, you hit your browser's Refresh button and you are done with it. No need to restart your mongrel all the time.

So wouldn't it be nice if ruby-debug also be able to reflect all these code changes instead of displaying stale source code?

By entering reload command, you can instruct the debugger to refresh all source code it's aware of. You can also automate this process by using reload on command. In this case, the debugger will be checking the file timestamp and reload the file if it's been updated automatically.

New irb command (experimental)

Evan Weaver popped the question in his blog:

It would be nice to be able to drop into an IRB instance, too, but I don’t know how to do that.

Enter irb command - it activates an irb instance with the current frame's binding. This feature is somewhat experimental and is not available in remote mode. (I wasn't able to install my own input method in order to redirect standard IO).

That's it for now. Enjoy.

Google Calculator

2006-12-17T00:11:00Z

Google calculator is a very powerful tool. Besides basic arithmetic, you can use it in many other interesting ways. But I always wanted to use it from the command line without opening a new Safari window.

Ruby to the rescue:

    $ cat gcal 
    #!/usr/bin/env ruby
    %w(rubygems open-uri hpricot erb).each {|lib| require lib }
    doc = Hpricot(open("http://www.google.com/search?q=#{ERB::Util.u(ARGV*' ')}"))
    puts (doc/'/html/body/p/table/tr/td[3]/font/b').inner_text

    $ ./gcal 2^20
    2^20 = 1 048 576

    $ ./gcal 'sqrt(-1)'
    sqrt(-1) = i

    $ ./gcal 30 rubles in dollars
    30 Russian rubles = 1.1379844 U.S. dollars

    $ ./gcal 2 gallons in liters
    2 US gallons = 7.5708236 liters

It's not too bad for three-liner like this. By the way, did I say that Hpricot is awesome?

WS-*

2006-12-13T22:49:00Z

I've been dealing with SOAP/WSDL a lot lately, and this is beside trying to play a role of ActionWebService maintainer. There are several points to mention. First off, everyone wants to use SOAP no matter whether it makes sense or not. Not a single company I've worked with had a slightest idea of what SOAP/WSDL is. OK, I take it back. What a f*ing mess it is...

Anyway, I was quit pleasantly surprised today after reading this article at InfoQ. It means there are still some sane people left in WS-* crowd. Pete Lacey's The S stands for Simple only proves my point.

Also I'd like to thank NAKAMURA Hiroshi, the author of soap4r library. It is a tough job to live in the mess like this, and his library is the best one I know in the dynamic language landscape that provides a decent SOAP/WSDL implementation. He also praises ruby-debug as a quite useful tool for debugging soap4r applications! Very much appreciated.

Live Ruby process inspection

2006-09-23T15:23:00Z

OK, this is totally insane. First Jamis Buck hit us with Inspecting a live Ruby process article where he demonstrated a number of very interesting technics you can use in order to poke around your live Ruby process.

But then Mauricio Fernandez showed us how masters do their katas ( 型 ) in "Inspecting a live Ruby process", easier if you cheat.

I didn't know that gdb can be that powerful! I need to read more about it.

On a side note, I've just finished reading Scalable Internet Architectures by Theo Schlossnagle and I very enjoyed it. If you followed this interesting exchange of opinions, you should definitely read this book. The author make a clear point that the raw speed of your language of choice does not matter in creating scalable solutions. Even if your application is powered by C, you still can reach a point when your single server is not able to serve all incoming requests and you need to scale your application horizontally. This book explains how.

Next on my "to read" list is Building Scalable Web Sites by Cal Henderson.