5 ms·
Pry: A better Ruby REPL
- peterb 15y agoThe 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 15y agoJust 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.
- injekt 15y agoLink to GitHub repo: https://github.com/banister/pry 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
- lobster_johnson 15y agoSeems 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 15y agoIndeed, 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 http://github.com/cldwalker/ripl. To attach to live running processes, see https://github.com/ileitch/hijack https://github.com/ileitch/hijack
- injekt 15y agoIt'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 15y ago$ 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
- adriand 15y agoIs 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.
- cldwalker 15y agoIt seems unnecessary features is in the eye of the beholder.
- xiaoma 15y agoThis thread is about pry. Don't you think three separate comments pimping ripl is a bit much?
- cldwalker 15y agoDownvotes 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?
- qrush 15y agoDoesn't Rubinius provide a lot of this?
- cldwalker 15y agoFor something much lighter (1/10th the size of pry) and less opinionated, see http://github.com/cldwalker/ripl 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 15y agoOther irb alternatives to check out: https://github.com/raggi/ir https://github.com/raggi/ir, https://github.com/wycats/irb2 https://github.com/wycats/irb2, https://github.com/alloy/dietrb https://github.com/alloy/dietrb
- jfb 15y agoDoes it play nicely with an Emacs inferior mode?
- banister 15y agoIf you turn off paging with `Pry.pager = false` it should work fine i think.
- deleted 15y ago[deleted]
- kzar 15y agoDo 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.
- dpritchett 15y agoPython'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.
- wewyor 15y agoIt 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.
- dpritchett 15y agoWith IDLE a quick Ctrl-P will bring up the entire previous block input, including indents, all at once.
- wewyor 15y agoIndents 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.
- cldwalker 15y agoI just implemented it for ripl, http://github.com/cldwalker/ripl http://github.com/cldwalker/ripl, in two ways: https://gist.github.com/939846 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 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.