> I don't know how I'd have managed without vim + vim-slime.
This is interesting -- I've worked with people who swear by common lisp, emacs, and SLIME.
I'm happiest with ruby and vim, but I have not tried vim-slime (nor even heard of it before, so thank you!).
But FWIW, my strategy for running larger bits of ad hoc code on the ruby/rails console is to:
1. Add the code to a persistent local file (e.g. "ops_console_tools.rb")
2. scp the file up to the target machine where I am running the irb/pry console
3. In the console, run `load '/PATH/TO/ops_console_tools.rb'`
4. Run the new code: `Ops::User::CustomReport.run(90.days.ago..)`
To keep things a bit more sane, all of the ad hoc ruby code is in modules, e.g. `Ops::User`.
And it helps to include some code to clear constant definitions which would otherwise complain to STDERR if you update and reload the file multiple times.
None of this is as awesome as SLIME of course, but it's pretty tolerable with a bit of readline-style up-arrow and command-history conveniences.
Disclaimer: Of course, running ad hoc code in prod is frowned upon. But we're extolling the virtues of CL in this thread, so I'll confess to breaking best practices in environments where it's permissible! Also this process gives you syntax highlighting while editing without requiring config on target host, and you can include the file in version control for greater formality.
I replaced a similar workflow with SLIME-style `eval-defun` by just running the remote Ruby console within emacs, using inf-ruby. Combined with robe, you get code intelligence for free, but without the heavy and error-prone static indexing of Solargraph or Ruby-LSP.
This is interesting -- I've worked with people who swear by common lisp, emacs, and SLIME.
I'm happiest with ruby and vim, but I have not tried vim-slime (nor even heard of it before, so thank you!).
But FWIW, my strategy for running larger bits of ad hoc code on the ruby/rails console is to:
To keep things a bit more sane, all of the ad hoc ruby code is in modules, e.g. `Ops::User`.And it helps to include some code to clear constant definitions which would otherwise complain to STDERR if you update and reload the file multiple times.
None of this is as awesome as SLIME of course, but it's pretty tolerable with a bit of readline-style up-arrow and command-history conveniences.
Disclaimer: Of course, running ad hoc code in prod is frowned upon. But we're extolling the virtues of CL in this thread, so I'll confess to breaking best practices in environments where it's permissible! Also this process gives you syntax highlighting while editing without requiring config on target host, and you can include the file in version control for greater formality.