Skip to content

pry de

Jump to bottom Edit New page
rking edited this page Sep 23, 2012 · 77 revisions

pry-de

No, it's not a pry with sauerkraut: It's the Pry Development Environment, silly!

The Ideas

An editor is a good "home base" for traditional development, because the whole mentality is file-based storage and pre-compile-time editing. There is more information avialable at run-time, so (theoretically) it's a better place to do work. Pry is, as far as I know, the bleeding edge of run-time environments overlaid on top of file-based environments (that is, if you want the full force, try out Squeak — but Smalltalk is too radical, so people don't generally use it.)

  1. The runtime, compiletime, and edittime are all implementation details. It's just time, and the programmer should be free of the boundaries between them.
  2. The programmer and user roles are arbitrarily distinguished. There's just a machine and some people who work on it. Each person that touches the system should be able to add their own kind of value, and should be able to upstream that contribution.
  3. The tests and implementation are two sides of the same coin. Separating them is a mis-step.

The Task

The key elements seem to be:

  • Exception handling that brings you into the code rather than just quitting.
  • Interactivity so you can explore the API
  • Promotion so you can make temporary scraps become permanent on the filesystem, eventually to VCS.

It's about tightening feedback cycles: shortening the time between when you have a question and when you get the answer.

The Implementation

One important part is to integrate from the editor toward the REPL, e.g.:

  • emacs through Mon Ouïe's ruby-dev.el
  • vim
    • tslime.vim (for tmux) (See the ancestry here: slime.vim (for screen).)
      • Note: pry-de should include a vim file to be a better version of this.
    • Command to slurp some part of the tail of ~/.pry_history
      • '\pry-1' does the last one
      • '\pryh' brings up interactive prompt

The other way is to integrate the REPL toward the filesystem (and editor):

  • pry-de repo and gem v0.0.0.
  • The edit command needs to:
    • Tabcomplete filenames (done)
    • edit classes as well as methods (and give a good interface for when the class is scattered, i.e., reopoened or dynamically created somehow)
    • Somehow be test/spec-aware. Like edit -t SomeClass brings you to the spec for it. This might require a mapping somewhere. Or maybe it's time to start putting tests inline with the implementation?
  • save-source — a command to write REPL'd methods to disk. After you sketch out some code interactively it should be easy to attach that code as a method inside an actual file. (In fact, it should maybe be the default behavior of edit that it only works in a scrap space then syncs with the file. If you spend too much time camped out in the editor you lose the REPL power.) (Note: There is already the save-file command, which helps)
  • The ,e command:
    • ,,e added to the end of a line (like ? Foo.bar ,,e to act like edit-method Foo.bar (,, because it's a syntax error (thus clearly not Ruby), and easy to type.)
    • ,e by itself will have some context-sensitive semantics to complement edit -c
  • ,r will act like zsh's r: Repeating previous command. (done)
  • Rails optimizations
    • ,emodel ⇒ edit app/model/#{arg}
    • ,econtroller
    • ,a ⇒ "Alternate", hop from implementation to test/spec.
    • …Otherwise steal everything from rails-vim.
    • Note: The newer versions of the pry-rails gem have some cool commands:
      • show-models
      • show-routes (Note especially how it executes instantaneously (compared to the sluggish rake routes). This is because working at run-time ≡ winning.)
      • show-middleware
  • pry-debugger for stepping: added as dep, and short commands for each (done)
    • Make ,, shorten ,c ,s ,n to c s n * (done)
    • Also need a good way to start stepping when interactive. Currently I def xx; binding.pry; do_what_i_want_to_trace end; xx but it should be better. See: nixme/pry-debugger#14, where Banister said he has a local fix.
  • pry-stack_explorer, and pry-exception_explorer to make the runtime env more maneuverable. (done)
  • pry-git for git stuff.
    • These commands need more love. Will determine the missing bits soonish.
  • pry-vterm_aliases to reduce the need to drop back to the shell
  • pry-theme to homogenize syntax highlighting between REPL and text editor (e.g., the vim-default theme). (Done-ish. My new detailed.vim theme is on a solid start, but I need to update pry-themes vim-detailed to match)
The Loop --------

Making pry-de a reality should center around one, really solid develop workflow. What better than the "red/green/refactor" loop?

So, here's the idea:

  1. Install guard to watch the files
  2. Edit the test file in one window.
  3. Use something like pry-rescue with https://gist.github.com/8a9ea68a9988bde2b622
  4. Edit/save in the guard+pry window.
  5. try-again
  6. Exit and watch the tests all pass.
  7. (Refactor, somehow)
  8. Start again.

Troubles so far:

  • That gist's code only catches proper exceptions from within examples. Out-of-band stuff, like failure to require, escapes its grasp.
  • NoMethodError is treated as a plain exception. Would be nice if it started the "class Foo; def xyz; …" in the Pry input buffer.
  • We still don't have a good edit command, nor Pry.save, both of which would be huge wins, here.
  • Need a method like the Rails console's reload!. Sometimes edit doesn't know which you changed. Maybe some kind of pry_restart! to clear out everything except what's on the filesystem?
  • Guard has some odd interaction with readline/pry that I have yet to reliably replicate, but it requires a \stty echo`` to see what you're typing.
  • Need a part of ,e that knows about _ex_+pry-resuce, and does a try-again by default.
  • Maybe the "ran all tests successfully" step should kick you back into the implementation for a refactor step. I'm thinking this should happen either in Guard or the RSpec testrunner: https://github.com/guard/guard/issues/321

Solutions so far:

  • Installing pry-stack_explorer keeps spec failures from dropping you into the innards of the RSpec matcher.

Web Companion

pry-de could integrate with something like pry-mirror. This could allow for an easy upgrade of UI, such as hyperlinking, subdividing the screen, and graphics, but it could also have some killer use cases along the lines of rapidly developing views or AJAX code.

Education

Some of this stuff is simply a matter of teaching users how to use the Pry (and Ruby (and shell)) they already have.

For example, I at first thought we'd need something like shell's !$ expansion, but check out readline's excellent Alt+. (or Alt+Shift+_) binding to immediately insert the token from the previous line. (Note, this is possible with vi keys as well.)

For much of it, I imagine it should be upstreamed into pry itself, and the pry-de gem only being needed for bringing in some of the more intrusive/surprising bits (and also being useful to get the whole pack of dependencies in one shot).

The Standards

Factor (thanks, epitron!) http://youtu.be/f_0QlhYlS8g [TOWATCH]

  • Ctrl+w to start the current line in the "Walker", a step/next/etc debugger @5m15s
  • Everything is hyperlinked, e.g. they define factorial using an interesting [a,b] notation, but within the Walker you can click on it and see its defintion.
  • Ctrl+Shift+h gives help for previous token (note: not working for me IRL, it seems) @10m
  • [Lengthy description of the language itself, which is really cool, but not related to pry-de]
  • Ctrl+r to profile @51m30
  • Pausing at http://youtu.be/f_0QlhYlS8gk#t=1h

Also:

  • NoMethodError equivalents do some fuzzy-finding then offer you to pick one or defer definition.
  • F2 to refload all files

Smalltalk: Squeak and its fork Pharo (Pharocasts)

Common Lisp Exceptions

light-table has some good ideas

SLIME vid (150mb .mov)

  • First ~8 minutes: Cumbrous setup of Swank on remote machine, Slime on local machine
  • 8:23 */**/*** (like Pry's _/__/_out_[-2])
  • 'Output Presentations': Allow references to any value previously output by REPL
  • 9:25 Shortcuts: Get list by hitting , on empty line. Includes change-directory, change-package, help, etc. (Like Pry's commands)
  • 10:04 C-c C-d d = slime-describe-symbol. Like show-doc
  • 11:58 C-c C-d h = slime-hyperspec-lookup.
  • 12:45
    • C-M-x = slime-eval-defun, evaluate 'toplevel form'
    • C-x C-e = slime-eval-last-expression (evaluate form to left of cursor)
  • 13:49 - Slime selector
    • ? - help
    • c - "SLIME connections buffer" (?)
    • d - "*sldb* buffer for the current connection" (?)
    • e - most recently visited emacs-lisp-mode buffer (Like pry-de refactor or respec)
    • i - "*inferior-lisp* buffer" (?)
    • l - same as e but for lisp-mode instead of emacs-lisp-mode
    • r - SLIME REPL
    • s - *slime-scratch* buffer
    • t - "SLIME threads buffer" (?)
    • v - "*slime-events* buffer" (?)
    • n - "Cycle to the next Lisp connection" (?)
    • m - "First mrepl-buffer" (?)
  • (Pausing at 14:06 for now)
  • Slime has fuzzy symbol completion (optional)
An old Lisp machine, [Open Genera](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=30m) - The REPL responds to completed expressions instantly with an evaluation [@34m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=34m) - When prompted for a string type, you can click on the previously-displayed strings (and it's smart enough not to let you click on numbers, because the context is wrong) [@35m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=35m) - Keyboard lover's note: The mouse isn't necessary for this, you could just narrow the pool for tabcompletion. - The data display is nested (and zoomable) [@35m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=35m30s) - The objects update even if you go back in the history and change the values [@36m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=36m) - Fuzzy-finding [@37m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=37m) - Keyword context (like args completion) [@37m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=37m30s) - Mentions [CLIM](https://en.wikipedia.org/wiki/CLIM), a successor of the Symbolics machines. - Asynchronous output to terminal (and mostly nondisruptive, and optional even when they would be trouble) - Clickable pointers (zooming in) [@42m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=42m30s) - Interactive documentation, with a smartish tree context [@43m00s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=43m00s) - Runnable examples in docs [@45m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=45m) - Creating a record, getting an error — beginning of debug sequence [@45m35s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=45m35s) - Ctrl+b = backtrace, clickable. - Cool little scrollbar UI dotted line - "More interesting" backtrace [@47m45s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=47m45s) - Ctrl+e to hop to editor - Stack-down [@49m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=49m30s) - Pull up temp REPL while editing [@51m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=51m30s) - Holding down Ctrl makes the UI work charwise, instead of object-wise (like holding down Shift in a mouse-aware ncurses program) - Forgetting a paren, just to remind us he's using Lisp (though, he says the tools would have warned him if he had've taken a few more steps). - M-x start-patch (like commit+push with git) [@55m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=55m) - M-x start-private-patch (like local commit with git) - Using basic object display as GUI tool for commit task [@56m45s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=56m45s) - A mess+solution regarding Common Lisp namespacing. - Version control at the filesystem level. - Graphics output to console [@1h2m30s](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=1h2m30s) - Peeking into running process [@1h07m](https://docs.google.com/a/foo.com/file/d/0Bw4Wz8Ir0pl1cmNRaHYwdU1wdXM/preview?pli=1#t=1h07m)

Multiple views of a project (not restricted to a single, serialized organization):

Hopping around has to be as convenient (or more) than using:

We should be able to do everything we that we can currently do from vim/emacs/TextMate/etc., faster and with less distraction. (That "distraction" piece is why users click through inefficient menus with their mouse rather than learn the shortcuts — because the time it takes to stop and learn the efficient ways seems like too big a detraction from the current task. An example of what I mean by "with less distraction" is how you can exploratively Tab-complete things in Pry. You may not remember the method you're looking for, but after a few tabs you'll see it and remember without forgetting why you were headed there in the first place.)

The Future

Some things that might happen:

Add a custom footer
Add a custom sidebar
Clone this wiki locally