Pry: A better Ruby REPL | Hacker News Reader

Pry: A better Ruby REPL

rdoc.info

131 pointsmileszs23 comments

Link to GitHub repo: https://github.com/banister/pry

People should know Pry is relatively new. We're actively writing code daily to improve it. We have some pretty awesome items on the TODO list, so keep an eye on it!

To answer an FAQ: There's no reason not to replace IRB with Pry, or at least extend IRB with Pry inside of your ~/.irbrc

The runtime invocation is particularly nice for live debugging. You navigate in and out of program scope (using cd) and view variables in scope (using ls). It is all very smalltalk-ish.

Just have the different scopes and contexts attached to windows, and have XCode-like "inspector" windows where every text field is effectively another REPL, and you'd just about have Smalltalk. Ruby already has most of the cool language/library constructs, plus an order of magnitude more (too much) syntax.

Do any of these IRB alternatives support multi-line history? I want to define a function, press up and have the whole function definition there instead of the last line of it -- how it works with Clojure's REPL.

Python's IDLE does this as well. It's hugely frustrating in other REPLs (irb, iPython) to type out a 5-line block only to find that you missed a keystroke on line 2. I'm hoping there's a keyboard shortcut I don't know about.

It does work in ipython it just is annoying to navigate and you have to rely on the automatic indenting a bit more if you are adding anything (as the ...: is missing).

Unless of course you mean history through different sessions as that doesn't work for full functions.

With IDLE a quick Ctrl-P will bring up the entire previous block input, including indents, all at once.

Indents are included with a simple up arrow with ipython, it also works if you are doing a backwards search (C-r), it just doesn't have the nice formatting you get when you first write the function.

Idle is a bit easier to edit the function though.

I just implemented it for ripl, http://github.com/cldwalker/ripl, in two ways: https://gist.github.com/939846. First way would put it in your history as a one-liner. The second would let you edit the last code block in your editor. The gist shows an example.

If you want to try this out, simply `gem install ripl ripl-multi_line` and add the gist to ~/.riplrc. Since this is a hack, I would open an issue on https://github.com/janlelis/ripl-multi_line/issues if you want it to be done properly.

If you were talking about using readline's multi-line history, I'm not sure if ruby's readline library has an api to it. Would be useful.

Hey, I've implemented it for the ripl multi_line plugin <https://github.com/janlelis/ripl-multi_line/>; (version 0.3.0).

You can change the behavior with the Ripl.config[:multi_line_history] option. Possible values: * :compact - transform the last statement into a ; separated one-liner * :block - just join the last multi-line statement to one block ("\n") * :blank - do nothing

For something much lighter (1/10th the size of pry) and less opinionated, see http://github.com/cldwalker/ripl. It's designed to be extendable and thus already has 20+plugins and 5 shells built on top of it.

Other irb alternatives to check out: https://github.com/raggi/ir, https://github.com/wycats/irb2, https://github.com/alloy/dietrb

Seems unnecessarily complicated. The whole point of IRB is to always be in Ruby mode. Being able to "drop down" into other out-of-band evaluation modes seems like a useful idea, but that's the exception, not the main use case.

So this looks less like a REPL than a gdb-like interactive debugging tool. But unless it can be used for attaching to and inspecting live running processes, it doesn't seem all that useful.

Indeed, it started out as a debugging tool. Weighing in at 2800 lines, it's going the way of irb, giving you a lot of functionality you may never use. For a more modular irb alternative, see http://github.com/cldwalker/ripl. To attach to live running processes, see https://github.com/ileitch/hijack

It's actually built for this purpose. It's not supposed to be anything like ripl is. I'd also recommend using that as a lightweight IRB alternative. But Pry isn't supposed to be that.

Also, Pry is currently weighing in at less than 2 thousand lines. It's not going the way IRB is going, but it is indeed very feature full, and probably will contain stuff you may not use every day. It's also easy to extend, so moving commands out of core and abstracting them into their own external libraries would be simple, would we ever want/need to slim the library.

$ wc -l lib/pry/*.rb | tail -1 -> 2801 total

I guess you're referring to lines of code. But if we're talking about that then you're actually pretty close to the original irb in size.

"It's also easy to extend, so moving commands out of core and abstracting them into their own external libraries would be simple"

Moving code around is simple yet pry's current extendability and abstraction is all of one plugin

Is being "large" and feature-rich a bad thing for a command-line tool? I don't want gems with unnecessary features bloating my projects, but I have no issue with feature-rich gems that help me develop more effectively, even if I don't use all of the features present.

It seems unnecessary features is in the eye of the beholder.

This thread is about pry. Don't you think three separate comments pimping ripl is a bit much?

Downvotes for pointing out a fact about pry's size, comparing it to a relevant project (one I've made) and pointing to additional info. Really HN?

Does it play nicely with an Emacs inferior mode?

If you turn off paging with `Pry.pager = false` it should work fine i think.

Doesn't Rubinius provide a lot of this?

Reply on news.ycombinator.com