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

[ruby-core:113447] [Ruby master Bug#11582] On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float
by jeremyevans0 (Jeremy Evans) 10 May '23

10 May '23

Issue #11582 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Third Party's Issue This is an inconsistency in the default behavior of the Solaris pow function compared to other platforms. You could file this as a bug in the Illumios bug tracker (or raise an issue with Oracle Solaris support) if you would like them to change the behavior: https://www.illumos.org/projects/illumos-gate/issues ---------------------------------------- Bug #11582: On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float https://bugs.ruby-lang.org/issues/11582#change-103027 * Author: Eregon (Benoit Daloze) * Status: Third Party's Issue * Priority: Normal * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- For instance, > Rational(0, 1) ** -1.0 => +Infinity on most platforms, -Infinity on Solaris by default. The Rational is implicitly converted to the Float value 0.0, and the libm function pow(0.0, -1.0) is called. Should this kind of behavior be made consistent by Ruby or should we accept this as dependent on the libm/libc used? They are likely other edges cases for pow() which might differ, and I think in general Ruby should try to unify these cases so the behavior is consistent across platforms at least for arithmetic. For more details, please see https://github.com/ruby/rubyspec/issues/134 reported by ngoto. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113446] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by headius (Charles Nutter) 10 May '23

10 May '23

Issue #11064 has been updated by headius (Charles Nutter). Issue filed for JRuby's differing behavior; if we decide that the method should always be visible through the `singleton_*` calls, we will change it in JRuby. https://github.com/jruby/jruby/issues/7787 ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-103026 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113445] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by headius (Charles Nutter) 10 May '23

10 May '23

Issue #11064 has been updated by headius (Charles Nutter). The behavior for this is at least consistent in JRuby; `singleton_method` does not see methods defined directly on `nil`. I think it should be made consistent, so either it shows up in both `singleton_method` and `singleton_methods` or it should show up in neither (the JRuby behavior currently). I don't have a strong opinion which way is better, but having it show up in both probably has less potential to break things. Of course, it has never worked in JRuby, so if there's code out there depending on `nil.singleton_method` returning a result, it hasn't been reported to us. ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-103025 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113444] [Ruby master Bug#7976] TracePoint call is at call point, not call site
by jeremyevans0 (Jeremy Evans) 10 May '23

10 May '23

Issue #7976 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed @headius and I agree this is not a bug. JRuby has similar behavior for Java extensions as CRuby does for C extensions. ---------------------------------------- Bug #7976: TracePoint call is at call point, not call site https://bugs.ruby-lang.org/issues/7976#change-103024 * Author: zenspider (Ryan Davis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: 2.0 ---------------------------------------- Using TracePoint to make a new tracer utility I'm finding it very difficult to actually trace where the origin is for type :call. Instead, I get the destination. This is not the case for :c_call or :b_call as they trace at the origin, not destination. Reproduction attached. Notice how it outputs ":call wtf.rb:08 :x" where line 8 is the definition of x, not the call of x, yet the subsequent backtrace lists line 21 which is the original origin for the call to x. ---Files-------------------------------- tp_test.rb (1.21 KB) -- https://bugs.ruby-lang.org/

1 0

[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