Hijack: Get A Live IRB Prompt For Any Existing Ruby Process

This post is by Ari Brown from Ruby Inside

Click here to view on the original site: Original Post

jackSometimes taking an app down for debugging purposes is just not an option. Luckily a new tool called Hijack can provide a live IRB prompt for an existing Ruby process in the same way that Erlang provides hot swapping of code (changing the definition of a system while the system is still up and running).

Hijack (it’s still in a beta state, so be careful and don’t use it in production yet!) lets you to pry your way into a running Ruby process, where it drops you into a live IRB session running over DRB. Gone are the days of stopping live applications just to make a minor update!

Using the GDB (GNU DeBugger), Hijack connects to the running Ruby process, injecting a small payload to start a DRB session which provides an IRB session:

$ ruby hijack 16451
        => Hijacking...
        => Mirroring: 100%
        => Hijacked 16451 (my_script.rb) (ruby 1.8.7 [i686-darwin9])

You may already be familiar with live-console which provides a similar functionality. The key difference, however, is that Hijack can “inject” itself into an existing Ruby process without needing the code to have included it explicitly. Developer Ian Leitch explains:

I’ve just changed Hijack so that you can hijack any Ruby process – no need for your target process to require any code before it can be hijacked. It does this by first injecting a payload using gdb, then it signals the process to start up a DRb server which the hijack client then connects to.

jslab.pngJumpstart Lab is running a JavaScript Master Class for Javascript & UI programmers with Thomas Fuchs (Scriptaculous, Prototype Core) and Amy Hoy (UI Expert) on 9/12 in Washington, DC. Save 10% with code “rubyinside”!

SexpPath: A Ruby DSL for Pattern Matching S-Expressions

With people occasionally talking about “Code vs. Data”, it only makes sense that you should be able process over code as you would a string. Sexp Path is a code processing tool that allows you to search over and process Ruby code in the form of S-Expressions.

For those who don’t know, an S-Expression (or simply, a “sexp”) is an iterable way of representing code or data. Using Ryan Davis’ Parse Tree, you can parse Ruby files and process over them using Sexp Path. It’s a bit like┬álike XPath or regular expressions for your code.

The foundation of Sexp Path is the query, formed with Q?{ ... }, which is applied to the sexp via the / method. These methods can be chained, and the results processed via the each method. Using this as an example, Sexp Path also supports named captures like Q?{ s(:class, atom % 'class_name', _, _) } in line 16 so that the second atom is accessible via the class_name attribute in line 25.

The code is stored on GitHub. Unclear of where the project is headed, Adam Sanderson, the creator, encourages forking and feedback.