Issue #20337 has been reported by Eregon (Benoit Daloze).
----------------------------------------
Bug #20337: Complex#inspect mutates the string returned by `real.inspect`
https://bugs.ruby-lang.org/issues/20337
* Author: Eregon (Benoit Daloze)
* Status: Open
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
```
irb(main):001:0> n = Numeric.new
=> #<Numeric:0x00007f81b2308578>
irb(main):004:0> class Numeric; def inspect = super.freeze; end
=> :inspect
irb(main):006:0> Complex(n, 1).inspect
(irb):6:in `inspect': can't modify frozen String: "#<Numeric:0x00007f81b2308578>" (FrozenError)
from (irb):6:in `<main>'
from /home/eregon/.rubies/ruby-3.2.2/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11:in `<top (required)>'
from /home/eregon/.rubies/ruby-3.2.2/bin/irb:25:in `load'
from /home/eregon/.rubies/ruby-3.2.2/bin/irb:25:in `<main>'
```
It feels wrong to mutate the result of inspect at least in general, for instance `true.inspect` is frozen.
Discovered by https://github.com/ruby/spec/pull/1142
--
https://bugs.ruby-lang.org/
Issue #20333 has been reported by dorianmariefr (Dorian Marié).
----------------------------------------
Bug #20333: segfault while running my tests
https://bugs.ruby-lang.org/issues/20333
* Author: dorianmariefr (Dorian Marié)
* Status: Open
* ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
No sure how to debug it, I had a segfault while running the tests, maybe you will find it useful.
---Files--------------------------------
segfault.log (731 KB)
crash.log (100 KB)
--
https://bugs.ruby-lang.org/
Issue #4247 has been updated by mame (Yusuke Endoh).
Status changed from Assigned to Rejected
Assignee deleted (mame (Yusuke Endoh))
We discussed this at the dev meeting. No one remembered the discussion from over 10 years ago, so we discussed it anew and concluded that this was a no-go.
A naive API design could be `ary.sample(k, weights: [Float])`, but this would be an O(ary.size * k) time-consuming algorithm.
There are many more efficient algorithms for weighted sampling. (We read Julia's [StatsBase.jl](https://juliastats.org/StatsBase.jl/stable/sampling/) and Python's [random](https://docs.python.org/3.13/library/random.html).) However, these require additional information, such as the sum of the weights, cumulative weight table, the need to build the table in advance, etc.
We want to avoid an API design that only allows slow algorithm, but it seems overkill to introduce an API that allows advanced algorithms as a built-in feature. We concluded that it would be better to make a gem, instead of a built-in feature, for such things.
----------------------------------------
Feature #4247: New features for Array#sample, Array#choice
https://bugs.ruby-lang.org/issues/4247#change-107242
* Author: oj (Yoji Ojima)
* Status: Rejected
----------------------------------------
=begin
We are planning to add the following features of the random sampling to Array.
1. Weighted random sampling.
2. Sampling with replacement.
3. Iteration.
It is discussed in ruby-dev (Feature #3647 and #4147).
API will be:
Array#sample([size, [opt]])
- Random selection without replacement.
- Returns a new array when size is specified.
- opt:
weight: proc or array
random: Random instance
Array#choice([size, [opt]])
- Random selection with replacement.
- Returns a new array when size is specified.
- opt: same as above.
Array#each_sample([opt])
- Random selection iterator without replacement.
- Choose a random element and yield it.
- Returns an Enumerator if a block is not given.
- opt: same as above.
Array#each_choice([opt])
- Random selection iterator with replacement.
- Choose a random element and yield it.
- Returns an Enumerator if a block is not given.
- opt: same as above.
Comments?
=end
--
https://bugs.ruby-lang.org/
Issue #20261 has been reported by burdettelamar (Burdette Lamar).
----------------------------------------
Feature #20261: Add symbol alternatives to '' and nil for IO line separators
https://bugs.ruby-lang.org/issues/20261
* Author: burdettelamar (Burdette Lamar)
* Status: Open
* Priority: Normal
----------------------------------------
For IO's line-oriented read methods, there are two special values for the line-separator argument `sep`; I'm proposing to add (user-friendlier) symbol synonyms for those values:
- `:paragraph` as synonym for `''` (read paragraphs).
- `:slurp` as synonym for `nil` (read all).
Details (code, documentation, tests) may be seen at https://github.com/ruby/ruby/pull/9921.
--
https://bugs.ruby-lang.org/
Issue #20310 has been reported by kjtsanaktsidis (KJ Tsanaktsidis).
----------------------------------------
Bug #20310: ASAN fake stacks need to be marked during GC for non-current execution context
https://bugs.ruby-lang.org/issues/20310
* Author: kjtsanaktsidis (KJ Tsanaktsidis)
* Status: Assigned
* Assignee: kjtsanaktsidis (KJ Tsanaktsidis)
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
When ASAN (address sanitizer) is enabled, the compiler does not necessarily store all local variables on the real machine stack; instead, locals can be stored in per-frame heap allocated memory which ASAN uses to detect things like stack-use-after-return ("fake stacks"). A pointer to the fake stack is left on the real machine stack, so it's possible to discover these fake stacks during GC and mark locals stored there as well.
At the moment, Ruby is currently marking these fake stacks for the current execution context which triggered GC, as part of `mark_current_machine_context`: https://github.com/ruby/ruby/blob/fe0b704df5553bdd59e90650ffbbfac785a2e48a/…. However, there are other machine stacks which also need to be marked like this:
* Machine stacks for other threads which did not trigger GC are marked in `rb_execution_context_mark` here: https://github.com/ruby/ruby/blob/fe0b704df5553bdd59e90650ffbbfac785a2e48a/…
* Machine stacks for fibers are marked in `cont_mark` here: https://github.com/ruby/ruby/blob/fe0b704df5553bdd59e90650ffbbfac785a2e48a/…
We need to make these two kinds of stacks perform the same ASAN fake stack marking as `mark_current_machine_context` does.
(P.S. - `callcc` continuations are another kind of machine stack which get marked, but ASAN is not compatible with callcc, so this doesn't really matter).
(P.S. - it appears to me that the currently-switched-to fiber will have its stack marked _twice_; once in `rb_execution_context_mark` or `mark_current_machine_context, and once in `cont_mark`; if this is true, I will fix this too)
--
https://bugs.ruby-lang.org/
Issue #20306 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Feature #20306: Add rb_free_at_exit_p
https://bugs.ruby-lang.org/issues/20306
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/10104
From ticket [#20290](https://bugs.ruby-lang.org/issues/20290#note-6), I found that C extensions could use ruby_vm_at_exit to register hooks to free memory at shutdown. However, they cannot determine whether they should free all memory during shutdown to mirror the behavior of Ruby when RUBY_FREE_AT_EXIT is set.
This ticket proposes a new API called rb_free_at_exit_p that returns true when RUBY_FREE_AT_EXIT is set, and false otherwise.
--
https://bugs.ruby-lang.org/
Issue #20265 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Feature #20265: Deprecate and remove rb_newobj and rb_newobj_of
https://bugs.ruby-lang.org/issues/20265
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/9964
I’m proposing deprecating and removing the rb_newobj and rb_newobj_of APIs because they are difficult to use, fragile to use, and requires knowledge of the internal implementation of data types in Ruby.
The rb_newobj function creates a T_NONE object. T_NONE objects are tricky to deal with since T_NONE objects cannot be marked, T_NONE objects are not reclaimed by the GC, and changing the object to other types require internal knowledge about the data type.
T_NONE objects are not allowed to be marked, so it cannot be GC managed. Since T_NONE objects are skipped during sweeping, it will leak Ruby heap memory if the developer never changes the object to another type.
Changing a T_NONE object to another type is tricky. For example, T_STRING objects have many flags for embedded, shared, shared root, encoding, coderange, etc. Many of these flags are not public, preventing direct use by developers. Developers must understand these flags to convert a T_NONE object into a T_STRING object.
While the rb_newobj_of function is easier to use than the rb_newobj function, it still requires developers to understand flags, meaning some issues of rb_newobj also apply to rb_newobj_of.
Below is the usage of RB_NEWOBJ, rb_newobj, rb_newobj_of, RB_NEWOBJ_OF with vendored Ruby and comments removed. You can see that there are very few gems using these APIs and all are from over a decade ago (the most recent one is from 2011).
```
2009-11-18 /srv/gems/bleak_house-7.2/ruby/ruby-1.8.7.patch:@@ -438,10 +438,8 @@ rb_newobj()
2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj() -> VALUE;
2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj_of(klass: VALUE, flags: VALUE) -> VALUE;
2010-08-06 /srv/gems/langscan-1.2/ext/langscan/ruby/compat/ripper/ripper.c: NODE *n = (NODE*)rb_newobj();
2011-02-03 /srv/gems/memprof-0.3.10/ext/memprof.c: VALUE ret = rb_newobj();
2011-02-03 /srv/gems/memprof-0.3.10/ext/tracers/objects.c: last_obj = orig_rb_newobj();
2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/newobj:rb_newobj()
2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/node/newnode: NODE *n = (NODE*)rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: prov = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: req = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: conf = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: obso = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/file.c: file = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj();
2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj();
2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.c: syd_scope = (struct SCOPE*)rb_newobj();
2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.y: syd_scope = (struct SCOPE*)rb_newobj();
```
--
https://bugs.ruby-lang.org/
Issue #20202 has been reported by matheusrich (Matheus Richard).
----------------------------------------
Feature #20202: Memoized endless method definitions
https://bugs.ruby-lang.org/issues/20202
* Author: matheusrich (Matheus Richard)
* Status: Open
* Priority: Normal
----------------------------------------
I propose introducing a shorthand for memoized endless method definitions:
```rb
class Foo
def bar ||= :memoized_value
# It should behave like
def bar = (@bar ||= :memoized_value)
end
```
Not only is this shorter and (IMO) a natural follow-up for endless method definitions, but it's also a common pattern on Ruby codebases. It's very useful to decompose responsibilities into several objects:
```rb
class User
def notifications_enabled? = settings.notifications?
def enable_notifications = (settings.notifications = true)
def disable_notifications = (settings.notifications = false)
private
def settings = @settings ||= Settings.new(self)
end
class User::Settings
attr_writer :notifications
def initialize(user)
@user = user
@notifications = false
end
def notifications? = @notifications
end
u = User.new
u.notifications_enabled? # => false
u.enable_notifications
u.notifications_enabled? # => true
```
In the example, the `settings` method could be rewritten as
```rb
def settings ||= Settings.new(self)
```
--
https://bugs.ruby-lang.org/
Issue #20293 has been reported by nobu (Nobuyoshi Nakada).
----------------------------------------
Feature #20293: Add `Warning.categories` method that returns the warning category names
https://bugs.ruby-lang.org/issues/20293
* Author: nobu (Nobuyoshi Nakada)
* Status: Open
----------------------------------------
I propose a new method `Warning.categories`.
This would be useful (or necessary) for tests mainly.
Currently, `EnvUtil.capture_global_values` saves the original warning settings as followings:
```ruby
@original_warning = defined?(Warning.[]) ? %i[deprecated experimental].to_h {|i| [i, Warning[i]]} : nil
```
But this is wrong now; `performance` is missing.
So we need:
```ruby
@original_warning = if defined?(Warning.[]) # 2.7+
%i[deprecated experimental performance].to_h do |i|
[i, begin Warning[i]; rescue ArgumentError; end]
end.compact
end
```
That means this list is version dependent and we will need to maintain this list in future.
We need another surefire way.
--
https://bugs.ruby-lang.org/
Issue #20224 has been reported by yui-knk (Kaneko Yuichiro).
----------------------------------------
Bug #20224: Backport https://github.com/ruby/ruby/pull/9634 to Ruby 3.3
https://bugs.ruby-lang.org/issues/20224
* Author: yui-knk (Kaneko Yuichiro)
* Status: Closed
* Priority: Normal
* Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED
----------------------------------------
It's nice if we can backport https://github.com/ruby/ruby/pull/9634 (3d19409637de1462b6790d2a92344bf0a10d8c52) to Ruby 3.3 branch.
Even so previous codes work as expected but it depends on how parse.c works and misleading.
--
https://bugs.ruby-lang.org/