- ruby-core - ml.ruby-lang.org

[ruby-core:114290] [Ruby master Feature#19785] Deprecate `RUBY_GC_HEAP_INIT_SLOTS `
by peterzhu2118 (Peter Zhu) 23 Aug '23

23 Aug '23

Issue #19785 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19785: Deprecate `RUBY_GC_HEAP_INIT_SLOTS ` https://bugs.ruby-lang.org/issues/19785 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/8116 The `RUBY_GC_HEAP_INIT_SLOTS` environment variable is replaced by `RUBY_GC_HEAP_INIT_SIZE_%d_SLOTS` (introduced in commit [3ab3455](https://github.com/ruby/ruby/commit/3ab34551450c7a3a3e1ae0b24bf6b7…) which allows for more fine-grained tuning of size pools. So it doesn't make sense to keep the environment variable `RUBY_GC_HEAP_INIT_SLOTS`. I'm proposing to deprecate `RUBY_GC_HEAP_INIT_SLOTS` and eventually remove it. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114461] [Ruby master Bug#10416] Create mechanism for updating of Unicode data files downstreams when we want
by duerst 23 Aug '23

23 Aug '23

Issue #10416 has been updated by duerst (Martin Dürst). The next version of Unicode (15.1) will be released in about 3 weeks. I'll check at that point, and close if no longer relevant. ---------------------------------------- Bug #10416: Create mechanism for updating of Unicode data files downstreams when we want https://bugs.ruby-lang.org/issues/10416#change-104227 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.2.0dev (2014-10-22 trunk 48092) [x86_64-cygwin] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- The current mechanism for updating Unicode data files will create the following problem: Downstream compilers/packagers will download Unicode data files ONE time (they may already have done so). However, if they don't activate ALWAYS_UPDATE_UNICODE = yes, these files will never get updated, and they will stay on Unicode version 7.0 even if in five years Unicode is e.g. on version 12.0. On the other hand, if they activate ALWAYS_UPDATE_UNICODE = yes (and assuming issue #10415 gets fixed), they constantly update to the latest version of Unicode. That's good for those who actually want this, but now what our current policy is. What's missing is that we (Ruby core) can make sure downstream checkouts update to a new Unicode version when we want then to do so (as we e.g. can do for other parts that are based on Unicode data, see e.g. https://bugs.ruby-lang.org/issues/9092) without sending an email to everybody and hoping they read and follow it. [Currently, the only solution I know will work is the one pointed out by Yui Naruse in https://bugs.ruby-lang.org/issues/10084#note-17, but I'm okay with any other solution.] -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114460] [Ruby master Bug#19005] Ruby interpreter compiled XCode 14 cannot build some native gems on macOS
by stanhu (Stan Hu) 23 Aug '23

23 Aug '23

Issue #19005 has been updated by stanhu (Stan Hu). We can close this now that XCode 14.3, which ships with clang 14.0.3, now fixes this issue: https://github.com/python/cpython/issues/97524#issuecomment-1458855301 ---------------------------------------- Bug #19005: Ruby interpreter compiled XCode 14 cannot build some native gems on macOS https://bugs.ruby-lang.org/issues/19005#change-104223 * Author: stanhu (Stan Hu) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.6p219 (2022-04-12 revision 44c8bfa984) [arm64-darwin21] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- This seems related to https://bugs.ruby-lang.org/issues/18912 and https://bugs.ruby-lang.org/issues/18981 . Steps to reproduce: 1. Upgrade to XCode 14. 2. Compile a new Ruby interpreter. I used the version provided in https://github.com/ruby/ruby/pull/6297 with `./configure --prefix=/tmp/ruby --with-openssl-dir=$(brew --prefix openssl(a)1.1) --with-readline-dir=$(brew --prefix readline) --enable-shared`. 3. Confirm that `-Wl,-undefined,dynamic_lookup` is no longer available: ``` irb(main):001:0> RbConfig::CONFIG['DLDFLAGS'] => "-Wl,-multiply_defined,suppress" ``` 4. Ran `gem install pg_query` (`gem install ffi-yajl` will also fail). Error: ``` linking shared-object pg_query/pg_query.bundle Undefined symbols for architecture arm64: "Init_pg_query", referenced from: -exported_symbol[s_list] command line option (maybe you meant: _Init_pg_query) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` I can workaround the problem by doing: ``` gem install pg_query -- --with-ldflags="-Wl,-undefined,dynamic_lookup" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114274] [Ruby master Feature#19783] Weak References in the GC
by peterzhu2118 (Peter Zhu) 23 Aug '23

23 Aug '23

Issue #19783 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19783: Weak References in the GC https://bugs.ruby-lang.org/issues/19783 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/8113 I'm proposing support for weak references in the Ruby garbage collector. This feature adds a new function called `void rb_gc_mark_weak(VALUE *ptr)` which marks `*ptr` as weak, meaning that if no other object strongly marks `*ptr` (using `rb_gc_mark` or `rb_gc_mark_movable`), then it will be overwritten with `*ptr = Qundef`. Weak references are implemented using a buffer in `objspace` that stores all the `ptr` in the latest marking phase. After marking has finished, we iterate over the buffer and check if the `*ptr` is a dead object. If it is, then we set `*ptr = Qundef`. Weak references are implemented on the callable method entry (CME) of callcaches, which fixes issue #19436. Weak references are also implemented on `ObjectSpace::WeakMap` and `ObjectSpace::WeakKeyMap`, which have: - Significantly simpler implementations because we no longer need to have multiple tables and do not need to define finalizers on the objects. - Support for compaction because finalizers pin objects and we no longer need to define finalizers on the objects. - Much faster performance (see [benchmarks](#microbenchmarks)). ## Benchmark results ### YJIT-bench We see largely no change in performance or memory usage after this feature. ``` -------------- --------- ---------- --------- ----------- ---------- --------- -------------- ----------- bench base (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr base/branch activerecord 72.3 2.2 51.9 72.9 2.2 51.9 0.99 0.99 chunky-png 889.2 0.3 43.9 874.5 0.3 42.5 1.02 1.02 erubi-rails 21.2 13.5 90.7 21.0 13.3 90.9 1.01 1.01 hexapdf 2557.0 0.8 157.1 2559.2 0.7 197.1 1.01 1.00 liquid-c 65.2 0.4 34.5 65.4 0.4 34.5 0.99 1.00 liquid-compile 62.5 0.4 30.9 62.2 0.4 31.0 1.00 1.01 liquid-render 164.6 0.4 33.1 162.6 0.3 33.1 1.01 1.01 mail 133.3 0.1 46.4 134.4 0.2 46.4 1.03 0.99 psych-load 2066.6 0.2 31.6 2083.6 0.1 31.6 0.99 0.99 railsbench 2027.0 0.5 88.8 2019.4 0.5 89.0 1.01 1.00 ruby-lsp 65.6 3.0 90.1 65.4 3.1 88.5 1.00 1.00 sequel 73.1 1.1 36.6 73.1 1.1 36.6 1.00 1.00 -------------- --------- ---------- --------- ----------- ---------- --------- -------------- ----------- ``` ### Microbenchmarks We can see signficantly improved performance in `ObjectSpace::WeakMap`, with `ObjectSpace::WeakMap#[]=` being nearly 3x faster. Base: ``` ObjectSpace::WeakMap#[]= 1.037M (± 0.5%) i/s - 5.262M in 5.072833s ObjectSpace::WeakMap#[] 12.367M (± 0.9%) i/s - 62.479M in 5.052365s ``` Branch: ``` ObjectSpace::WeakMap#[]= 3.054M (± 0.3%) i/s - 15.448M in 5.058783s ObjectSpace::WeakMap#[] 15.796M (± 4.8%) i/s - 79.245M in 5.028583s ``` Code: ```ruby require "bundler/inline" gemfile do source "https://rubygems.org" gem "benchmark-ips" end wmap = ObjectSpace::WeakMap.new key = Object.new val = Object.new wmap[key] = val Benchmark.ips do |x| x.report("ObjectSpace::WeakMap#[]=") do |times| i = 0 while i < times wmap[Object.new] = Object.new i += 1 end end x.report("ObjectSpace::WeakMap#[]") do |times| i = 0 while i < times wmap[key] wmap[val] # does not exist i += 1 end end end ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114453] [Ruby master Feature#14579] Hash value omission
by olivierlacan (Olivier Lacan) 22 Aug '23

22 Aug '23

Issue #14579 has been updated by olivierlacan (Olivier Lacan). Has it been considered to ever expand this feature to allow instance variables and global variables. Or was it strictly reserved for local variables intentionally, to avoid incompatible or dangerous behavior? Thanks for adding this regardless, it's a wonderful feature. ---------------------------------------- Feature #14579: Hash value omission https://bugs.ruby-lang.org/issues/14579#change-104215 * Author: shugo (Shugo Maeda) * Status: Closed * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How about to allow value omission in Hash literals: ```ruby x = 1 y = 2 h = {x:, y:} p h #=> {:x=>1, :y=>2} ``` And in keyword arguments: ```ruby def login(username: ENV["USER"], password:) p(username:, password:) end login(password: "xxx") #=> {:username=>"shugo", :password=>"xxx"} ``` ---Files-------------------------------- hash_value_omission.diff (619 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114452] [Ruby master Bug#12725] Trying to use ./miniruby before it exists
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #12725 has been updated by jeremyevans0 (Jeremy Evans). @duerst Have you seen this issue reoccur since it was initially posted? If not, do you think this can be closed? ---------------------------------------- Bug #12725: Trying to use ./miniruby before it exists https://bugs.ruby-lang.org/issues/12725#change-104214 * Author: duerst (Martin Dürst) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.4.0dev (2016-09-05 trunk 56071) [x86_64-cygwin] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- ---Files-------------------------------- bug12725.txt (6.08 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114451] [Ruby master Bug#11526] Streaming HTTP requests are not idempotent and should not be retried
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #11526 has been updated by jeremyevans0 (Jeremy Evans). A fix for this has been submitted as an upstream pull request: https://github.com/ruby/net-http/pull/87 ---------------------------------------- Bug #11526: Streaming HTTP requests are not idempotent and should not be retried https://bugs.ruby-lang.org/issues/11526#change-104213 * Author: tdg5 (Danny Guinther) * Status: Assigned * Priority: Normal * Assignee: naruse (Yui NARUSE) * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Hello! A colleague of mine ran into an issue today where he discovered that streaming HTTP requests made with Net::HTTP would retry some types of errors without giving any indication that an error had occurred and the request stream had been rewound. This ultimately resulted in a response body that contained an incomplete response followed by the complete response body. I think when the request is being streamed it cannot be considered idempotent because there's no telling what sort of side effects might occur in the block that the response chunk is yielded to. I've attached a diff and will create a GitHub PR shortly that aims to deal with this behavior by only retrying the request if a block is not given. That said, I suspect this issue warrants further discussion. We are not the first to run into this issue. One of the developers of the aws-sdk gem ran into this same issue in the last 6 months and chose to handle the issue by clearing out the IDEMPOTENT_METHODS_ collection such that no requests would automatically retry. This seems like overkill to me, but makes sense for a minimally evasive monkeypatch. The author of that patch, Trevor Rowe, suggested that he would create an issue here, but I have been unable to find such an issue. The related aws-sdk GitHub issue: https://github.com/aws/aws-sdk-ruby/pull/799 The related aws-sdk GitHub commit: https://github.com/aws/aws-sdk-ruby/commit/5a005974afcda0ec0c8e9332bed4c70a… If I can provide any further information on this matter, please let me know. Thanks in advance for any and all help! ---Files-------------------------------- no_retry_http_streams.diff (2.3 KB) trowe-net-http-idempotent-retry-fix.diff (6.52 KB) trowe-net-http-idempotent-retry-fix-with-test-fixes.diff (7.42 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114450] [Ruby master Bug#10416] Create mechanism for updating of Unicode data files downstreams when we want
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #10416 has been updated by jeremyevans0 (Jeremy Evans). @duerst Do you think this can be closed? ---------------------------------------- Bug #10416: Create mechanism for updating of Unicode data files downstreams when we want https://bugs.ruby-lang.org/issues/10416#change-104209 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.2.0dev (2014-10-22 trunk 48092) [x86_64-cygwin] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- The current mechanism for updating Unicode data files will create the following problem: Downstream compilers/packagers will download Unicode data files ONE time (they may already have done so). However, if they don't activate ALWAYS_UPDATE_UNICODE = yes, these files will never get updated, and they will stay on Unicode version 7.0 even if in five years Unicode is e.g. on version 12.0. On the other hand, if they activate ALWAYS_UPDATE_UNICODE = yes (and assuming issue #10415 gets fixed), they constantly update to the latest version of Unicode. That's good for those who actually want this, but now what our current policy is. What's missing is that we (Ruby core) can make sure downstream checkouts update to a new Unicode version when we want then to do so (as we e.g. can do for other parts that are based on Unicode data, see e.g. https://bugs.ruby-lang.org/issues/9092) without sending an email to everybody and hoping they read and follow it. [Currently, the only solution I know will work is the one pointed out by Yui Naruse in https://bugs.ruby-lang.org/issues/10084#note-17, but I'm okay with any other solution.] -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114449] [Ruby master Bug#9435] Kernel.system problem
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #9435 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Rejected I don't think this is a bug in Ruby, it is a general issue with Windows. As @nobu mentioned, you shouldn't use quotes in `PATH`. See https://serverfault.com/questions/349179/path-variable-and-quotation-marks-… ---------------------------------------- Bug #9435: Kernel.system problem https://bugs.ruby-lang.org/issues/9435#change-104206 * Author: windwiny (wind winy) * Status: Rejected * Priority: Normal * ruby -v: 2.0.0 ---------------------------------------- if ENV['PATH'] include double quotes, Kernel.system cann't find it. windows OS, open a cmd window ``` set PATH="C:\Program Files\7-Zip";%PATH% 7z -h # can run it pry system '7z -h' # can't find ``` and, if command include double quotes, system can't find too. ``` system '"C:\Program Files\7-Zip\7z" -h' # ok system '"C:\Program Files\7-Zip"\7z -h' # can't find system '"C:\Program Files\7-Zip\"7z -h' # can't find ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114448] [Ruby master Bug#7859] Readline: Incorrect arrow key behavior in vi_editing_mode insert mode with Readline 6.2
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23

Issue #7859 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed Readline was removed from Ruby in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream: https://github.com/ruby/readline/issues ---------------------------------------- Bug #7859: Readline: Incorrect arrow key behavior in vi_editing_mode insert mode with Readline 6.2 https://bugs.ruby-lang.org/issues/7859#change-104204 * Author: davidbalbert (David Albert) * Status: Closed * Priority: Normal * Assignee: kouji (Kouji Takao) * ruby -v: 2.0.0-rc2 ---------------------------------------- =begin I've discovered what I think is a bug in the (({Readline})) module in the standard library. When I am using (({vi_editing_mode})) in insert mode (rather than command mode), I am unable to use the up arrow to go up through history. It seems that I can only go up through history when in command mode. Additionally, pressing the down arrow while in insert mode changes to command mode, which seems odd. Perhaps this is intended behavior for the (({Readline})) module, but if it is, I would propose changing it. I would expect the up and down arrows to scroll up and down through history in both command mode and insert mode when (({Readline.vi_editing_mode?})) is true. You can find examples of the expected behavior in bash (`((%set -o vi%))` to get into vi mode), the Python REPL, and all other that I can remember using. I've reproduced this with (({Readline})) 6.2 on Mac OS X 10.8.2 and Ubuntu precise64 with kernel version 3.2.0-37. It is worth noting that on Mac OS X with the EditLine wrapper, the (({Readline})) module works correctly although you must have the proper settings in your .editrc file because (({Readline.vi_editing_mode})) is not implemented. Here is the code I used to test: # readlinetest.rb require 'readline' trap(:INT) { exit 0 } Readline.vi_editing_mode puts "Readline::VERSION => #{Readline::VERSION}" loop do puts Readline.readline(">> ", true) end Example usage: $ ruby readlinetest.rb Readline::VERSION => 6.2 >> 1234 1234 >> At this point, I would expect that the up arrow would put 1234 after the prompt, but instead nothing happens. Pressing the down arrow is the same as pressing escape and changes (({readline})) into command mode. Let me know if there's anything else I can provide to help fix this. I tried jumping into the (({Readline})) module myself, but I'm not particularly familiar with how (({readline})) works and wasn't able to make much headway. =end -- https://bugs.ruby-lang.org/

1 0