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

[ruby-core:112329] [Ruby master Misc#19431] DevMeeting at RubyKaigi 2023
by mame (Yusuke Endoh) 10 May '23

10 May '23

Issue #19431 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19431: DevMeeting at RubyKaigi 2023 https://bugs.ruby-lang.org/issues/19431 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- RubyKaigi 2023 will be at Matsumoto, Japan, May 11th - 13th. I would like to try to hold a face-to-face dev meeting at Matsumoto. (@matz will also participate!) Date: 2023/05/10 (Wed.) 14:00-18:00 (The day before RubyKaigi) Location: A meeting room in [Matsumoto Performing Arts Centre](https://www.mpac-en.com/about) (in the RubyKaigi venue, detailed location TBA) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. If you would like to participate, please comment on this ticket so that we can get a headcount. ### Call for agenda If you want to give a talk at the meeting, please raise your agenda on this ticket. I recommend you to file a ticket of your proposal ahead of time. ### Meeting format Depending on the number of talks, we plan to spend approximately half the time on the talks and the remaining time triaging and discussing open tickets. (However, the schedule may change.) ### Disclaimer We may cancel the meeting depending on the situation, such as due to COVID-19. -- https://bugs.ruby-lang.org/

33 34

[ruby-core:113439] [Ruby master Bug#16820] LEGAL is out of sync
by jeremyevans0 (Jeremy Evans) 10 May '23

10 May '23

Issue #16820 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Ruby does not seem to have any LGPL code anymore. The IBM code is now documented in LEGAL. The BSD-2-Clause code is still not documented in LEGAL, but all BSD-2-Clause code seems to also be licensed under Ruby license, so I don't think it is necessary to document in LEGAL. The benchmark code issues are also now documented in LEGAL. Since all issues have addressed, I think this can be closed. ---------------------------------------- Bug #16820: LEGAL is out of sync https://bugs.ruby-lang.org/issues/16820#change-103011 * Author: shyouhei (Shyouhei Urabe) * Status: Closed * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- At the very beginning of `LEGAL`, it reads: > All the files in this distribution are covered under either the Ruby's > license (see the file COPYING) or public-domain except some files > mentioned below. This means that the exception list must be comprehensive. If we miss someone else's software there, it would be automatically made belong to matz. This is very bad. However this is happening now. ## Unclear situation for `benchmark` ## For instance, `benchmark/so_concatenate.rb` comes with no license agreements. Yet as we read its contents, there is almost no doubt that it is _not_ covered by the Ruby's license. The problem is that the URL that was once written inside the file is lost. Our `git log` tells nothing. This and other files under the directory have permanently lost their origin. ## BSD licensed libraries ## Take a look at this search result: ``` % git grep -i 'BSD-2-Clause' | wc -l 43 ``` None of them are listed in `LEGAL`. ## Programs owned by IBM ## ``` % git grep 'International Business Machines' | wc -l 4 ``` The four occurrences of the name IBM does not include `LEGAL`. Also, I wonder if they are actually compatible with Ruby's license. ## LGPL portions ## ``` % git grep 'the GNU LGPL' | wc -l 11 ``` It seems racc is complicated. - `racc.gemspec` says `s.licenses = ["MIT"]`. - It however has some files that are LGPL. - It also has some files that are under Ruby's license. Which one should we believe? If we mix all of them, the library as a whole must be under LGPL. Am I right? -- https://bugs.ruby-lang.org/

1 0

[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) 09 May '23

09 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