[original text](http://blogger.godfat.org/2011/02/ripl-rc-1-ripl-irb-replacement.html) # ripl, an irb replacement

TL;DR: see the comparison table/list on the bottom of this post. Still TL;DR?

> gem install ripl
> ripl rc

Use it in rails console?

> gem install ripl-rails
> ripl rc rails

# ripl Days ago when I was using pry to debug heroku-scaler, (which is a ramaze and em-http-request application), I wanted to make pry use irb history to easy debugging, and then I found it was talking about something like pry is not an irb replacement, to find an irb replacement, see ripl. That's where I started playing around with ripl. At first, I didn't think I need an replacement for irb, because it worked for me. But as always, we don't know if we need a better tool until we're really using a better tool. ripl is this kind of story for me, and so do yard to rdoc and so on so forth. Interestingly, this is not always true for all tools. For example, I like rake better than thor (though I didn't really try thor), and didn't really need the power of erubis over erb. One can think that, using thor/erubis might force others to do the same (though erubis could be used as a drop-in replacement for erb), but irb/ripl is just a personal tool instead of really a library that once you used it in the application, all developers would be forced to use or test against it, too. Just like a text editor. Personal taste only.. Back to topic... So what would we benefit from switching irb to ripl? If we're only using the core functionality of ripl, then not even talking about gains, but we'll lose some features that irb provides but ripl doesn't. What good is, according to the README of ripl, the code size was about ~270 lines vs 5,000+ lines, so we can expect that ripl is a lot easier to extend and customize, and this is also a fact. ripl is designed to be extended and customized from the beginning, and since the code is very modular and lightweight, it's very easy to replicate irb's behavior and features that are missing in ripl. You can take a look at ripl-irb. It might grow to be fat after installing many plugins and extensions, but I guess it will never reach the size of irb, since irb *has its own ruby parser*... ripl-multi_line uses a trick that catches syntax error exception to achieve multiline support. This might be tricky because it depends on the error message coming from syntax error; however irb's own ruby parser might not be accurate as well... as long as it's not using ruby's own parser. At first I was trying to add some simple patches with only a few of lines to the core of ripl to make it better, but the author only accepted my bug fix patches instead of features patches, even it's only a few of lines and I don't see why others won't want that features. Sometimes this make me feel like vim or bash, you'll definitely want some personal (might not be so personal though) config files instead of using the defaults, which is very different than GUI applications, which always try to provide the best defaults. I think both have their strength, and I don't mind as long as it could be customized to suit my flavor, and that's why I've written ripl-rc. ripl-rc is a ripl plugins collection, each of its require is a different plugin. For example:

require 'ripl/rc/color'
require 'ripl/rc/anchor'

The first line would enable colorizing plugin, and the latter would enable pry session like plugin. The reason I do this instead of releasing ripl-color, ripl-anchor, etc., is I think it's a lot easier to maintain and install as a plugin collection, since each plugin has only a few of codes. We can take advantage of fixing plugins at the same time, too, since some plugins would work with other plugins. (e.g. ripl/rc/anchor and ripl/rc/color) It would be tedious for users and developers to release or update a bunch of new releases... I really hate rails doing that, though the code base is not the same level. It might be a must for rails somehow... Enough of rubbish, let's see the comparison. # Comparison ripl has: * a lot fewer codes and is a lot easier to customize * better auto-complete (from bond) irb has: * multiline support (ripl uses ripl-multi_line) * subsessions and workspaces (actually I don't know what are they, never used. ripl uses ripl-commands) ripl-rc has, upon session ends: * require 'ripl/rc/squeeze_history' which squeezes the same input in history, both in memory and history file. * require 'ripl/rc/mkdir_history' which calls `mkdir -p` on directory which contains history file. For example, I put my irb_history in an directory might not exist before use: `~/.config/irb/irb_history` * require 'ripl/rc/ctrld_newline' ruby 1.9.2 has no this problem in irb, but 1.8 and ripl do. When hitting ctrl+d to exit ripl, it would print a newline instead of messing up with shell prompt. upon formatting output: * require 'ripl/rc/strip_backtrace' ripl prints the full backtrace upon exceptions, even the exceptions come from interactive environment, making it very verbose. This ripl plugin strips those backtrace. * require 'ripl/rc/color' There's ripl-color_result that make use of awesome_print, coderay, or wirb. The problem of awesome_print is it's too awesome and too verbose, and the problem of coderay and wirb is that they are both parser based. In ripl, this should be as simple as just print different colors upon different objects, instead of inspecting it and parsing it. ripl/rc/color just uses a hash with Class to color mapping to pick up which color should be used upon a ruby object. To customize the color schema, inspect `Ripl.config[:rc_color]` upon input: * require 'ripl/rc/multiline' I need some modification on ripl-multi_line to make prompt work better, but not sure if I can come up a good fix and try to convince the author to accept those patches. So I just bundle and maintain it on my own. If you're using ripl-rc, you could use this plugin, otherwise, keep using ripl-multi_line. * require 'ripl/rc/eat_whites' irb will just give you another prompt upon an empty input, while ripl would show you that your input is nil. I don't like this, because sometimes I'll keep hitting enter to separate between inspects. This plugin would skip inspect if the input is empty just like irb. special tool: * require 'ripl/rc/anchor' So this is my attempt to emulate pry in ripl. Instead trying to make pry support irb_history, colorizing, etc., I think implement pry like feature in ripl is a lot easier. No need to be fancy, I just need the basic functionality. To use it, use:

Ripl.anchor your_object_want_to_be_viewed_as_self

Ripl.anchor binding

in your code. Other than pry ripl support, you might be interested in ripl-rails and ripl-hijack, too. about config: * require 'ripl/rc/noirbrc' By default ripl is reading `~/.irbrc`. I don't think this is what people still using irb would want, because the configuration is totally different. This suppress that, make it only read `~/.riplrc` for lazies: * require 'ripl/rc' This requires anything above for you, and is what `ripl rc` and `ripl rc rails` shell commands did. So that's all at the moment for ripl-rc 0.1.3. Enjoy, 2010-02-28 (16:36~21:49)