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

[ruby-core:113470] [Ruby master Bug#5179] Complex#rationalize and to_r with approximate zeros
by kjtsanaktsidis (KJ Tsanaktsidis) 14 May '23

14 May '23

Issue #5179 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). I've explored the behaviour here a bit, and I think I do believe that `0.0` really does represent the concept of "zero". Specifically, it's the number that satisfies the following properties, for all possible non-NaN floats N: * `abs(0.0 * N) == 0.0` * `0.0 + N == N` You might obtain a bit pattern for 0.0 from the result of a calculation which might have otherwise produced a non-zero result if there was more precision; however that doesn't change the fact that the bit pattern you have really does satisfy the mathematical properties of zero. Additionally, I think the distinction that complex.c currently draws between floating-point and non-floating-point zero also results in some other surprising results: ``` irb(main):030:0> Complex(3, 7) ** 0.0 => (1.0+0.0i) irb(main):031:0> Complex(3, 7) ** 0 => (1+0i) irb(main):032:0> Complex(3.2, 7) ** 0 => (1+0i) irb(main):033:0> Complex(3.2, 7) ** 0.0 => (1.0+0.0i) ``` Why does the type of `A ** B` depend on whether B is a float or not, but not A? ``` irb(main):034:0> Complex(3.2, 7) ** Complex(1, 0.0) => (3.200000000000001+6.999999999999999i) irb(main):035:0> Complex(3.2, 7) ** Complex(1, 0) => (3.2+7i) ``` This doesn't _need_ to accumulate floating point error - the code in `rb_complex_pow` special-cases `(a + bi) ** (c + 0i) -->(a + bi) ** c`, but the special-casing is skipped if `0i` is `0.0i` instead. Also, `#to_i` and `#to_f` have the same issue as `#to_r`: ``` irb(main):037:0> Complex(3, 0.0).to_i (irb):37:in `to_i': can't convert 3+0.0i into Integer (RangeError) irb(main):038:0> Complex(3, 0.0).to_f (irb):38:in `to_f': can't convert 3+0.0i into Float (RangeError) ``` This is especially odd for `#to_i` because it of course has no problems truncating away the real part: ``` irb(main):040:0> Complex(3.1, 0).to_i => 3 ``` I think we should change all the checks for `k_exact_zero_p` in `complex.c` to `f_zero_p`; i.e. in all the places where `complex.c` special-cases integer zero, also make it special-case floating-point zero. If people agree with this (especially people who actually use Complex in their code - I have pretty much never used it!) I can send a pretty simple patch to cloe this out. ---------------------------------------- Bug #5179: Complex#rationalize and to_r with approximate zeros https://bugs.ruby-lang.org/issues/5179#change-103049 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * ruby -v: r32354 ---------------------------------------- Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though: Complex(1, 0).to_r # => Rational(1,1) Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1) Complex(1, 0.0).to_r # => RangeError This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113464] [Ruby master Misc#16512] Improving `www.ruby-lang.org` reference by merging with `rubyreferences.github.io`
by hsbt (Hiroshi SHIBATA) 13 May '23

13 May '23

Issue #16512 has been updated by hsbt (Hiroshi SHIBATA). Assignee changed from zverok (Victor Shepelev) to hsbt (Hiroshi SHIBATA) I discussed this with @ufuk. We will work this to forward. ---------------------------------------- Misc #16512: Improving `www.ruby-lang.org` reference by merging with `rubyreferences.github.io` https://bugs.ruby-lang.org/issues/16512#change-103043 * Author: matz (Yukihiro Matsumoto) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- @zverok prepared better-looking reference pages at `rubyreferences.github.io`. I think there's room for improvement of reference pages on `www.ruby-lang.org`. @hsbt Is there a chance to work with? Matz. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113463] [Ruby master Feature#10602] Support multithreaded profiling
by ivoanjo (Ivo Anjo) 12 May '23

12 May '23

Issue #10602 has been updated by ivoanjo (Ivo Anjo). PR to implement this being discussed in https://github.com/ruby/ruby/pull/7784 ---------------------------------------- Feature #10602: Support multithreaded profiling https://bugs.ruby-lang.org/issues/10602#change-103042 * Author: mperham (Mike Perham) * Status: Open * Priority: Normal ---------------------------------------- The current `rb_profile_frames` captures the frame for whatever thread is current. This makes profiling a multithreaded system impossible. I'd like a `rb_thread_profile_frames` which captures a given thread. It seems like it would be a very simple change, something like this: ~~~ int rb_profile_frames(int start, int limit, VALUE *buff, int *lines) { rb_profile_frames(start, limit, buff, lines, GET_THREAD()) } int rb_thread_profile_frames(int start, int limit, VALUE *buff, int *lines, rb_thread_t *th) { int i; rb_control_frame_t *cfp = th->cfp, *end_cfp = RUBY_VM_END_CONTROL_FRAME(th); ... ~~~ This way profiling gems could lock to a specific thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113460] Ruby 3.3.0-preview1 Released
by NARUSE, Yui 12 May '23

12 May '23

We are pleased to announce the release of Ruby 3.3.0-preview1. Ruby 3.3 adds a new pure-Ruby JIT compiler named RJIT, uses lrama as a parser generator, and many performance improvements especially YJIT. ## RJIT * Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT. * RJIT supports only x86\_64 architecture on Unix platforms. * Unlike MJIT, it doesn't require a C compiler at runtime. * RJIT exists only for experimental purposes. * You should keep using YJIT in production. * If you are interested in developing JIT for Ruby, please check out [k0kubun's presentation on Day 3 of RubyKaigi](https://rubykaigi.org/2023/presentations/k0kubun.html#day3). ## Use Lrama instead of Bison * Replace Bison with [Lrama LALR parser generator](https://github.com/yui-knk/lrama) [Feature #19637] * If you have interest, please see [The future vision of Ruby Parser](https://rubykaigi.org/2023/presentations/spikeolaf.html) ## YJIT * Significant performance improvements over 3.2 * Splat and rest arguments support has been improved. * Registers are allocated for stack operations of the virtual machine. * More calls with optional arguments are compiled. * `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`, `Kernel#instance_of?`, `Module#===` are specially optimized. * Instance variables no longer exit to the interpreter with megamorphic Object Shapes. * Metadata for compiled code uses a lot less memory. * Improved code generation on ARM64 * Option to start YJIT in paused mode and then later enable it manually * `--yjit-pause` and `RubyVM::YJIT.resume` * This can be used to enable YJIT only once your application is done booting * Exit tracing option now supports sampling * `--trace-exits-sample-rate=N` * Multiple bug fixes ## Other Notable New Features ### Language ## Performance improvements * `defined?(@ivar)` is optimized with Object Shapes. ## Other notable changes since 3.2 ## Compatibility issues Note: Excluding feature bug fixes. ### Removed constants The following deprecated constants are removed. ### Removed methods The following deprecated methods are removed. ## Stdlib compatibility issues ### `ext/readline` is retired * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`. * We no longer need to install libraries like `libreadline` or `libedit`. ## C API updates ### Updated C APIs The following APIs are updated. ### Removed C APIs The following deprecated APIs are removed. ## Standard library updates The following default gems are updated. * RubyGems 3.5.0.dev * bigdecimal 3.1.4 * bundler 2.5.0.dev * csv 3.2.7 * fiddle 1.1.2 * fileutils 1.7.1 * irb 1.6.4 * optparse 0.4.0.pre.1 * psych 5.1.0 * reline 0.3.3 * stringio 3.0.7 * strscan 3.0.7 * syntax_suggest 1.0.4 * time 0.2.2 * timeout 0.3.2 * uri 0.12.1 The following bundled gems are updated. * minitest 5.18.0 * rbs 3.1.0 * typeprof 0.21.7 * debug 1.8.0 See GitHub releases like [Logger](https://github.com/ruby/logger/releases) or changelog for details of the default gems or bundled gems. See [NEWS](https://github.com/ruby/ruby/blob/v3_3_0_preview1/NEWS.md) or [commit logs](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_preview1) for more details. With those changes, [1922 files changed, 75283 insertions(+), 44896 deletions(-)](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_preview1… since Ruby 3.2.0! Merry Christmas, Happy Holidays, and enjoy programming with Ruby 3.3! ## Download * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.tar.gz> SIZE: 20428213 SHA1: 5445eec1cd9ddb44e03e74568cac94209c91b42d SHA256: c3454a911779b8d747ab0ea87041030d002d533edacb2485fe558b7084da25ed SHA512: 0f891f140ddc6372aa7c4459f8784126e0c341db7b80e72c51e441c5153c43c2d7b965f7807c076862ac84b9b8b0c6a66bbf66fc341746016151397bb21c782a * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.tar.xz> SIZE: 15074600 SHA1: 4c22ebca287c87811e1050bf4d59b7d32255b212 SHA256: ae300b49e06c13087dd163b97eddd38db895dc8e0c9904284119795d75303fbb SHA512: 46c1134dba5810847f7f6b4298900a91f5225679d7873548b271f4ef2ad1dc168722562a2e468a2ccf136314176ee613d8c7792fd4411a3f7a44c80b93b417ee * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.zip> SIZE: 24846962 SHA1: 31774fa653c54107b6afc30adda3a0350d8f41d2 SHA256: 6ecafecf83f2cacf446b2326012f2b6ee1a0614d8dd29bb1fb3f105c27e2c553 SHA512: 794bef847fefbbdbbdced85975a00c9289ef6464810408af3f0f2055052d6b5ef5576dbd41e0d87bb73f1ad276d8e27c36018610f8e2b9936828c0e692f611f0 ## What is Ruby Ruby was first developed by Matz (Yukihiro Matsumoto) in 1993, and is now developed as Open Source. It runs on multiple platforms and is used all over the world especially for web development.

1 0

[ruby-core:113450] [Ruby master Feature#19637] Use Lrama LALR parser generator instead of Bison
by yui-knk (Kaneko Yuichiro) 12 May '23

12 May '23

Issue #19637 has been reported by yui-knk (Kaneko Yuichiro). ---------------------------------------- Feature #19637: Use Lrama LALR parser generator instead of Bison https://bugs.ruby-lang.org/issues/19637 * Author: yui-knk (Kaneko Yuichiro) * Status: Open * Priority: Normal ---------------------------------------- I want to propose to use Lrama LALR parser generator instead of Bison. https://github.com/yui-knk/lrama is a pure ruby parser generator which accepts Ruby's "parse.y" and generate compatible "parse.c" file. By this change, we never depend on Bison whose version is different for each environment. Future improvement, like Nonterminal attributes and so on, will be discussed other tickets. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111136] [Ruby master Bug#19168] "such file" is bad grammar
by masterleep2 (Bill Lipa) 12 May '23

12 May '23

Issue #19168 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #19168: "such file" is bad grammar https://bugs.ruby-lang.org/issues/19168 * Author: masterleep2 (Bill Lipa) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The error message for a missing required file has bad grammar: $ irb irb(main):001:0> require 'wuxx' <internal:/opt/local/lib/ruby3.1/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- wuxx (LoadError) The "such" should be removed. "cannot load file" reads more normally in English. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:113455] [Ruby master Bug#19638] Multithread is not working as expected after gem fix
by leonard100 (Leo Camp) 11 May '23

11 May '23

Issue #19638 has been reported by leonard100 (Leo Camp). ---------------------------------------- Bug #19638: Multithread is not working as expected after gem fix https://bugs.ruby-lang.org/issues/19638 * Author: leonard100 (Leo Camp) * Status: Open * Priority: Normal * ruby -v: 2.7.6 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi, Im currently working on a ruby application that uses Ruby 2.7, ActiveRecord 7 and IBM_DB gem 5.4.0(with the fix https://bugs.ruby-lang.org/issues/19527) The application requires using ActiveRecord::Base for the connection_pool, Threads and the IBM_DB gem as an adapter to connect to the database but using ActiveRecord. The application requires running multiple queries at the same time, limited by the pool size. Previously using activerecord-jdbc-adapter and Jruby 1.7 which could run multiple connections and for each connection run a query using the pool and threads, that means 5 queries = 5 connections = 5 threads running them Now using the IBM_DB gem, you can execute the connections and queries with different ones completing the process, the problem is that it does it one by one instead of several at the same time, being the same code as before, it hangs just at the moment the one that executes the query in the thread, waits until it ends to go to the next one, this means 5 queries = 1 connection (different in each query) = 1 thread executing it (different in each query) We used the fixed version with the GC issue mentioned in this post https://bugs.ruby-lang.org/issues/19527 where we changed and recompiled the gem as follows: ``` ruby Before /IBM_DB_Adapter/ibm_db/ext/ibm_db.c _ruby_ibm_db_mark_stmt_struct(stmt_handle *handle) static inline VALUE ibm_Ruby_Thread_Call(rb_blocking_function_t *func, void *data1, rb_unblock_function_t *ubf, void *data2) { void *(*f)(void*) = (void *(*)(void*))func; return (VALUE)rb_thread_call_without_gvl(f, data1, ubf, data2); } After static inline VALUE ibm_Ruby_Thread_Call(rb_blocking_function_t *func, void *data1, rb_unblock_function_t *ubf, void *data2) { + return func(data1); } ``` This solved the GC problem, but since it is a method that handles the Threads when it is executed, it makes me believe that this Fix that was made to the method may be causing that when a query is executed it hangs there until that query ends and proceed with another thread/connection/query instead of executing it and leaving it running in the background while it goes to do another thread/connection/query I made this test code where I do the same as the application on a smaller scale, but the exact same case mentioned above happens, my doubt is the problem will be in this code or in the previous fix: ``` ruby require 'ibm_db' require 'active_record' $control_tables_schema = "" $db_config = { adapter: 'ibm_db', schema: $control_tables_schema, database: '', username: '', password: '', checkout_timeout: 20, pool: 20 # number of simultaneous connections } conn = nil condsql = nil condsql = ["SQL COMMAND", "SQL COMMAND", "SQL COMMAND"] condsql.each do |auxsql| threads = Thread.new(auxsql) do |command| conn = ActiveRecord::Base.establish_connection($db_config) res = nil conn.with_connection do |connection_cond| res = connection_cond.execute(auxsql) end #puts "************************************" puts conn.stat puts conn.connections() puts owner_thread = Thread.current puts res puts "************************************" #Output looks like this, no errors, just one by one instead of all at the same time #{:size=>20, :connections=>1, :busy=>0, :dead=>0, :idle=>1, :waiting=>0, :checkout_timeout=>20.0} #<ActiveRecord::ConnectionAdapters::IBM_DBAdapter:0x00007faf2852d150> #<Thread:0x00007faf44248b80 test.rb:26 run> end threads.join if conn then conn.release_connection(owner_thread = Thread.current) conn.clear_active_connections! rescue nil conn.clear_stale_cached_connections! rescue nil end end ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113454] Re: [Ruby master Bug#16820] LEGAL is out of sync
by James Cox 10 May '23

10 May '23

I know this is closed… but spotted this one and I thought it worth a look. In particular, I looked into benchmark and the shootout…. I found an archive in the wayback machine, which may provide some data to update LEGAL with a bit more data: https://web.archive.org/web/20010606133226/http://www.bagley.org/~doug/shoo… According to this ( https://web.archive.org/web/20010418111739/http://www.bagley.org/~doug/shoo…) it seems the venerable Dave Thomas contributed to a bunch of the ruby versions :) Another/followup version is here: http://web.archive.org/web/20040611035744/http://shootout.alioth.debian.org/ And then there are a few examples where MIT or other known licenses are in use for files, with just the copyright changing. Is it valuable to reproduce them over and over in LEGAL? Or would perhaps a yaml/json/something manifest outlining each file, copyright and license be potentially more useful? I know it’s not really high priority, but figured it might be worth making it a little more accurate as Jeremy’s point stands- it does currently assert that anything not identified properly in that file belongs to Matz, which is a bit ¯\_(ツ)_/ — not great, not evil, just not perfect. 🙂 — james

1 0

[ruby-core:111792] [Ruby master Bug#19334] Defining many instance variables and accessing them is slow in Ruby 3.2.0
by mame (Yusuke Endoh) 10 May '23

10 May '23

Issue #19334 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19334: Defining many instance variables and accessing them is slow in Ruby 3.2.0 https://bugs.ruby-lang.org/issues/19334 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal * Assignee: tenderlovemaking (Aaron Patterson) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` class C eval("def initialize; #{ (0..100000).map { "@x#{ _1 } = 0; " }.join } end") attr_reader :x50000 end p :start C.new.x50000 ``` This script takes less than one second in Ruby 3.1.3, and does more than ten second in Ruby 3.2.0. ``` $ time ruby -v test.rb ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] :start real 0m0.210s user 0m0.167s sys 0m0.044s ``` ``` $ time ruby -v test.rb ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] :start real 0m11.026s user 0m10.950s sys 0m0.040s ``` This problem is not critical, but is there any room for improvement? -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111309] [Ruby master Bug#19238] URI.open fails for file path when second argument is a hash
by dkinzer (David Kinzer) 10 May '23

10 May '23

Issue #19238 has been reported by dkinzer (David Kinzer). ---------------------------------------- Bug #19238: URI.open fails for file path when second argument is a hash https://bugs.ruby-lang.org/issues/19238 * Author: dkinzer (David Kinzer) * Status: Open * Priority: Normal * ruby -v: 3.0, 3.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I upgraded one of my projects to ruby 3.1.3 and I found that `URI.open` now throws an error when passed a second argument when the first argument is a file path. When the first argument is a URL, then URI.open will work as expected. I was able to replicate this issue in all 3.x versions including the latest so it's an issue that was introduce with the release of 3.0 I found it convenient that `URI.open(uri, {})`, worked regardless of wether uri was a file path or a URL because it meant I did not have to add logic for varying cases. When the uri argument was a file path URI.open would simply open up the file and disregard the hash options params. But now I have to add that logic myself which is not as clean looking. Below is an example of the error. It's quite easy to reproduce on any version of ruby 3.x ``` URI.open("spec/fixtures/blogs.json", {}) /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `initialize': no implicit conversion of Hash into String (TypeError) from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from (irb):9:in `<main>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `kernel_load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:23:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:486:in `exec' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:31:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:25:in `start' ... 5 levels... ``` -- https://bugs.ruby-lang.org/

3 2