Some background for this refactor:
1. Through a RubyLex instance's lifetime, the context passed to its methods
should be the same.
Given that `Context` is only initialised in `Irb#initialize`,
this should be true.
2. When `RubyLex` is initialised, the context object should be accessible.
This is also true in all 3 of `RubyLex.new`'s invocations.
With the above observations, we should be able to store the context in `RubyLex`
as an instance variable. And doing so will make `RubyLex`'s instance methods
easier to use and maintain.
5c8d3df2df
(https://github.com/ruby/irb/pull/478)
Given that `show_doc` already supports syntax like `String#gsub`, it
should be able to take it in non-string form too, like `edit` and
`show_source` do. This ensures users can have a consistent syntax on
argument between different commands.
The current `next` pre-command workaround on IRB source stepping
moves the location by 1 extra line. A better way is to make `debug`
skip IRB frames completely, which is what this commit does.
It also fixes the step command's test. The `|` in regexp was not escaped
so it was always incorrectly matched.
(https://github.com/ruby/irb/pull/473)
* Handle file loading commands' argument error gracefully
Currently, if users don't provide an argument to `source`,
`irb_load`, and `irb_require`, IRB raises `ArgumentError` with full
stacktrace. This is confusing because it looks similar to when IRB has
internal issues. The message also isn't helpful on helping users avoid
the error.
So in this commit, I add a new `CommandArgumentError` for commands to
raise explicitly when users' input doesn't satisfy a command's argument
requirement.
* Gracefully handle `fg` command's argument requirement
(https://github.com/ruby/irb/pull/472)
* Lazily load the multi-irb extension
We now have plan to implement a command that prints all commands'
information, which will need to load all command files without actually
running them.
But because the `multi-irb` extension patches IRB's top-level methods,
loading it would cause unintentional side-effects.
So this commit moves related requires into command execution to avoid the problem.
* Make extend_irb_context private
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
(https://github.com/ruby/irb/pull/449)
* Seamlessly integrate a few debug commands
* Improve the break command support
* Utilize skip_src option if available
* Add step and delete commands
* Write end-to-end tests for each debugger command
* Add documentation
* Add backtrace, info, catch commands
976100c1c2
(https://github.com/ruby/irb/pull/448)
* Minor fixes on debug command
* Discover and load debug.gem even if it's not in Gemfile
* Eliminate else for rescue
* Discover the latest one from all gem paths
(https://github.com/ruby/irb/pull/437)
* Transform ls's --grep/-G option to keyword args
* Make --grep less flexible
* Support -g instead of --grep
* Suppress warnings from symbol aliases
* Use colorable: argument as the only coloring control
* Centalize color controling logic at Color.colorable?
There are 2 requirements for coloring output:
1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`
Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like https://github.com/ruby/irb/pull/362
And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
* Add tests for all inspect modes
* Simplify inspectors' coloring logic
* Replace use_colorize? with Color.colorable?
* Remove Context#use_colorize cause it's redundant
1c53023ac4
Instead of accessing the struct as an array, access it via methods. There are other places inside of this file already using this API (for example e0a5c3d2b7/lib/irb/ruby-lex.rb (L829-L830)).
This commit moves all struct array-ish calls to use their method calls instead. It is also ~1.23 faster accessing values via a method instead of as an array according to this microbenchmark:
```ruby
Elem = Struct.new(:pos, :event, :tok, :state, :message) do
def initialize(pos, event, tok, state, message = nil)
super(pos, event, tok, State.new(state), message)
end
# ...
def to_a
a = super
a.pop unless a.empty?
a
end
end
class ElemClass
attr_accessor :pos, :event, :tok, :state, :message
def initialize(pos, event, tok, state, message = nil)
@pos = pos
@event = event
@tok = tok
@state = State.new(state)
@message = message
end
def to_a
if @message
[@pos, @event, @tok, @state, @message]
else
[@pos, @event, @tok, @state]
end
end
end
# stub state class creation for now
class State; def initialize(val); end; end
```
```ruby
Benchmark.ips do |x|
x.report("struct") { struct[1] }
x.report("class ") { from_class.event }
x.compare!
end; nil
```
```
Warming up --------------------------------------
struct 1.624M i/100ms
class 1.958M i/100ms
Calculating -------------------------------------
struct 17.139M (± 2.6%) i/s - 86.077M in 5.025801s
class 21.104M (± 3.4%) i/s - 105.709M in 5.015193s
Comparison:
class : 21103826.3 i/s
struct: 17139201.5 i/s - 1.23x (± 0.00) slower
```
This reverts commit 27dd2867cda5c789efaa5078214ad2fd82adcebf.
This is to fix the test I added.
(I separated commits to test a new behavior of ruby-commit-hook)
fe055d521a
https://github.com/ruby/irb/pull/249 actually slowed down how `code` is
concatenated. The original way of creating `code` is faster.
[before]
user system total real
2.420137 0.005364 2.425501 ( 2.426264)
[after]
user system total real
1.000221 0.007454 1.007675 ( 1.008295)
Theoretically, this implementation might skip lines that don't appear in
Ripper tokens, but this assumes such lines don't impact whether the code
passes compilation or not. At least normal blank lines seem to have an
`on_ignored_nl` token anyway though.
27dd2867cd
You can use "measure" command to check performance in IRB like below:
irb(main):001:0> 3
=> 3
irb(main):002:0> measure
TIME is added.
=> nil
irb(main):003:0> 3
processing time: 0.000058s
=> 3
irb(main):004:0> measure :off
=> nil
irb(main):005:0> 3
=> 3
You can set "measure :on" by "IRB.conf[:MEASURE] = true" in .irbrc, and, also,
set custom performance check method:
IRB.conf[:MEASURE_PROC][:CUSTOM] = proc { |context, code, line_no, &block|
time = Time.now
result = block.()
now = Time.now
puts 'custom processing time: %fs' % (Time.now - time) if IRB.conf[:MEASURE]
result
}
3899eaf2e2
