Issue #19742 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Bug #19742: Introduce `Module#anonymous?`
https://bugs.ruby-lang.org/issues/19742
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
As a follow-on <from https://bugs.ruby-lang.org/issues/19521>, I'd like propose we introduce `Module#anonymous?`.
In some situations, like logging/formatting, serialisation/deserialization, debugging or meta-programming, we might like to know if a class is a proper constant or not.
However, this brings about some other issues which might need to be discussed.
After assigning a constant, then removing it, the internal state of Ruby still believes that the class name is permanent, even thought it's no longer true.
e.g.
```
m = Module.new
m.anonymous? # true
M = m
m.anonyomous # false
Object.send(:remove_const, :M)
M # uninitialized constant M (NameError)
M.anonymous? # false
```
Because RCLASS data structure is not updated after the constant is removed, internally the state still has a "permanent class name".
I want to use this proposal to discuss this issue and whether there is anything we should do about such behaviour (or even if it's desirable).
Proposed PR: https://github.com/ruby/ruby/pull/7966
cc @fxn
--
https://bugs.ruby-lang.org/
Issue #19973 has been reported by tenderlovemaking (Aaron Patterson).
----------------------------------------
Bug #19973: Duplicate keyword argument names don't always warn
https://bugs.ruby-lang.org/issues/19973
* Author: tenderlovemaking (Aaron Patterson)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-10-24T19:38:50Z cleanup 3525a9bd22) [arm64-darwin23]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Calling a method with duplicate keyword arguments doesn't warn when it could:
```ruby
def bar a:, b:
a + b
end
# Warning
bar(a: 1, b: 3, a: 2)
z = { b: 123 }
# No warning
bar(a: 1, **z, a: 2)
```
The first call to `bar` gives a warning about duplicate keyword args, but the second call doesn't. I think both cases should emit a warning.
--
https://bugs.ruby-lang.org/
Issue #19967 has been reported by nobu (Nobuyoshi Nakada).
----------------------------------------
Bug #19967: Already installed libruby.dylib is used for test on macOS
https://bugs.ruby-lang.org/issues/19967
* Author: nobu (Nobuyoshi Nakada)
* Status: Assigned
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
* Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
On macOS, in the case of `--enable-shared` and `--disable-load-relative`, already install libruby.dylib is used during tests if exists.
This is because since [Bug #14992], `DYLD_FALLBACK_LIBRARY_PATH` is used instead of `DYLD_LIBRARY_PATH`.
The latter environment variable is used preferentially, whereas the former is used as a fallback, as the name implies.
--
https://bugs.ruby-lang.org/
Issue #19365 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19365: Ractors can access non-shareable values through enumerators
https://bugs.ruby-lang.org/issues/19365
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I don't think enumerators should be able to be passed to `Ractor.new`
```ruby
obj = Object.new # unshareable value
p obj
Ractor.new([obj].each) {|f| p f.first }.take
```
--
https://bugs.ruby-lang.org/
Issue #19395 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19395: Process forking within non-main Ractor creates child stuck in busy loop
https://bugs.ruby-lang.org/issues/19395
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
```ruby
def test_fork_in_ractor
r2 = Ractor.new do
pid = fork do
exit Ractor.count
end
pid
end
pid = r2.take
puts "Process #{Process.pid} waiting for #{pid}"
_pid, status = Process.waitpid2(pid) # stuck forever
if status.exitstatus != 1
raise "status is #{status.exitstatus}"
end
end
test_fork_in_ractor()
```
$ top # shows CPU usage is high for child process
--
https://bugs.ruby-lang.org/
Issue #19408 has been reported by luke-gru (Luke Gruber).
----------------------------------------
Bug #19408: Object no longer frozen after moved from a ractor
https://bugs.ruby-lang.org/issues/19408
* Author: luke-gru (Luke Gruber)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I think frozen objects should still be frozen after a move.
```ruby
r = Ractor.new do
obj = receive
p obj.frozen? # should be true but is false
p obj
end
obj = [Object.new].freeze
r.send(obj, move: true)
r.take
```
--
https://bugs.ruby-lang.org/
Issue #19905 has been reported by hi(a)joaofernandes.me (Joao Fernandes).
----------------------------------------
Feature #19905: Introduce `Queue#peek`
https://bugs.ruby-lang.org/issues/19905
* Author: hi(a)joaofernandes.me (Joao Fernandes)
* Status: Open
* Priority: Normal
----------------------------------------
This ticket proposes the introduction of the `Queue#peek` method, similar to what we can find in other object oriented languages such as Java and C#. This method is similar to `Queue#pop`, but does not change the data, nor does it require a lock.
```
q = Queue.new([1,2,3])
=> #<Thread::Queue:0x00000001065d7148>
q.peek
=> 1
q.peek
=> 1
```
I have felt the need of this for debugging, but I think that it can also be of practical use for presentation. I believe that the only drawback could be that newcomers could misuse it in multi-threaded work without taking into account that this method is not thread safe.
I also volunteer myself to implement this method.
--
https://bugs.ruby-lang.org/
Issue #19970 has been reported by larsin (Lars Ingjer).
----------------------------------------
Bug #19970: Eval leaks callcache and callinfo objects on arm32 (linux)
https://bugs.ruby-lang.org/issues/19970
* Author: larsin (Lars Ingjer)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [armv7l-linux-eabihf]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
The following script demonstrates a memory leak on arm 32 (linux):
``` ruby
def gcdiff(n)
GC.start
if @last_gc_stat
puts "GC.stat #{n} diff old_objects: #{GC.stat(:old_objects) - @last_gc_stat}"
end
@last_gc_stat = GC.stat(:old_objects)
end
def foo
end
10.times do |i|
10_000.times do
eval 'foo'
end
gcdiff(i)
puts "Number of live objects: #{GC.stat(:heap_live_slots)}"
puts "Memory usage: #{`ps -o rss= -p #{$$}`}"
puts
end
```
Output:
```
Number of live objects: 41303
Memory usage: 11900
GC.stat 1 diff old_objects: 20037
Number of live objects: 61317
Memory usage: 13604
GC.stat 2 diff old_objects: 20001
Number of live objects: 81317
Memory usage: 14880
GC.stat 3 diff old_objects: 20000
Number of live objects: 101317
Memory usage: 16596
GC.stat 4 diff old_objects: 20000
Number of live objects: 121317
Memory usage: 17248
GC.stat 5 diff old_objects: 20000
Number of live objects: 141317
Memory usage: 18760
GC.stat 6 diff old_objects: 20000
Number of live objects: 161317
Memory usage: 19540
GC.stat 7 diff old_objects: 20000
Number of live objects: 181317
Memory usage: 21752
GC.stat 8 diff old_objects: 20000
Number of live objects: 201317
Memory usage: 21828
GC.stat 9 diff old_objects: 20000
Number of live objects: 221317
Memory usage: 24896
```
ObjectSpace.count_imemo_objects shows that imemo_callcache and imemo_callinfo are leaking.
The issue does not occur on arm64 mac or x86_64 linux with the same ruby version.
The issue has also been reproduced with the latest 3.2.2 snapshot (2023-09-30).
--
https://bugs.ruby-lang.org/
Issue #19542 has been reported by hanazuki (Kasumi Hanazuki).
----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542
* Author: hanazuki (Kasumi Hanazuki)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I found that IO::Buffer of zero length is not cloneable.
```
% ruby -v
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
% ruby -e 'p IO::Buffer.for("").dup'
-e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError)
from -e:1:in `initialize_dup'
from -e:1:in `dup'
from -e:1:in `<main>'
% ruby -e 'p IO::Buffer.new(0).dup'
-e:1: warning: IO::Buffer is experimental and both the Ruby and C interface may change in the future!
-e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError)
from -e:1:in `initialize_dup'
from -e:1:in `dup'
from -e:1:in `<main>'
```
It seems `IO::Buffer.new(0)` allocates no memory for buffer on object creation and thus prohibits reading from or writing to it. So `#dup` method copying zero bytes into the new IO::Buffer raises the exception.
Empty buffers, however, often appear in corner cases of usual operations (encrypting an empty string, encoding an empty list of items into binary, etc.) and it would be easy if such cases could be handled consistently.
Other operations on NULL IO::Buffers are also useful but currently raising.
```
IO::Buffer.new(0) <=> IO::Buffer.new(1)
IO::Buffer.new(0).each(:U8).to_a
IO::Buffer.new(0).get_values([], 0)
IO::Buffer.new(0).set_values([], 0, [])
```
I'm not sure this is a bug or by design, but at least I don't want cloning and comparison to raise.
--
https://bugs.ruby-lang.org/
Issue #19461 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Bug #19461: Time.local performance tanks in forked process (on macOS only?)
https://bugs.ruby-lang.org/issues/19461
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
The following program demonstrates a performance regression in forked child processes when invoking `Time.local`:
```ruby
require 'benchmark'
require 'time'
def sir_local_alot
result = Benchmark.measure do
10_000.times do
tm = ::Time.local(2023)
end
end
$stderr.puts result
end
sir_local_alot
pid = fork do
sir_local_alot
end
Process.wait(pid)
```
On Linux the performance is similar, but on macOS, the performance is over 100x worse on my M1 laptop.
--
https://bugs.ruby-lang.org/