Repository navigation
Make IRB::VERSION available for library users - #1
Conversation
|
Seems like a good idea. Would be a good idea to replace those |
|
I believe |
|
AFAIK, |
|
Honestly, I do not know... possibly/probably(?) outdated information. But anyway I think this would best be considered in a different PR or on Redmine. Your suggestion would apply to most of the standard libraries and extensions in Ruby trunk, I guess. |
Sure, I'll have a look. |
|
You probably want to remove the useless |
Always require `irb/version' to provide IRB::VERSION at any time, not only when IRB.version is called previously.
|
@stomar Maybe this is what you vaguely remembered :-) |
|
@marcandre Thanks for the reference, seems I got it mixed up :) |
The following `test_irb_fg_jobs_and_kill_commands` expects that after `fg 0`
Thread#1 should be `sleep_forever`.
```ruby
def test_irb_fg_jobs_and_kill_commands
out = run_ruby_file do
type "irb"
type "fg 0"
type "jobs"
type "kill 1"
type "exit"
end
assert_match(/#0->irb on main \(#<Thread:0x.+ run>: running\)/, out)
assert_match(/ruby#1->irb#1 on main \(#<Thread:0x.+ sleep_forever>: stop\)/, out)
end
end
```
However, the following switching method expects that
```
def switch(key)
th, irb = search(key)
...
th.run
Thread.stop
```
(1) resume target thread
(2) Suspend current thread (-> sleep_forever)
`th.run` calls `Thread.pass` internally and maybe the context swtich to
resumed thread (#0 in this case).
Thread #0 should switch to ruby#1 before `jobs` command.
Until Ruby 3.4, I/O operation makes context switching to another ready thread,
so that several I/O output can resume `ruby#1`.
However, our planning new thread scheduler delays context switching on I/O
operations, so the thread ruby#1 still running (because `Thread.stop` is not called yet).
This patch add `Thraed.pass` to make workaround for this test.
The following `test_irb_fg_jobs_and_kill_commands` expects that after `fg 0`
Thread#1 should be `sleep_forever`.
```ruby
def test_irb_fg_jobs_and_kill_commands
out = run_ruby_file do
type "irb"
type "fg 0"
type "jobs"
type "kill 1"
type "exit"
end
assert_match(/#0->irb on main \(#<Thread:0x.+ run>: running\)/, out)
assert_match(/#1->irb#1 on main \(#<Thread:0x.+ sleep_forever>: stop\)/, out)
end
end
```
However, the following switching method expects that
```
def switch(key)
th, irb = search(key)
...
th.run
Thread.stop
```
(1) resume target thread
(2) Suspend current thread (-> sleep_forever)
`th.run` calls `Thread.pass` internally and maybe the context swtich to
resumed thread (#0 in this case).
Thread #0 should switch to #1 before `jobs` command.
Until Ruby 3.4, I/O operation makes context switching to another ready thread,
so that several I/O output can resume `#1`.
However, our planning new thread scheduler delays context switching on I/O
operations, so the thread #1 still running (because `Thread.stop` is not called yet).
This patch add `Thraed.pass` to make workaround for this test.
3 participants
IRB::VERSIONis defined and used in the gemspec, but not available for irb users. The PR makes it available in irb sessions.Edit: The build fail seems to be unrelated.