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

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

12 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

[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