| Age | Commit message (Collapse) | Author |
|---|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12624
|
|
(https://github.com/ruby/irb/pull/1043)
IRB started to page its evaluation output and it became a useful feature
for users. However, in `irb:rdbg` sessions, the output is not paged so
the sudden change in behavior is surprising and inconvenient.
This commit makes `irb:rdbg` sessions page the output of the debugger
too.
https://github.com/ruby/irb/commit/8241ec9a0c
|
|
(https://github.com/ruby/irb/pull/1007)
In debug command, IRB's context was using wrong binding.
Some code colorization, command detection failed because binding.local_variable returned wrong value.
https://github.com/ruby/irb/commit/68f718de21
|
|
(https://github.com/ruby/irb/pull/725)
Since `debug` stores and updates the target thread via its Session's
`@tc` variable, we don't need to and shouldn't lock the UI to the thread
that activates the integration.
https://github.com/ruby/irb/commit/202efdbf0c
|
|
(https://github.com/ruby/irb/pull/575)
* Support native integration with ruby/debug
* Prevent using multi-irb and activating debugger at the same time
Multi-irb makes a few assumptions:
- IRB will manage all threads that host sub-irb sessions
- All IRB sessions will be run on the threads created by IRB itself
However, when using the debugger these assumptions are broken:
- `debug` will freeze ALL threads when it suspends the session (e.g. when
hitting a breakpoint, or performing step-debugging).
- Since the irb-debug integration runs IRB as the debugger's interface,
it will be run on the debugger's thread, which is not managed by IRB.
So we should prevent the 2 features from being used at the same time.
To do that, we check if the other feature is already activated when
executing the commands that would activate the other feature.
https://github.com/ruby/irb/commit/d8fb3246be
|
