You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pry has a command called play that evaluates code blocks within the context of the REPL. This is an extremely useful method for iterative development in the REPL.
When using IRB as an iterative development environment or as a debugger this is extremely helpful to evaluate the effects of code blocks without either restarting the program flow or copy and pasting long chunks of text into the REPL.
I was attempting to debug this method. I knew that my "starting_bigrams" were not correct, but I didn't really know why. I could step through each of these lines of code in the debugger, but making changes to the loop on lines 20-22 required me to restart the method each time.
Using play - I was able to stop the interpreter on the binding.pry - execute a modified version of the loop on lines 20-22 and then repeatedly play -l 24..27 to see what the outcome would be. Because play executes in the context of the REPL it is able to modify local variables and enables rapid, iterative piece-wise development without littering the code with puts statements or stepping through the code multiple times.
play -i 20 --lines 1..3 # assumes lines of the input expression at 20
play -o 4 # the output of an expression at 4
play Pry#repl -l 1..-1 # play the contents of Pry#repl method
play -e 2 # play from specified line until end of valid expression
play hello.rb # play a file
play Rakefile -l 5 # play line 5 of a file
play -d hi # play documentation of hi method
play hi --open # play hi method and leave it open
The play command in Pry has a whole lot of features, including playing snippets from other files, replaying literate documentation and connecting the inputs and outputs of expressions in code in REPL context. Most of these are predicated on the ability to load arbitrary code not via line input methods and replay it in the current context. Creating that capability I think would be sufficient for this use case - as well as giving us a feedback surface for further development.
The text was updated successfully, but these errors were encountered:
Thanks for the proposal 😄 But we don't simply replicate Pry's features to reach feature parity with it. Can you share a few of your use cases for this command? I assume you won't be using all of its variations?
Description
Pry has a command called
play
that evaluates code blocks within the context of the REPL. This is an extremely useful method for iterative development in the REPL.When using IRB as an iterative development environment or as a debugger this is extremely helpful to evaluate the effects of code blocks without either restarting the program flow or copy and pasting long chunks of text into the REPL.
play
command helpThe most useful part of
play
is the--lines
flag.play --lines 149..153 # assumes current context
For example a recent usecase for this.
I was attempting to debug this method. I knew that my "starting_bigrams" were not correct, but I didn't really know why. I could step through each of these lines of code in the debugger, but making changes to the loop on lines 20-22 required me to restart the method each time.
Using
play
- I was able to stop the interpreter on thebinding.pry
- execute a modified version of the loop on lines 20-22 and then repeatedlyplay -l 24..27
to see what the outcome would be. Becauseplay
executes in the context of the REPL it is able to modify local variables and enables rapid, iterative piece-wise development without littering the code withputs
statements or stepping through the code multiple times.The
play
command in Pry has a whole lot of features, including playing snippets from other files, replaying literate documentation and connecting the inputs and outputs of expressions in code in REPL context. Most of these are predicated on the ability to load arbitrary code not via line input methods and replay it in the current context. Creating that capability I think would be sufficient for this use case - as well as giving us a feedback surface for further development.The text was updated successfully, but these errors were encountered: