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

[ruby-core:113463] [Ruby master Feature#10602] Support multithreaded profiling

by ivoanjo (Ivo Anjo)

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 year

1
0
0 0

[ruby-core:113460] Ruby 3.3.0-preview1 Released

by NARUSE, Yui

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 year

1
0
0 0

[ruby-core:113450] [Ruby master Feature#19637] Use Lrama LALR parser generator instead of Bison

by yui-knk (Kaneko Yuichiro)

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/

1 year

3
3
0 0

[ruby-core:111136] [Ruby master Bug#19168] "such file" is bad grammar

by masterleep2 (Bill Lipa)

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/

1 year

7
6
0 0

[ruby-core:113455] [Ruby master Bug#19638] Multithread is not working as expected after gem fix

by leonard100 (Leo Camp)

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/

1 year

2
1
0 0

[ruby-core:113454] Re: [Ruby master Bug#16820] LEGAL is out of sync

by James Cox

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 year

1
0
0 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)

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/

1 year

6
11
0 0

[ruby-core:111309] [Ruby master Bug#19238] URI.open fails for file path when second argument is a hash

by dkinzer (David Kinzer)

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/

1 year

3
2
0 0

[ruby-core:113447] [Ruby master Bug#11582] On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float

by jeremyevans0 (Jeremy Evans)

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 year

1
0
0 0

[ruby-core:113446] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array

by headius (Charles Nutter)

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 year

1
0
0 0

2024

2023

2022

ruby-core May 2023