Skip to content

pry de

Jump to bottom Edit New page
rking edited this page Sep 24, 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 'top-level form'
    • C-x C-e = slime-eval-last-expression (evaluate form to left of cursor)
    • 17:16 C-c C-c Sends top-level form to SLIME, but don't show expression result

  • 13:49 - Slime selector

    • ? - help
    • c - "SLIME connections buffer" (you can connect to several lisps at once. I think that's what this is.)
    • d - *sldb* (debugger) buffer for the current connection
    • e - most recently visited emacs-lisp-mode buffer (jumps back to code; ike 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" (?)

  • 14:20 change-package (like Pry's cd?)

  • 15:17 Typing function name gives signature for lambda list (looks like method signature)

  • 17:05 C-M-q = indent-sexp (Like vim =)

  • 19:15 C-c C-k compiles whole file

  • 19:39 SLIME's completion. Is fuzzy with visible

  • 22:22 SLIME debugger.

    • Error message at top
    • "Restarts"
      • 0 aka a = Abort-restart (maybe like pry's restart ?)
      • 1 Exit debugger (maybe like pry's ^D)
      • it doesn't seem like there's something as cool as pry-rescue's try-again
    • Backtrace
      • Starts abbreviated, but has a --more-- link.
      • t = toggle details (shows locals, like pry-de's ,loc)
      • v = show-source (like pry's edit-method); creates an unfocused window with the buffer for the file with that code.

  • 25:42 - (declaim (optimize …)) - Adjusting compilation details for debugging.

  • 27:05 - Emacs tools for writing Lisp

    • Opens with automatic close (like vim's delimitMate)
    • A few text editing tricks, either not needed in Ruby or easily done with ruby.vim features.

  • 33:35 - Result of compilation with faults

    • Editor gets underlines with errors ← red, warnings ← orange, style warnings ← yellow.
    • Window below with result (is hyperlinked so following fault jumps to spot in editor buffer)
    • 35:49 Strategies for API discovery:
      • Hyperspec docs (C-c C-d h, above)
      • M-. = find definition, AKA "Meta-Point" (like pry's edit-method or $)
      • describe-symbol to look for macro docs
      • C-c RET = slime-macroexpand-1 (would be cool if we cold hack this in in Ruby. Not going to be as clean, but it could be possible to see increasing recursions of show-source, perhaps)

  • 37:40 - (require :asdf-install) (like gem install)

    • Does the cool installtion idiom where you get a prompt on a split $PATH, asking which of the pieces to use as the dest dir.
    • A GPG signature error occurs, and somehow the SLIME debugger knows to offer a skip-gpg-check Restart in addition to the "Abort" and "Exit" of before. Maybe pry should have an error handling framework that acts similarly.

  • 39:00 - Package description via SLIME inspector (similar to inspecting a Gem::Specification - note that this is an example of the kind of thing where Ruby code works almost as well as Pry commands. It isn't as polished, definitely not as obvious to people who don't know about the APIs, but also easy to implement as commands if we want, e.g. gem-spec treetop ⇒ output.puts Gem::Specification.find_by_name('treetop').to_yaml)

  • 45:17 - M-. (like show-source) works inside a line. This is trickier with the namespacing of Ruby. Poor man's fix is to just show a menu of all classes that implement the given message, and let the user show-source on the one that makes most sense.

  • 45:24 - C-c C-t - enables tracing on function, from editor buffer. (We need "pry-trace" first)

  • 47:32 - Recursive inspection (showing guts of a lambda. There is a way to do similar in pry, I think requiring ruby4ruby, so you can inspect blocks/Procs/etc.)

  • 48:18 - i - sldb-inspect-in-frame, evaluate in context of frame (like the way pry-stack\_explorer has always acted, letting you go up then run REPL code with the locals visibile like whereami shows)

  • 50:41 - C-c < - slime-list-callers - Reverse tags, like cscope. Really good to see this in a dynamic language — must figure out how they do it. I still picture tracing a live execution then using that list, but maybe there's a way to figure it out. Must test this slime-list-callers on some dynamically generated symbols to see if it handles these cases.

    • Both of these are hyperlinked to edit the files that own them. (I'm thinking of some list that commands can manage to be args for edit. So you could list through a query like this, then edit -f3 to get the 3rd on the list)

  • 51:54 - C-c > - slime-list-callees - List every function a function calls.

  • pry-de.vim could liberate vim from dead-coding tyranny, giving access to the live data:

    • the ruby process behind Pry should run detached from the REPL (like ruby-dev.el, probably using pry-remote-em)
    • then we do something like: Pry.config.editor += ' +let\ g:pry_de_proc='+$? if Pry.config.editor[/^vim/]

  • Definitely need a way to stuff REPL interaction into a test-after result. I think IRT has this going on.

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