not defined
(https://github.com/ruby/irb/pull/853)
The issue (https://github.com/ruby/debug/issues/1064) is caused by a
combination of factors:
1. When user starts an IRB session without a history file, the
`@loaded_history_lines` ivar is not defined.
2. If the user then starts the `irb:rdbg` session, the history counter
is not set, because the `@loaded_history_lines` is not defined.
3. Because `irb:rdbg` saves the history before passing Ruby expression
to the debugger, it saves the history with duplicated lines. The number
grows in exponential order.
4. When the user exits the `irb:rdbg` session, the history file could be
bloated with duplicated lines.
This commit fixes the issue by resetting the history counter even when
`@loaded_history_lines` is not defined.
4afc98c258
(https://github.com/ruby/irb/pull/651)
* handle concurrent sessions and saving Readline::HISTORY, fixes https://github.com/ruby/irb/pull/510
* separate tests
* don't mutate the HISTORY object on the class
* avoid repeated .to_i calls
* remove intermediary history array
* work with array, fix test comment
---------
1681ada328
Co-authored-by: Stan Lo <stan001212@gmail.com>
(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.
d8fb3246be
(https://github.com/ruby/irb/pull/652)
1. Dynamically including `HistorySavingAbility` makes things unnecessarily
complicated and should be avoided.
2. Because both `Reline` and `Readline` use a single `HISTORY` constant
to store history data. When nesting IRB sessions, only the first IRB
session should handle history loading and saving so we can avoid
duplicating history.
3. History saving callback should NOT be stored in `IRB.conf` as it's
recreated every time `IRB.setup` is called, which would happen when
nesting IRB sessions.
0fef0ae160
(https://github.com/ruby/irb/pull/642)
* Define RelineInputMethod::HISTORY
The HistorySavingAbility module doesn't do anything if the input method
class doesn't define HISTORY.
- 3ac96be660/lib/irb/history.rb (L10)
- 3ac96be660/lib/irb/history.rb (L34)
This patch defines RelineInputMethod::HISTORY to avoid this.
* Improve history-saving's ability check
Instead of checking the existence of `input_method_class::HISTORY`, we should
make every input method class declare if it supports history saving or not.
Since the default value is `false`, it shouldn't break any custom input method
that inherits from `IRB::InputMethod`.
aec7a5b3f5
(https://github.com/ruby/irb/pull/613)
Since `IRB.conf[:SAVE_HISTORY]` is assigned with 1000 by default, history-saving
is a feature enabled by default. So it should not be treated as an extension,
which adds unnecessary complexity to the code.
2023-07-03 13:48:23 +00:00
Renamed from lib/irb/ext/save-history.rb (Browse further)
