-
Notifications
You must be signed in to change notification settings - Fork 598
pry de
No, it's not a pry with sauerkraut: It's the Pry Development Environment, silly!
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.)
- The runtime, compiletime, and edittime are all implementation details. It's just time, and the programmer should be free of the boundaries between them.
- 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.
- The tests and implementation are two sides of the same coin. Separating them is a mis-step.
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.
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
-
tslime.vim (for tmux) (See the ancestry here: slime.vim (for screen).)
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 ofedit
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 thesave-file
command, which helps) - The
,e
command:-
,,e
added to the end of a line (like? Foo.bar ,,e
to act likeedit-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 complementedit -c
-
-
,r
will act like zsh'sr
: 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 sluggishrake 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
toc 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.
- Make
- 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-theme
svim-detailed
to match)
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:
- Install guard to watch the files
- Edit the test file in one window.
- Use something like pry-rescue with https://gist.github.com/8a9ea68a9988bde2b622
- Edit/save in the guard+pry window.
try-again
- Exit and watch the tests all pass.
- (Refactor, somehow)
- 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, norPry.save
, both of which would be huge wins, here. - Need a method like the Rails console's
reload!
. Sometimesedit
doesn't know which you changed. Maybe some kind ofpry_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 atry-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.
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.
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).
- IRT, which is this but for IRB: https://github.com/ddnexus/irt
- Must match the speed of test runs in this SublimeText demo. I have no idea how they're going so fast; I must be under-using Guard+Spork.
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)
light-table has some good ideas
SLIME vid (150mb .mov) [TOWATCH]
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):
- http://multiview.cs.pdx.edu/
- Charles Simonyi's work: http://www.edge.org/digerati/simonyi/simonyi_p2.html ; ftp://ftp.research.microsoft.com/pub/tr/tr-95-52.doc
Hopping around has to be as convenient (or more) than using:
- vim
- zsh with https://github.com/zsh-users/zaw
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.)
Some things that might happen:
- It could become standard practice to make processes have a pry-remote backdoor for debugging/runtime-feature-addition.
-
pry-exception_explorer
could be ready at all times, with an interface similar to the menu provided by thehammertime
gem. - Could drive more advanced terminal interaction, such as Termkit (or perhaps even use the gruesome w3m+xterm hack to display graphics.)
- epitron ideas:
-
Viewpoints Research Institute
- Especially STEPS, by Alan Kay
- http://chris.ill-logic.com/wiki/HCI/Speech_vs._Vision
- Brett Victor's recent talk about live programming (http://worrydream.com)
- Aza Raskin (Mozilla Labs)
- http://chris.ill-logic.com/wiki/HCI/Speech_vs._Vision
- http://www.cs.iastate.edu/~design/vmil/2011/papers/p02-kell.pdf
- http://arxiv.org/abs/q-alg/9705009
- Jaron Lanier
- http://subtextual.org/ especially http://subtextual.org/demo1.html
- live/metacoding - "a company built by charles simonyi, ex senior software architect at microsoft, working on making that easy intentional software (intentsoft.com)"
- Content Centric Networking | http://www.youtube.com/watch?v=gqGEMQveoqg
-
Viewpoints Research Institute