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

[ruby-core:113438] [Ruby master Bug#16185] basictest failure on AIX 6.1 for 64bit build
by headius (Charles Nutter) 10 May '23

10 May '23

Issue #16185 has been updated by headius (Charles Nutter). A note just from poking around here... I'm guessing this is due to the reporter's system using a filesystem encoding that uses wide characters, and the Ruby version tested is not handling it well. This issue against Python's pip seems similar: https://github.com/pypa/pip/issues/10858 I know that CRuby has in the past had some bugs around peculiar or non-standard filesystem encodings, like UTF-16 with its wide characters. This may be fixed in more recent versions, but as @jeremyevans0 points out we're pretty far past the AIX freshness date and I would not know how to even confirm this bug, much less fix it if still broken. ---------------------------------------- Bug #16185: basictest failure on AIX 6.1 for 64bit build https://bugs.ruby-lang.org/issues/16185#change-103010 * Author: Reshma (Reshma Kumar) * Status: Open * Priority: Normal * Assignee: kanemoto (Yutaka Kanemoto) * ruby -v: 2.6.3 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- We are building ruby 2.6.3(both 32 and 64bit) on AIX 6.1. The build options used for 64bit build are:- export LDFLAGS="-L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/usr/lib:/lib" and for 32bit build are:- export LDFLAGS="-L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib:/usr/lib:/lib -Wl,-bmaxdata:0x80000000" The testcase fails with the following error for 64bit whereas it passes for 32bit $ ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./basictest/runner.rb" --run-opt=--disable-gems /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:system \exec(): 0509-036 Cannot load program sh because of the following errors: 0509-150 Dependent module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3 could not be loaded. 0509-022 Cannot load module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3. 0509-026 System error: Cannot run a file that does not have a valid format. F|exec(): 0509-036 Cannot load program sh because of the following errors: 0509-150 Dependent module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3 could not be loaded. 0509-022 Cannot load module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3. 0509-026 System error: Cannot run a file that does not have a valid format. F|Traceback (most recent call last): 1: from /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2022:in `<main>' /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2022:in `unlink': No such file or directory @ apply2files - script_tmp.13762634.bak (Errno::ENOENT) not ok system 2 -- /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:1975:in `<main>' not ok system 8 -- /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2019:in `<main>' test failed Any idea what is the issue? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113437] [Ruby master Bug#16185] basictest failure on AIX 6.1 for 64bit build
by jeremyevans0 (Jeremy Evans) 10 May '23

10 May '23

Issue #16185 has been updated by jeremyevans0 (Jeremy Evans). Does this issue still occur with the master branch? Does it occur with a supported version of AIX? AIX 6.1 went out of support in April 2017 (https://www.ibm.com/support/pages/aix-support-lifecycle-information) so unless this is still an issue in a supported version of AIX, I think we should close this. ---------------------------------------- Bug #16185: basictest failure on AIX 6.1 for 64bit build https://bugs.ruby-lang.org/issues/16185#change-103009 * Author: Reshma (Reshma Kumar) * Status: Open * Priority: Normal * Assignee: kanemoto (Yutaka Kanemoto) * ruby -v: 2.6.3 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- We are building ruby 2.6.3(both 32 and 64bit) on AIX 6.1. The build options used for 64bit build are:- export LDFLAGS="-L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/usr/lib:/lib" and for 32bit build are:- export LDFLAGS="-L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib:/usr/lib:/lib -Wl,-bmaxdata:0x80000000" The testcase fails with the following error for 64bit whereas it passes for 32bit $ ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./basictest/runner.rb" --run-opt=--disable-gems /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:system \exec(): 0509-036 Cannot load program sh because of the following errors: 0509-150 Dependent module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3 could not be loaded. 0509-022 Cannot load module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3. 0509-026 System error: Cannot run a file that does not have a valid format. F|exec(): 0509-036 Cannot load program sh because of the following errors: 0509-150 Dependent module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3 could not be loaded. 0509-022 Cannot load module /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/libruby.so.2.6.3. 0509-026 System error: Cannot run a file that does not have a valid format. F|Traceback (most recent call last): 1: from /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2022:in `<main>' /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2022:in `unlink': No such file or directory @ apply2files - script_tmp.13762634.bak (Errno::ENOENT) not ok system 2 -- /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:1975:in `<main>' not ok system 8 -- /home/buildusr/rpmbuild/BUILD/ruby-2.6.3/64bit/basictest/test.rb:2019:in `<main>' test failed Any idea what is the issue? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113436] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by janosch-x 09 May '23

09 May '23

Issue #18368 has been updated by janosch-x (Janosch Müller). This is a cool improvement! I think it's fine to keep the special String behavior, and maybe that of Symbols. These special cases are not counterintuitive as there is no naturally intuitive way for them to behave. The burden on the language also looks manageable as it seems unlikely that a lot of complexity will be built on top of this part in particular. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-103008 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112398] [Ruby master Feature#19435] Expose counts for each GC reason in GC.stat
by byroot (Jean Boussier) 09 May '23

09 May '23

Issue #19435 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19435: Expose counts for each GC reason in GC.stat https://bugs.ruby-lang.org/issues/19435 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context We recently tuned the GC settings on our monolith application because we were seeing some very long GC pauses (multiple seconds) during some requests. Very early we realized that we could know how often the GC was triggered, and how long it was taking, but we had no information as to why, hence no good way to know which specific configuration to tune. As of today, the only way to get this information is to compile Ruby with debug counters, but that's not really accessible for most users, and not very suitable to be deployed in production. So we patched our Ruby to expose counters for each specific reason in `GC.stat` and this data was extremely valuable. For instance we discovered that the number 1 cause of major GC was `shady` objects, which allowed us to both better tune or GC and to drive some targeted patches to Ruby. ### Proposal We'd like to merge the patch we used on our Ruby build. It expose 8 new keys in `GC.stat`: - `:major_gc_nofree_count` - `:major_gc_oldgen_count` - `:major_gc_shady_count` - `:major_gc_newobj_count` - `:major_gc_malloc_count` - `:major_gc_oldmalloc_count` - `:minor_gc_newobj_count` - `:minor_gc_malloc_count` Some very uncommon reasons like `force` etc are ignored as they're not valuable. Also note that sometimes multiple conditions can be met to trigger GC, in such case we my increment several counters, so the sum of `major_gc_*_count` can be higher than `major_gc_count`. Proposed patch: https://github.com/ruby/ruby/pull/7250 -- https://bugs.ruby-lang.org/

6 9

[ruby-core:113419] You have [13] pending incoming emails
by mail.ml.ruby-lang.org 08 May '23

08 May '23

1 0

[ruby-core:113221] [Ruby master Misc#19597] Process.argv0 returns the same mutable String
by andrykonchin (Andrew Konchin) 08 May '23

08 May '23

Issue #19597 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #19597: Process.argv0 returns the same mutable String https://bugs.ruby-lang.org/issues/19597 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal ---------------------------------------- `Process.argv0` returns a name of the script being executed. But it seems it's always the same object, that can be modified and this change will be visible to the consequent `Process.argv0` calls. It makes sense to return a frozen String that cannot be modified. `$0` initial value equals a value returned by `Process.argv0` so `$0` by default also could be a frozen String. Example: ```ruby puts "Object id:" p Process.argv0.object_id p Process.argv0.object_id puts "Value before modification:" p Process.argv0 Process.argv0.upcase! puts "Value after modification:" p Process.argv0 ``` It will output: ``` Object id: 60 60 Value before modification: "argv0.rb" Value after modification: "ARGV0.RB" ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:113404] [Ruby master Bug#19629] Fix for CVE-2023-28755 breaks "puppet apply" run
by ManuelKiessling 06 May '23

06 May '23

Issue #19629 has been reported by ManuelKiessling (Manuel Kießling). ---------------------------------------- Bug #19629: Fix for CVE-2023-28755 breaks "puppet apply" run https://bugs.ruby-lang.org/issues/19629 * Author: ManuelKiessling (Manuel Kießling) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- (Not neccessarily a bug in Ruby - chances are I should have formatted my Puppet file URIs differently from the get-go.) However, since yesterday I'm getting these errors when running `puppet apply`: Could not evaluate: Could not retrieve file metadata for puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades: Failed to open TCP connection to :8140 (Connection refused - connect(2) for "" port 8140) I think the reason this happens now in an otherwise completely unchanged environment is that on my Ubuntu system, a new ruby2.7 package has been installed, due to CVE-2023-28755. See http://changelogs.ubuntu.com/changelogs/pool/main/r/ruby2.7/ruby2.7_2.7.0-5… for the backport info. The patch info (URI.parse should set empty string in host instead of nil in lib/uri/rfc3986_parser.rb, raise ArgumentError with empty host url again in lib/net/http/generic_request.rb.) sounds exactly like the reason I'm suddenly running into this error: `puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades` is an URI with an empty hostname - or is it? It's actually meant to refer to a local file, not a file on remote host ""; however, this is how it now seems to be interpreted: protocol `puppet`, hostname ``, path `/modules/unattended_upgrades...`. Because the patched code now returns `""` for the hostname instead of `nil`, it tries to do a hostname lookup for `""` which of course fails. Not sure if this is an intended consequence of the patch in this specific context, which is why I'm reporting it. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113308] [Ruby master Bug#19611] Ruby hangs up with `while true && true`
by tompng (tomoya ishida) 06 May '23

06 May '23

Issue #19611 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19611: Ruby hangs up with `while true && true` https://bugs.ruby-lang.org/issues/19611 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [x86_64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Fails to run this code. It hangs up. Ctrl+C does not work. ~~~ruby def hoge while true && true end end ~~~ Compiling `while true && true; end` will also hangs up ~~~ruby irb(main):001:0> RubyVM::InstructionSequence.compile 'while true && true; end'; puts :done (no response) ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:113403] [Ruby master Feature#19015] Language extension by a heredoc
by pyromaniac (Arkadiy Zabazhanov) 04 May '23

04 May '23

Issue #19015 has been updated by pyromaniac (Arkadiy Zabazhanov). @duerst It is funny you asked cause I just found this > [Kernel] Support for multi-letter uppercase sigils here https://hexdocs.pm/elixir/main/changelog.html We can definitely start doing this right from the beginning. Also, from my experience, even 1-letter sigils are not causing any issues but simplifying code reading/writing a lot. ---------------------------------------- Feature #19015: Language extension by a heredoc https://bugs.ruby-lang.org/issues/19015#change-102974 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- This propose new heredoc extension with `<<!LANG` like ```ruby doc = <<!LANG # description written in lang LANG foo bar LANG ``` and it is translated to: ```ruby doc = heredoc_extension_LANG(heredoc_text, binding) ``` ## Example ```ruby require 'erb' def heredoc_extension_erb str, b ERB.new(str).run(b) end name = 'ko1' html = <<!erb <div>Hello <%= name %></div> erb puts html #=> <div>Hello ko1</div> ``` ## Background / considerations * Sometimes we write Ruby syntax string with `<<RUBY` and this proposal inspired by it. * it is similar to shebang (`#!LANG` in shell) * [Elixir's custom sigil](https://elixir-lang.org/getting-started/sigils.html) translates `~u(...)` translates to `sigil_u(...)`. This is why it translated to `heredoc_extension_LANG(...)` private method call. * JavaScript has JSX but I don't think it is fit to the Ruby language. * Heredoc is Ruby's chaos part and already confusing a lot. Additional chaos doesn't matter. * `<<!foo` is valid syntax but now I don't think it is not used. gem codesearch doesn't find the usage. * Sorry I couldn't wait 1st/Apr. ## Implementation I attached the experimental implementation which only supports `erb` (because I couldn't find how to get delimiter to determine a method name :p). ---Files-------------------------------- heredoc_extension.patch (2.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113402] [Ruby master Feature#19015] Language extension by a heredoc
by duerst 04 May '23

04 May '23

Issue #19015 has been updated by duerst (Martin Dürst). @pyromaniac I think the main problem would be how to handle namespacing. With single letters, the chance of collision is very high. How does Elixir handle this? ---------------------------------------- Feature #19015: Language extension by a heredoc https://bugs.ruby-lang.org/issues/19015#change-102973 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- This propose new heredoc extension with `<<!LANG` like ```ruby doc = <<!LANG # description written in lang LANG foo bar LANG ``` and it is translated to: ```ruby doc = heredoc_extension_LANG(heredoc_text, binding) ``` ## Example ```ruby require 'erb' def heredoc_extension_erb str, b ERB.new(str).run(b) end name = 'ko1' html = <<!erb <div>Hello <%= name %></div> erb puts html #=> <div>Hello ko1</div> ``` ## Background / considerations * Sometimes we write Ruby syntax string with `<<RUBY` and this proposal inspired by it. * it is similar to shebang (`#!LANG` in shell) * [Elixir's custom sigil](https://elixir-lang.org/getting-started/sigils.html) translates `~u(...)` translates to `sigil_u(...)`. This is why it translated to `heredoc_extension_LANG(...)` private method call. * JavaScript has JSX but I don't think it is fit to the Ruby language. * Heredoc is Ruby's chaos part and already confusing a lot. Additional chaos doesn't matter. * `<<!foo` is valid syntax but now I don't think it is not used. gem codesearch doesn't find the usage. * Sorry I couldn't wait 1st/Apr. ## Implementation I attached the experimental implementation which only supports `erb` (because I couldn't find how to get delimiter to determine a method name :p). ---Files-------------------------------- heredoc_extension.patch (2.7 KB) -- https://bugs.ruby-lang.org/

1 0