
Pry: A better Ruby REPL - mileszs
http://rdoc.info/github/banister/pry/master/file/README.markdown
======
injekt
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

------
peterb
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.

~~~
stcredzero
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.

------
kzar
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.

~~~
cldwalker
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.

~~~
J-_-L
Hey, I've implemented it for the ripl multi_line plugin
<[https://github.com/janlelis/ripl-
multi_line/>](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

------
cldwalker
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.

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

------
lobster_johnson
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.

~~~
cldwalker
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>

~~~
injekt
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.

~~~
cldwalker
$ 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

------
jfb
Does it play nicely with an Emacs inferior mode?

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

------
qrush
Doesn't Rubinius provide a lot of this?

