Issue #9366 has been updated by hsbt (Hiroshi SHIBATA).
Status changed from Assigned to Feedback
@normalperson Do you still have this issue?
----------------------------------------
Bug #9366: "make -j32 check TESTS=-j32" occasionally fails on rubygems/specification
https://bugs.ruby-lang.org/issues/9366#change-102267
* Author: normalperson (Eric Wong)
* Status: Feedback
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* ruby -v: ruby 2.2.0dev (2014-01-05 trunk 44507) [x86_64-linux]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
This only happens occasionally, maybe 1 out of 10 times during "make check",
so it's probably a bug somewhere with GC.
I'll try to reproduce without parallel tests (could take a while).
It seems to reproduce more easily on slower machine.
I initially thought it was a bug in cachelined, but I can also reproduce it with plain trunk.
/home/ew/ruby/lib/rubygems/specification.rb:748:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError)
/home/ew/ruby/lib/rubygems/specification.rb:747:in `sort!'
/home/ew/ruby/lib/rubygems/specification.rb:747:in `_resort!'
/home/ew/ruby/lib/rubygems/specification.rb:699:in `_all'
/home/ew/ruby/lib/rubygems/specification.rb:882:in `each'
/home/ew/ruby/lib/rubygems/dependency.rb:284:in `find_all'
/home/ew/ruby/lib/rubygems/dependency.rb:284:in `to_specs'
/home/ew/ruby/lib/rubygems/dependency.rb:309:in `to_spec'
/home/ew/ruby/lib/rubygems/core_ext/kernel_gem.rb:53:in `gem'
/home/ew/ruby/lib/rubygems/package_task.rb:25:in `<top (required)>'
/home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require'
/home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require'
/home/ew/ruby/test/rubygems/test_gem_package_task.rb:3:in `<top (required)>'
/home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require'
/home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require'
/home/ew/ruby/lib/test/unit/parallel.rb:114:in `run'
/home/ew/ruby/lib/test/unit/parallel.rb:183:in `<main>'
Some worker was crashed. It seems ruby interpreter's bug
or, a bug of test/unit/parallel.rb. try again without -j
option.
--
https://bugs.ruby-lang.org/
Issue #19450 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Feature #19450: Is there an official way to set a class name without setting a constant?
https://bugs.ruby-lang.org/issues/19450
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
This is the best I could come up with:
```ruby
klass = Class.new
Object.const_set("Klass", klass)
Object.send(:remove_const, "Klass")
puts klass.new
# => #<Klass:0x0000000100a9d688>
```
Can we do better?
--
https://bugs.ruby-lang.org/
Issue #16431 has been updated by hsbt (Hiroshi SHIBATA).
Status changed from Open to Assigned
Assignee set to hsbt (Hiroshi SHIBATA)
----------------------------------------
Feature #16431: Optionally load did_you_mean (and RubyGems)
https://bugs.ruby-lang.org/issues/16431#change-102266
* Author: vo.x (Vit Ondruch)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
----------------------------------------
I just have opened PR [1], which allows Ruby to run when did_you_mean is not available. As I previously discussed in #16427, there are cases when speed, memory, disk or network bandwidth is a concern and did_you_mean is not useful for runtime. This is especially useful when Ruby is installed via packaging systems of (Linux) distributions.
The PR is split into 4 commits, because since I was there, I prepared similar changes to RubyGems.
[1]: https://github.com/ruby/ruby/pull/2764
--
https://bugs.ruby-lang.org/
Issue #18658 has been updated by hsbt (Hiroshi SHIBATA).
Status changed from Assigned to Rejected
We decided to not backport openssl-3.x gem into `ruby_2_7` and `ruby_3_0` branches. Because it affects with OpenSSL 1.0.x.
Unfortunately, the users should upgrade their ruby version to 3.1+ before upgrading their OS version.
----------------------------------------
Bug #18658: Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x)
https://bugs.ruby-lang.org/issues/18658#change-102262
* Author: schneems (Richard Schneeman)
* Status: Rejected
* Priority: Normal
* Assignee: usa (Usaku NAKAMURA)
* ruby -v: 3.0
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
Ubuntu 22.04 is being released soon and ships with openssl 3. As of now Ruby 2.7.x and 3.0.x are under core support and will not build on Ubuntu 22.04 with openssl (Ruby 3.1.x can compile).
When attempting to compile 3.0.3 on Ubuntu 22 it issues this warning:
```
*** Following extensions are not compiled:
openssl:
Could not be configured. It will not be installed.
/ruby-3.0.3/ext/openssl/extconf.rb:113: OpenSSL >= 1.0.1, < 3.0.0 or LibreSSL >= 2.5.0 is required
Check ext/openssl/mkmf.log for more details.
```
Here are some existing issues/PRs that I could find:
- https://github.com/ruby/openssl/issues/369
- https://github.com/ruby/openssl/pull/399
Ideally I would like to compile and support all non-EOL Ruby versions for Ubuntu 22 on release day. Are there any plans to backport support for OpenSSL 3 to Ruby 3.0 and 2.7?
--
https://bugs.ruby-lang.org/
Issue #18743 has been updated by ko1 (Koichi Sasada).
Assignee set to ko1 (Koichi Sasada)
----------------------------------------
Bug #18743: Enumerator#next / peek re-use each others stacktraces
https://bugs.ruby-lang.org/issues/18743#change-102258
* Author: sos4nt (Stefan Schüßler)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
I encountered an odd behavior.
If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa)
```ruby
# enum.rb # 1
# 2
enum = [].each # 3
enum.peek rescue nil # 4
enum.next # 5
```
it will show the stacktrace from the rescued `peek` call:
```
$ ruby enum.rb
enum.rb:4:in `peek': iteration reached an end (StopIteration)
from enum.rb:4:in `<main>'
```
Whereas the error should refer to `next` on line number 5.
The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls:
```ruby
# enum.rb # 1
# 2
enum = [].each # 3
enum.peek rescue nil # 4
enum.next rescue nil # 5
enum.peek rescue nil # 6
puts "line #{__LINE__}" # 7
enum.next # 8
```
The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location:
```
$ ruby enum.rb
line 7
enum.rb:4:in `peek': iteration reached an end (StopIteration)
from enum.rb:4:in `<main>'
```
This is very confusing when debugging code.
---Files--------------------------------
01-Recreate-stacktrace-enumerator.patch (1.29 KB)
--
https://bugs.ruby-lang.org/
Issue #19094 has been updated by matz (Yukihiro Matsumoto).
I understand the usefulness of the proposal. Accepted.
But do not propose other changes just for consistency with this change.
Matz.
----------------------------------------
Feature #19094: `sleep(nil)` vs `sleep()` and replicating the default implementation.
https://bugs.ruby-lang.org/issues/19094#change-102255
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
```
> sleep(nil)
(irb):1:in `sleep': can't convert NilClass into time interval (TypeError)
```
However, I feel that this makes implementing a compatible sleep method a little difficult.
```ruby
def sleep(time = nil)
if time
sleep_some(time)
else
sleep_forever
end
end
```
Can we consider allowing `sleep(nil)` and `sleep(false)` to be the same as `sleep()` to simplify this behaviour?
Otherwise, it's hard to proxy (e.g. fiber scheduler, or even just a plain old variable argument).
e.g.
```ruby
class Sleeper
def initialize(time = nil)
@time = time
end
def sleep
Kernel::sleep(@time) # Hard to get the behaviour of `sleep()` here without explicitly handling/checking.
end
end
```
--
https://bugs.ruby-lang.org/
Issue #19472 has been reported by ko1 (Koichi Sasada).
----------------------------------------
Feature #19472: Ractor::Selector to wait multiple ractors
https://bugs.ruby-lang.org/issues/19472
* Author: ko1 (Koichi Sasada)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: 3.3
----------------------------------------
This ticket propose `Ractor::Selector` API to wait multiple ractor events.
Now, if we want to wait for taking from r1, r2 and r3, we can use `Ractor.select()` like that.
```ruby
r, v = Ractor.select(r1, r2, r3)
p "taking an object #{v} from #{r}"
```
With proposed `Ractor::Selector` API, we can write the following:
```ruby
selector = Ractor.selector.new(r1, r2) # make a waiting set with r1 and r2
selector.add(r3) # we can add r3 to the waiting set after that.
selector.add(r4)
selector.remove(r4) # we can remove r4 from the waiting set.
r, v = selector.wait
p "taking an object #{v} from #{r}"
```
* `Ractor::Selector.new(*ractors)`: create a selector
* `Ractor::Selector#add(r)`: add `r` to the waiting list
* `Ractor::Selector#remove(r)`: remove `r` from the waiting list
* `Ractor::clear`: remove all ractors from the waiting list
* `Ractor::wait`: wait for the ractor events
The advantages from `Ractor.select` is:
* (1) (API design) We can preset the waiting set before waiting. Providing unified way to manage waiting list seems better.
* (2) (Performance) It is lighter than passing an array object to the `Ractor.select(*rs)` if `rs` is bigger and bigger.
For (2), it is important to supervise thousands of ractors.
`Ractor::Selector#wait` also has additional features:
* `wait(receive: true)` also waits receiving.
* `Ractor.select(*rs, Ractor.current)` does same, but I believe `receive: true` keyword is more direct to understand.
* `wait(yield_value: obj, move: true/false)` also waits yielding.
* Same as `Ractor.select(yield_value: obj, move: true/false)`
* If a ractor `r` is closing, then `#wait` removes `r` automatically.
* If there is no waiting ractors, it raises an exception (now `Ractor::Error` is raised but it should be a better exception class)
With automatic removing, we can write the code to wait n tasks.
```ruby
rs = n.times.map{ Ractor.new{ do_task } }
selector = Ractor::Selector.new(*rs)
loop do
r, v = selector.wait
handle_answers(r, v)
rescue Ractor::Error
p :all_tasks_done
end
```
Without auto removing, we can write the following code.
```ruby
rs = n.times.map{ Ractor.new{ do_task } }
selector = Ractor::Selector.new(*rs)
loop do
r, v = selector.wait
handle_answers(r, v)
rescue Ractor::ClosedError => e
selector.remove e.ractor
rescue Ractor::Error
p :all_tasks_done
end
# or on this case worker ractors only yield one value (at exit) so the following code works as well.
loop do
r, v = selector.wait
handle_answers(r, v)
selector.remove r
rescue Ractor::Error
p :all_tasks_done
end
```
I already merged it but I want to discuss about the spec.
Discussion:
* The name `Selector` is acceptable?
* Auto-removing seems convenient but it can hide the behavior.
* allow auto-removing
* allow auto-removing as configurable option
* per ractor or per selector
* which is default?
* disallow auto-removing
* What happens on no taking ractors
* raise an exception (which exception?)
* return nil simply
maybe and more...
--
https://bugs.ruby-lang.org/
Issue #19484 has been reported by joel(a)drapper.me (Joel Drapper).
----------------------------------------
Feature #19484: Calling `binding` on a C-level proc raises an `ArgumentError`
https://bugs.ruby-lang.org/issues/19484
* Author: joel(a)drapper.me (Joel Drapper)
* Status: Open
* Priority: Normal
----------------------------------------
Calling `binding` on a C-level proc (from `&:symbol`) raises an `ArgumentError`, "Can't create Binding from C level Proc" but there is no way to tell if a given proc is a C-level proc before calling `binding` on it. It’s possible to rescue this error, but rescuing an exception is slow.
Given that a C-level proc doesn't have a binding, would it make more sense to respond to `binding` with `nil` rather than raise an error? That would allow us to, for example, look up the receiver and fall back to self, e.g. `block.binding&.receiver || self`.
Alternatively, it would be useful to be able to check whether a given proc is a C-Level proc using something like this.
```ruby
case block
when CProc
block.call(self)
else
block.call
end
```
An example use case is an interface that takes a hash of conditions and tokens. If the condition is valid, we do something with the token. Otherwise, we ignore it.
```ruby
some_interface(-> { true } => "foo", -> { false } => "bar" )
```
With literal Procs, it makes sense to call them and check their truthiness.
```ruby
def some_interface(**conditional_tokens)
conditional_tokens.each do |condition, token|
do_something_with(token) if condition.call
end
end
```
When given C-Level procs, it makes sense to call them with `self` to evaluate the corresponding method.
```ruby
some_interface(&:foo? => "foo", &:bar? => "bar" )
```
```ruby
def foo? = true
def bar? = false
def some_interface(**conditional_tokens)
conditional_tokens.each do |condition, token|
case condition
when CProc
do_something_with(token) if condition.call(self)
else
do_something_with(token) if condition.call
end
end
end
```
--
https://bugs.ruby-lang.org/
Issue #19432 has been reported by joel(a)drapper.me (Joel Drapper).
----------------------------------------
Feature #19432: Introduce a wrapping operator (&) to Proc
https://bugs.ruby-lang.org/issues/19432
* Author: joel(a)drapper.me (Joel Drapper)
* Status: Open
* Priority: Normal
----------------------------------------
I don't know if this concept exists under another name, or whether there’s a technical term for it. I often find myself wanting to wrap a proc in another proc.
Here's a snippet from a recent example where a visitor class renders a TipTap AST. Given a `text` node, we want to output the text by calling the `text` method with the value. But if the text has `marks`, we want to iterate through each mark, wrapping the output for each mark. It's possible to do this using the `>>=` operator if each proc explicitly returns another proc.
```ruby
when "text"
result = -> { -> { text node["text"] } }
node["marks"]&.each do |mark|
case mark["type"]
when "bold"
result >>= -> (r) { -> { strong { r.call } } }
when "italic"
result >>= -> (r) { -> { em { r.call } } }
end
end
result.call.call
end
```
This is quite difficult to follow and the `result.call.call` feels wrong. I think the concept of wrapping one proc in another proc would make for a great addition to `Proc` itself. I prototyped this using the `&` operator.
```ruby
class Proc
def &(other)
-> { other.call(self) }
end
end
```
With this definition, we can call `&` on the original proc with our other proc to return a new proc that calls the other proc with the original proc as an argument. It also works with `&=`, so the above code can be refactored to this:
```ruby
when "text"
result = -> { text node["text"] }
node["marks"]&.each do |mark|
case mark["type"]
when "bold"
result &= -> (r) { strong { r.call } }
when "italic"
result &= -> (r) { em { r.call } }
end
end
result.call
end
```
--
https://bugs.ruby-lang.org/