4 ms·

Do you mean you do all coding, including file saves in a REPL? Just trying to understand.

rezonant 3y ago
They explain elsewhere that they use an external editor, though they do sometimes use pry's builtin shortcuts and EDITOR convention integration to perform quick edits.
- vidarh 3y ago
  I'll note an additional take on this, represented by my editor to illustrate just how far down the rabbit hole this goes with Ruby: My editor is in Ruby, and uses DrB to talk to the backend. It has a key combination to throw me into a pry prompt, and also throws me into a pry prompt if any exception is thrown. Since DrB will forward any exceptions during the execution of any messages (and here we really see the message passing bit - they are literally messages passed over a socket and via proxies that don't know what they mean) back to the client, this means that any exceptions in the server will throw me into a pry prompt where I can dynamically edit the code of the server process and continue execution. The server process holds the open buffers, and I can reattach to it, and thanks to that use of DrB I was able to switch to using my own editor day to day at a point where it was still wildly unstable without losing any data. Sometimes I'd edit the editor with itself while it was in a broken state, and reload the offending code to fix things and just keep working. With most other languages - with a few exceptions - I'd have to wait until I had something more finished and more stable to start using things. With Ruby I often feel comfortable with starting to use projects while they're still crash-prone and half-finished and lacking because it's so easy to metaphorically replace the engine in mid-flight.
  - rezonant 3y ago
    Fancy, custom editor or something that's out there?
    - vidarh 3y ago
      Very custom, to the point that the current iteration is dependent enough on a bunch of details of my environment (part of this is an ongoing drive towards minimalism - e.g. the editor doesn't know how to open files or select buffers or select themes; all of those things are delegated to scripts that currently use rofi) to the point I'm not convinced it'll even start on someone. I'm slowly cleaning it up to at least pretend it might work for someone else, but that means also deciding on a cleaner interface to the helper scripts so I don't have to package up my entire environment in one go. The beauty of the DrB part of it, though, is that the shell of that is very small: Just spawn a DrB server, spawn a client, and wrap the client in a begin/rescue block with binding.pry, and put any critical data on the server side. Suddenly your server-side is near crash-proof and your data much less likely to disappear. If you want an extra level of protection, run a threat on the server side to checkpoint the data regularly (I used to checkpoint it every 5 seconds at the start; it's now at around 5 minutes, which also means every buffer I've opened and not bothered to kill from the last 5-6 years are still accessible... I never bothered to add code to clean them up as they just don't take up much space)
vidarh 3y ago
You can do that. E.g. pry has an "edit [methodname]" command that will spawn $EDITOR. But I usually keep my editor in a different window and just call a "reload" method at the pry prompt where I've wrapped up the logic to reload the running code. Occasionally I may restart, if e.g. object state has changed enough, but this means that if I've set up a bunch of test data for example, and run into a bug, I can fix the bug, "reload", and the state of the running objects remain the same but the method will have updated and I can retry the same method call with the exact same object state.

They explain elsewhere that they use an external editor, though they do sometimes use pry's builtin shortcuts and EDITOR convention integration to perform quick edits.

vidarh 3y ago
I'll note an additional take on this, represented by my editor to illustrate just how far down the rabbit hole this goes with Ruby: My editor is in Ruby, and uses DrB to talk to the backend. It has a key combination to throw me into a pry prompt, and also throws me into a pry prompt if any exception is thrown. Since DrB will forward any exceptions during the execution of any messages (and here we really see the message passing bit - they are literally messages passed over a socket and via proxies that don't know what they mean) back to the client, this means that any exceptions in the server will throw me into a pry prompt where I can dynamically edit the code of the server process and continue execution. The server process holds the open buffers, and I can reattach to it, and thanks to that use of DrB I was able to switch to using my own editor day to day at a point where it was still wildly unstable without losing any data. Sometimes I'd edit the editor with itself while it was in a broken state, and reload the offending code to fix things and just keep working. With most other languages - with a few exceptions - I'd have to wait until I had something more finished and more stable to start using things. With Ruby I often feel comfortable with starting to use projects while they're still crash-prone and half-finished and lacking because it's so easy to metaphorically replace the engine in mid-flight.
- rezonant 3y ago
  Fancy, custom editor or something that's out there?
  - vidarh 3y ago
    Very custom, to the point that the current iteration is dependent enough on a bunch of details of my environment (part of this is an ongoing drive towards minimalism - e.g. the editor doesn't know how to open files or select buffers or select themes; all of those things are delegated to scripts that currently use rofi) to the point I'm not convinced it'll even start on someone. I'm slowly cleaning it up to at least pretend it might work for someone else, but that means also deciding on a cleaner interface to the helper scripts so I don't have to package up my entire environment in one go. The beauty of the DrB part of it, though, is that the shell of that is very small: Just spawn a DrB server, spawn a client, and wrap the client in a begin/rescue block with binding.pry, and put any critical data on the server side. Suddenly your server-side is near crash-proof and your data much less likely to disappear. If you want an extra level of protection, run a threat on the server side to checkpoint the data regularly (I used to checkpoint it every 5 seconds at the start; it's now at around 5 minutes, which also means every buffer I've opened and not bothered to kill from the last 5-6 years are still accessible... I never bothered to add code to clean them up as they just don't take up much space)

vidarh 3y ago

You can do that. E.g. pry has an "edit [methodname]" command that will spawn $EDITOR. But I usually keep my editor in a different window and just call a "reload" method at the pry prompt where I've wrapped up the logic to reload the running code. Occasionally I may restart, if e.g. object state has changed enough, but this means that if I've set up a bunch of test data for example, and run into a bug, I can fix the bug, "reload", and the state of the running objects remain the same but the method will have updated and I can retry the same method call with the exact same object state.