Issue #15778 has been updated by st0012 (Stan Lo).
What if we settle for an API and implement and test it first in the debug gem?
The `debug` gem already has a method `DEBUGGER__.capture_frames` that achieves something similar. But I agree with @Eregon on not using the `debug` gem for this: - Pulling the `debug` gem in means this the API won't be used and shaped for production use. - The `debug` gem causes side-effects upon required (e.g. new threads and TracePoints activated in the background). In some cases it changes applications' behaviours and breaks tests for example. You can see more related discussions in [this issue](https://github.com/ruby/debug/issues/797). - It's probably not a huge risk for most apps, but this is something we should avoid when possible. - Even without all these issues, it complicates `debug` gem's role and could complicate its maintenance. I know the proposal is just to experiment it in `debug` first, but the reality is that we can't make gems move away from a dependency easily. ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-101471 * Author: gsamokovarov (Genadi Samokovarov) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello, I'm the maintainer of the web-console (https://github.com/rails/web-console/) gem, where one of our features is to jump between the frames in which an error occurred. To accomplish this, I currently use the Debug Inspector CRuby API. I think we should expose this functionality in Rubyland, so tools like web-console don't need to resort to C code for this. This also makes it quite harder for me to support different implementations like JRuby or TruffleRuby as everyone is having a different way to create Ruby Binding objects that represent the frames. Here the API ideas: Add `Thread::Backtrace::Location#binding` method that can create a binding for a specific caller of the current frame. We can reuse the existing `Kernel.caller_locations` method to generate the array of `Thread::Backtrace::Location` objects. We can optionally have the `Kernel.caller_locations(debug: true)` argument if we cannot generate the bindings lazily on the VM that can instruct the VM to do the slower operation. - `Thread::Backtrace::Location#binding` returns `Binding|nil`. Nil result may mean that the current location is a C frame or a JITted/optimized frame and we cannot debug it. We can also expose the DebugInspector API directly, as done in the https://github.com/banister/debug_inspector gem, but for tools like web-console, we'd need to map the bindings with the backtrace, as we cannot generate Bindings for every frame (C frames) and this needs to be done in application code, so I think the `Thread::Backtrace::Location#binding` is the better API for Ruby-land. Such API can help us eventually write most of our debuggers in Ruby as right now we don't have a way to do Post-Mortem debugging without native code or even start our debuggers without monkey-patching `Binding`. I have presented this idea in a RubyKaigi's 2019 talk called "Writing Debuggers in Plain Ruby", you can check-out the slides for more context: http://kaigi-debuggers-in-ruby.herokuapp.com. -- https://bugs.ruby-lang.org/