August 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:114471] [Ruby master Bug#12500] TestProcess#test_aspawn_too_long_path fails on mips with "argument too big"
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #12500 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to handle this ArgumentError: https://github.com/ruby/ruby/pull/8270 ---------------------------------------- Bug #12500: TestProcess#test_aspawn_too_long_path fails on mips with "argument too big" https://bugs.ruby-lang.org/issues/12500#change-104244 * Author: zeha (Christian Hofstaedtler) * Status: Open * Priority: Normal * ruby -v: ruby 2.3.1p112 (2016-04-26) [mips-linux-gnu] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: REQUIRED ---------------------------------------- Recently in Debian we've enabled `make check` and this is one of the test failures we get for ruby2.3, on mips: ``` TestProcess#test_aspawn_too_long_path [/«PKGBUILDDIR»/test/ruby/test_process.rb:1602]: [ruby-core:34833] #7904 [ruby-core:52628] #11613. [Errno::ENOENT, Errno::E2BIG] exception expected, not. Class: <ArgumentError> Message: <"argument too big"> ---Backtrace--- /«PKGBUILDDIR»/test/ruby/test_process.rb:1619:in `*' /«PKGBUILDDIR»/test/ruby/test_process.rb:1619:in `block (3 levels) in assert_fail_too_long_path' /«PKGBUILDDIR»/test/ruby/test_process.rb:1616:in `loop' /«PKGBUILDDIR»/test/ruby/test_process.rb:1616:in `block (2 levels) in assert_fail_too_long_path' /«PKGBUILDDIR»/test/lib/test/unit/assertions.rb:74:in `assert_raise' /«PKGBUILDDIR»/test/ruby/test_process.rb:1614:in `block in assert_fail_too_long_path' /«PKGBUILDDIR»/test/lib/envutil.rb:159:in `suppress_warning' /«PKGBUILDDIR»/test/ruby/test_process.rb:1613:in `assert_fail_too_long_path' /«PKGBUILDDIR»/test/ruby/test_process.rb:1602:in `test_aspawn_too_long_path' /«PKGBUILDDIR»/test/lib/test/unit.rb:1018:in `run_test' --------------- ``` I think is caused by some array or string mangling code used by Process.spawn, but can't be sure. Please also backport any fixes for this to 2.3. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114470] [Ruby master Bug#14474] skip "TestException#test_thread_signal_location" as known bug
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14474 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This test has not been skipped since commit:5ec3450438150e7cb05422c04dc18901161a13ea in January 2022, and I don't think this has been a problem since, so I'm closing this. ---------------------------------------- Bug #14474: skip "TestException#test_thread_signal_location" as known bug https://bugs.ruby-lang.org/issues/14474#change-104243 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * ruby -v: 2.6 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- `TestException#test_thread_signal_location` fails randomly https://gist.github.com/ko1/797b0f058f2d09ae57c9af1ee07a42b2#file-brlog-tru… > `[BUG] pthread_mutex_lock: Invalid argument (EINVAL)` https://gist.github.com/ko1/df41bb11a19792a14417c9332e70171e#file-brlog-tru… > `[BUG] Segmentation fault at 0x0000000000000000` and so on. This test consists of signal, threads, termination process, and so on. I've tried to investigate but no idea. Additionally, it is hard to reproduce. To keep CI clean, I skip this test, file about this issue and wait for a person who can solve this issue. Thanks, Koichi -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114469] [Ruby master Bug#14422] Ruby configuration options should not be reused for gem builds
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14422 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed vo.x (Vit Ondruch) wrote in #note-8: > Unfortunately, this does not address the original issue. So is there any hope this will be improved upstream? I would like to avoid some rbconfig.rb hacks to remove the configuration flags in question. As @nobu stated in https://bugs.ruby-lang.org/issues/14422#note-1, use `XCFLAGS` and `XLDFLAGS` to specify options only for building Ruby, that you do not want used when building extensions. You implied you didn't want to do this, apparently without trying this approach. However, be aware that is the Ruby-supported way of supporting what you want. @nobu pointed out the issues with not using Ruby's `CFLAGS` or `LDFLAGS` by default when building Ruby extensions, so we definitely cannot make the behavior you are requesting the default as it would break things on other platforms. I don't think this is a general issue with building Ruby. If you are building packages for Ruby extensions, you should have all of Ruby's dependencies installed. If Fedora doesn't populate its buildroot with Ruby's dependencies when building packages for Ruby extensions, that does seem like a problem to be fixed in Fedora. I know not all packaging systems have Fedora's problem, because OpenBSD's packaging system does not. ---------------------------------------- Bug #14422: Ruby configuration options should not be reused for gem builds https://bugs.ruby-lang.org/issues/14422#change-104242 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When Fedora started to harden its packages, we quite often seen complains from our users about problems installing their gems, with errors such as [1]: ~~~ gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory ~~~ The issue as analyzed by Mamoru TASAKA is [2]: > Well, if I am not mistaken, the real problem here is that rpm's %optflags is always embedded into Fedora's ruby config file, that is > > /usr/lib64/ruby/rbconfig.rb:167: CONFIG["CXXFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic" > /usr/lib64/ruby/rbconfig.rb:171: CONFIG["CFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic -fPIC" > > on x86_64, for example. > > Although I am not sure this is already discussed somewhere or not, basically I think changing the default CFLAGS of "system" ruby like this way is undesirable and ? installed "rbconfig.rb" should have some "minimal" CFLAGS / CXXFLAGS. > ( for example, just like CONFIG["CFLAGS"] = "-fPIC" ) > > Only when we build Fedora gems or so (on koji), we should change CFLAGS / CXXFLAGS explicitly afterwards using %optflags. and Red Hat toolchain team responds [3]: > The current advice of the Red Hat toolchain team is to keep distribution build flags and toolchain default flags separate. This is why running “gcc” gives you the upstream defaults, and not the flags we use to compile Fedora packages. For consistency, Ruby (and other compilation support tools) follow this pattern: Use distribution flags when building for Fedora, but use upstream flags when the user compiles packages (i.e., what Ruby uses, probably something involving -O2). > > Our build flags are fully ABI-compatible with each other, so mismatches will not cause any problems at the C/C++/ABI level. The question is why Ruby does this and how we can avoid this behavior. We could force installation of redhat-rpm-config package, providing the "/usr/lib/rpm/redhat/redhat-hardened-cc1", to every ruby user, but that does not seems right. There are also other similar issues discussing this situation [4], [5]. Any thoughts? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c6 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c11 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1218294 [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1432191 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114468] [Ruby master Bug#14418] ruby 2.5 slow regexp execution
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14418 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Thanks to very impressive work by @makenowjust, this issue has been fixed in Ruby 3.2. ---------------------------------------- Bug #14418: ruby 2.5 slow regexp execution https://bugs.ruby-lang.org/issues/14418#change-104241 * Author: jakub.wozny (Kuba W) * Status: Closed * Priority: Normal * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- I have simple regexp that performing very slow. ~~~ ruby "fußball "*20 =~ /^([\S\s]{1000})/i ~~~ It works fast if I remove `/i` flag. I figured out that is also depends on string length or on quantifier value (in this case it is `{1000}`). When you remove `ß` form the string it also works fast. I tested on 2.3.1, 2.4.3 and 2.5.0. I'm not sure it is a bug or it just works that way. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114467] [Ruby master Bug#14064] test-all with and without -j - incorrect assertions and missing test methods
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14064 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed It looks like a fix for this was committed in commit:dd3851d2786412de019350a11e749c56fa5a07cc ---------------------------------------- Bug #14064: test-all with and without -j - incorrect assertions and missing test methods https://bugs.ruby-lang.org/issues/14064#change-104240 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0dev (2017-10-29 trunk 60531) [x64-mingw32] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- I always run test-all with a `-v` parameter, and although both Travis & Appveyor scripts do not, many of the https://rubyci.org builds seem to. With `-v`, one has a log of all test methods. For quite a while, I ran ruby-loco (MinGW trunk build) with `test-all` having no `-j` parameter. I've now changed to using `-j`, and I'm surprised at what I'm finding. When run without a `-j` parameter, the total test count is correct, but the total assertions count is high. When run with a `-j` parameter (even set to 1), the test count drops (along with tests not appearing in the log), and the total assertions count is correct. Often, whole test files (classes) disappear from the log. Re the test count variance, I wrote code to parse the logs (the total test count variance), which showed which test methods were present in non-parallel test logs that were missing in parallel test logs. As to the assertions, I ran test-all on a few single files, and added the assertion count to each test method line, then compared with and without `-j`. Finally, by checking individual methods for their respective number of assertions, it was clear that the numbers shown in a non-parallel run were high. At first, it seemed that they were high by a count of three, but that only held for a few files. First of all, I'm wondering if anyone else has found similar results. Secondly, I've spent some time verifying this, but I can't seem to find where the code needs corrections to function properly. I hoped it might be a timeout issue, but that doesn't seem to be the case. Hence, suggestions as to where to start are welcome. Finally, in Travis, the line for test-all is: ``` make -s $JOBS test-all -o exts TESTOPTS='-q --color=never --job-status=normal' ``` Using MinGW, adding $JOBS as a make parameter seems to have no effect. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114466] [Ruby master Bug#13571] Script arguments, encoding, windows / MinGW
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #13571 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Starting in Ruby 3.0, arguments provided to Ruby (in `ARGV`) are now in correct UTF-8 encoding. ---------------------------------------- Bug #13571: Script arguments, encoding, windows / MinGW https://bugs.ruby-lang.org/issues/13571#change-104237 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0dev (2017-05-17 trunk 58774) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- The following is windows/MinGW specific. I have been patching around a failure in [TestRubyOptions#test_command_line_progname_nonascii](https://github.com/rub… for a while, and decided to investigate further, assuming it was a simple issue. The following code - ```ruby # set dir to valid directory dir = "E:/temp" fn_1 = 'äÖü.rb' fn_2 = 'テスト.rb' puts puts "ENV['RUBYOPT'] #{ENV['RUBYOPT']}" \ "\nfilesystem #{Encoding.find('filesystem')}" \ "\nexternal #{Encoding.default_external}" \ "\n`chcp` #{`chcp`}" \ "locale #{Encoding.find('locale')}" \ "\n__ENCODING__ #{__ENCODING__}" \ "\ninternal #{Encoding.default_internal}\n" \ "\nfn_1 #{fn_1.encoding.to_s}" \ "\näÖü.rb #{'äÖü.rb'.encoding.to_s}" \ "\nfn_2 #{fn_2.encoding.to_s}" \ "\nテスト.rb #{'テスト.rb'.encoding.to_s}" Dir.chdir(dir) do |dir| open(fn_1, "w") { |f| f.puts "puts File.basename($0)" } open(fn_2, "w") { |f| f.puts "puts File.basename($0)" } puts puts "File.exist?(fn_1) #{File.exist?(fn_1)}" puts "File.exist?(fn_2) #{File.exist?(fn_2)}" puts puts `ruby #{fn_1}` puts `ruby #{fn_2}` end ``` produces the following output - ``` ENV['RUBYOPT'] filesystem Windows-1252 external IBM437 `chcp` Active code page: 437 locale IBM437 __ENCODING__ UTF-8 internal fn_1 UTF-8 äÖü.rb UTF-8 fn_2 UTF-8 テスト.rb UTF-8 File.exist?(fn_1) true File.exist?(fn_2) true äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT) ruby: Invalid argument -- ???.rb (LoadError) ``` Of note is that both files are created (and appear correctly in Explorer), but neither can be used as a script argument. Copy and pasting the names (from Explorer) on the command line produces the following similar output - ``` E:\temp>ruby äÖü.rb äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT) E:\temp>ruby テスト.rb ruby: Invalid argument -- ???.rb (LoadError) ``` Lastly, if before running the code I do a `chcp 1252` command to match up 'locale' and 'filesystem', the first script file runs and produces the correct output. Hence, it appears that some (or all?) `File` methods deal properly with `filesystem` encoding, but ruby script arguments are not correctly encoded. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114465] [Ruby master Bug#13269] test/readline/test_readline.rb and mingw
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #13269 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed The readline extension was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream: https://github.com/ruby/readline-ext ---------------------------------------- Bug #13269: test/readline/test_readline.rb and mingw https://bugs.ruby-lang.org/issues/13269#change-104233 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.5.0dev (2017-03-02 trunk 57755) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- When running test-all on a mingw build, [`test_readline.rb`](https://github.com/ruby/ruby/blob/trunk/test/readline/test_readline.rb) generates failures and errors. Several of the errors are due to the `with_temp_stdio` method in `test_readline.rb`. It also leaves several undeleted files in the temp dir. Current link is: [TestReadline#with_temp_stdio](https://github.com/ruby/ruby/blob/trunk/test/… The current code is: ```ruby def with_temp_stdio Tempfile.create("test_readline_stdin") {|stdin| Tempfile.create("test_readline_stdout") {|stdout| yield stdin, stdout } } end ``` Replacing it with the following solved the problems. ```ruby def with_temp_stdio stdin = Tempfile.new("test_readline_stdin") stdout = Tempfile.new("test_readline_stdout") yield stdin, stdout if stdout stdout.closed? ? stdout.unlink : stdout.close! end if stdin stdin.closed? ? stdin.unlink : stdin.close! end end ``` I can only test on Windows, but I assume the changed code would work on other os's. If someone could test it, I'd submit a PR. Maybe the code in `Tempfile::Remover` is really where the change should occur, but I haven't looked at that. After this update, I only had one failure and three errors. Text below. Odd thing for two errors it that they report `NoMethodError: undefined method assert_separately`, but the highlighted line is `return if assert_under_utf8`. I didn't do an exhaustive search, but I can't find a reference to that function. But, I'm pulling the test files out of ruby and running separately... ``` Failure: test_input_metachar(TestReadline) D:/r_test/Readline/test_readline.rb:420:in `test_input_metachar' 417: wo = w.dup 418: wo.write("\C-re\ef\n") 419: end => 420: assert_equal("hello", line, bug6601) 421: ensure 422: wo.close 423: Readline.delete_text [ruby-core:45682] <"hello">(UTF-8) expected but was <"hfello">(IBM437) diff: ? hfello ? Encoding: UTF-8 ? IBM437 ==================================================================================================================================================== Error: test_input_metachar_multibyte(TestReadline): NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcfef0> Did you mean? assert_empty D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8' D:/r_test/Readline/test_readline.rb:429:in `test_input_metachar_multibyte' 426: 427: def test_input_metachar_multibyte 428: unless Encoding.find("locale") == Encoding::UTF_8 => 429: return if assert_under_utf8 430: skip 'this test needs UTF-8 locale' 431: end 432: bug6602 = '[ruby-core:45683]' ==================================================================================================================================================== Error: test_refresh_line(TestReadline): NoMethodError: undefined method `assert_ruby_status' for #<TestReadline:0x00000003bcf6f8> Did you mean? assert_raises D:/r_test/Readline/test_readline.rb:459:in `block (2 levels) in test_refresh_line' 456: bug6232 = '[ruby-core:43957] [Bug #6232] refresh_line after set_screen_size' 457: with_temp_stdio do |stdin, stdout| 458: replace_stdio(stdin.path, stdout.path) do => 459: assert_ruby_status(%w[-rreadline -], <<-'end;', bug6232) 460: Readline.set_screen_size(40, 80) 461: Readline.refresh_line 462: end; D:/r_test/Readline/test_readline.rb:567:in `block (2 levels) in replace_stdio' D:/r_test/Readline/test_readline.rb:557:in `open' D:/r_test/Readline/test_readline.rb:557:in `block in replace_stdio' D:/r_test/Readline/test_readline.rb:556:in `open' D:/r_test/Readline/test_readline.rb:556:in `replace_stdio' D:/r_test/Readline/test_readline.rb:458:in `block in test_refresh_line' D:/r_test/Readline/test_readline.rb:583:in `with_temp_stdio' D:/r_test/Readline/test_readline.rb:457:in `test_refresh_line' ==================================================================================================================================================== Error: test_using_quoting_detection_proc_with_multibyte_input(TestReadline): NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcf2c0> Did you mean? assert_empty D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8' D:/r_test/Readline/test_readline.rb:517:in `test_using_quoting_detection_proc_with_multibyte_input' 514: saved_completer_word_break_characters = Readline.completer_word_break_characters 515: return unless Readline.respond_to?(:quoting_detection_proc=) 516: unless Encoding.find("locale") == Encoding::UTF_8 => 517: return if assert_under_utf8 518: skip 'this test needs UTF-8 locale' 519: end 520: ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112399] [Ruby master Bug#19436] Call Cache for singleton methods can lead to "memory leaks"
by byroot (Jean Boussier) 23 Aug '23

23 Aug '23

Issue #19436 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19436: Call Cache for singleton methods can lead to "memory leaks" https://bugs.ruby-lang.org/issues/19436 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Using "memory leaks" with quotes, because strictly speaking the memory isn't leaked, but it can nonetheless lead to large memory overheads. ### Minimal Reproduction ```ruby module Foo def bar end end def call_bar(obj) # Here the call cache we'll keep a ref on the method_entry # which then keep a ref on the singleton_class, making that # instance immortal until the method is called again with # another instance. # The reference chain is IMEMO(callcache) -> IMEMO(ment) -> ICLASS -> CLASS(singleton) -> OBJECT obj.bar end obj = Object.new obj.extend(Foo) call_bar(obj) id = obj.object_id obj = nil 4.times { GC.start } p ObjectSpace._id2ref(id) ``` ### Explanation Call caches keep a strong reference onto the "callable method entry" (CME), which itself keeps a strong reference on the called object class and in the cache of a singleton class, it keeps a strong reference onto the `attached_object` (instance). This means that any call site that calls a singleton method, will effectively keep a strong reference onto the last receiver. If the method is frequently called it's not too bad, but if it's infrequently called, it's effectively a (bounded) memory leak. And if the `attached_object` is big, the wasted memory can be very substantial. ### Practical Implications Once relative common API impacted by this is [Rails' `extending` API](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#met…. This API allow to extend a "query result set" with a module. These query results set can sometimes be very big, especially since they keep references to the instantiated `ActiveRecord::Base` instances etc. ### Possible Solutions #### Only keep a weak reference to the CME The fairly "obvious" solution is to keep a weak reference to the CME, that's what I explored in https://github.com/ruby/ruby/pull/7272, and it seems to work. However in debug mode It does fail on an assertion during compaction, but it's isn't quite clear to me what the impact is. Additionally, something that makes me think this would be the right solution, is that call caches already try to avoid marking the class: ```c # vm_callinfo.h:275 struct rb_callcache { const VALUE flags; /* inline cache: key */ const VALUE klass; // should not mark it because klass can not be free'd // because of this marking. When klass is collected, // cc will be cleared (cc->klass = 0) at vm_ccs_free(). ``` So it appears that the class being also marked through the CME is some kind of oversight? #### Don't cache based on some heuristics If the above isn't possible or too complicated, an alternative would be to not cache CMEs found in singleton classes, except if it's the the singleton class of a `Class` or `Module`. It would make repeated calls to such methods slower, but the assumption is that it's unlikely that these CME would live very long. #### Make `Class#attached_object` a weak reference Alternatively we could make the `attached_object` a weak reference, which would drastically limit the amount of memory that may be leaked in such scenario. The downside is that `Class#attached_object` was very recently exposed in Ruby 3.2.0, so it means changing its semantic a bit. cc @peterzhu2118 @ko1 -- https://bugs.ruby-lang.org/

8 24

[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