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

[ruby-core:112037] [Ruby master Feature#15778] Expose an API to pry-open the stack frames in Ruby
by st0012 (Stan Lo) 25 Jan '23

25 Jan '23

Issue #15778 has been updated by st0012 (Stan Lo). > What if we settle for an API and implement and test it first in the debug gem? The `debug` gem already has a method `DEBUGGER__.capture_frames` that achieves something similar. But I agree with @Eregon on not using the `debug` gem for this: - Pulling the `debug` gem in means this the API won't be used and shaped for production use. - The `debug` gem causes side-effects upon required (e.g. new threads and TracePoints activated in the background). In some cases it changes applications' behaviours and breaks tests for example. You can see more related discussions in [this issue](https://github.com/ruby/debug/issues/797). - It's probably not a huge risk for most apps, but this is something we should avoid when possible. - Even without all these issues, it complicates `debug` gem's role and could complicate its maintenance. I know the proposal is just to experiment it in `debug` first, but the reality is that we can't make gems move away from a dependency easily. ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-101471 * Author: gsamokovarov (Genadi Samokovarov) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello, I'm the maintainer of the web-console (https://github.com/rails/web-console/) gem, where one of our features is to jump between the frames in which an error occurred. To accomplish this, I currently use the Debug Inspector CRuby API. I think we should expose this functionality in Rubyland, so tools like web-console don't need to resort to C code for this. This also makes it quite harder for me to support different implementations like JRuby or TruffleRuby as everyone is having a different way to create Ruby Binding objects that represent the frames. Here the API ideas: Add `Thread::Backtrace::Location#binding` method that can create a binding for a specific caller of the current frame. We can reuse the existing `Kernel.caller_locations` method to generate the array of `Thread::Backtrace::Location` objects. We can optionally have the `Kernel.caller_locations(debug: true)` argument if we cannot generate the bindings lazily on the VM that can instruct the VM to do the slower operation. - `Thread::Backtrace::Location#binding` returns `Binding|nil`. Nil result may mean that the current location is a C frame or a JITted/optimized frame and we cannot debug it. We can also expose the DebugInspector API directly, as done in the https://github.com/banister/debug_inspector gem, but for tools like web-console, we'd need to map the bindings with the backtrace, as we cannot generate Bindings for every frame (C frames) and this needs to be done in application code, so I think the `Thread::Backtrace::Location#binding` is the better API for Ruby-land. Such API can help us eventually write most of our debuggers in Ruby as right now we don't have a way to do Post-Mortem debugging without native code or even start our debuggers without monkey-patching `Binding`. I have presented this idea in a RubyKaigi's 2019 talk called "Writing Debuggers in Plain Ruby", you can check-out the slides for more context: http://kaigi-debuggers-in-ruby.herokuapp.com. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111872] [Ruby master Bug#19350] Backport the latest stable version of RubyGems/Bundler
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #19350 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19350: Backport the latest stable version of RubyGems/Bundler https://bugs.ruby-lang.org/issues/19350 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: naruse (Yui NARUSE) * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- RubyGems 3.4.4 and Bundler 2.4.4 have been released. We should backport them into `ruby_3_2` branch. https://github.com/ruby/ruby/pull/7061 I also added patch for [Bug #19298] to above pull-request. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111577] [Ruby master Bug#19299] YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting...
by ollym (Oliver Morgan) 25 Jan '23

25 Jan '23

Issue #19299 has been reported by ollym (Oliver Morgan). ---------------------------------------- Bug #19299: YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting... https://bugs.ruby-lang.org/issues/19299 * Author: ollym (Oliver Morgan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Attached is the backtrace. The code is a moderately complex view with partials and translations. The panic happens specifically when i call a translation `t('...')` but if i simplify the view code around that call the panic goes away. I'm trying to create a simplified way to recreate it without giving you the full application. I'll keep trying, unless the backtrace is enough. ---Files-------------------------------- backtrace.txt (12.3 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112032] [Ruby master Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by Eregon (Benoit Daloze). I think this could become part of ruby/spec, and then we'd run ruby/spec on both built and on installed CRuby with chkbuild. ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101466 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112031] [Ruby master Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by Eregon (Benoit Daloze). FYI there is this script to check bin/ files, which could be reused: https://github.com/ruby/ruby-dev-builder/blob/master/cli_test.rb ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101465 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112029] [Ruby master Bug#10919] [gem install] installs multipe platforms
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #10919 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Third Party's Issue @abaumgaertner Can you file this to https://github.com/rubygems/rubygems? ---------------------------------------- Bug #10919: [gem install] installs multipe platforms https://bugs.ruby-lang.org/issues/10919#change-101463 * Author: abaumgaertner (Andreas Baumgaertner) * Status: Third Party's Issue * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49761) [x64-mingw32] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Natively build a gem - just an example mysql2 on windows x64-mingw32 I could only get the gem to compile with devkit when --platform=ruby is specified - so my understanding is that all devkit compiled gems are platform ruby, even if devkit platform is acutally x64-mingw32 ~~~ C:\apps\redmine_dev\bin>gem install mysql2 --no-document --platform=ruby -- "--with-mysql-dir=c:/apps/redmine_dev/mysql-5.6.23-winx64" Fetching: mysql2-0.3.18.gem (100%) Temporarily enhancing PATH to include DevKit... Building native extensions with: '--with-mysql-dir=c:/apps/redmine_dev/mysql-5.6.23-winx64' This could take a while... Successfully installed mysql2-0.3.18 1 gem installed ~~~ here comes the acutal issue: rerun (also with other dependency managers e.g. bundle install) installs dupplicate gem for platform x64-mingw32 ~~~ C:\apps\redmine_dev\bin>gem install mysql2 Fetching: mysql2-0.3.18-x64-mingw32.gem (100%) ====================================================================================================== \ You've installed the binary version of mysql2. It was built using MySQL Connector/C version 6.1.5. It's recommended to use the exact same version to avoid potential issues. At the time of building this gem, the necessary DLL files were retrieved from: http://cdn.mysql.com/Downloads/Connector-C/mysql-connector-c-6.1.5-winx64.z… \ This gem *includes* vendor/libmysql.dll with redistribution notice in vendor/README. ====================================================================================================== Successfully installed mysql2-0.3.18-x64-mingw32 Parsing documentation for mysql2-0.3.18-x64-mingw32 Installing ri documentation for mysql2-0.3.18-x64-mingw32 Done installing documentation for mysql2 after 0 seconds 1 gem installed ~~~ what is the point in installing a gem for two platforms? it is also not supported by require to specify a platform. solution a: gem install should not install an additional platform, if the gem is already present gem list should always display the platform (not only if there are more than 1) solution b: add an option to gem install that forces devkit build for specific platform so gem install will recognize that the platform is already present. ~~~ C:\apps\redmine_dev\bin>gem list *** LOCAL GEMS *** bundler (1.8.3) mysql2 (0.3.18 ruby x64-mingw32) ~~~ ~~~ C:\apps\redmine_dev\bin>gem env RubyGems Environment: - RUBYGEMS VERSION: 2.4.5 - RUBY VERSION: 2.2.1 (2015-02-26 patchlevel 85) [x64-mingw32] - INSTALLATION DIRECTORY: C:/apps/redmine_dev/ruby/lib/ruby/gems/2.2.0 - RUBY EXECUTABLE: C:/apps/redmine_dev/ruby/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/apps/redmine_dev/ruby/bin - SPEC CACHE DIRECTORY: C:/Users/abaumgaertner/.gem/specs - SYSTEM CONFIGURATION DIRECTORY: C:/ProgramData - RUBYGEMS PLATFORMS: - ruby - x64-mingw32 - GEM PATHS: - C:/apps/redmine_dev/ruby/lib/ruby/gems/2.2.0 - C:/Users/abaumgaertner/.gem/ruby/2.2.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - https://rubygems.org/ - SHELL PATH: - C:\apps\redmine_dev\ruby\bin - C:\apps\redmine_dev\libs - C:\apps\redmine_dev\ImageMagick - D:\apps\mercurial_dev - d:\msys64\mingw64\bin - d:\msys64\mingw64\lib - d:\msys64\usr\bin - C:\Windows\system32 - C:\Windows - C:\Windows\System32\Wbem - C:\Windows\System32\WindowsPowerShell\v1.0\ ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112028] [Ruby master Feature#16012] Add a (small) test-install suite?
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by hsbt (Hiroshi SHIBATA). I'm considering this request again. I'll add small check into https://github.com/ruby/chkbuild. ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101462 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112027] [Ruby master Feature#13534] Checking installation results of default gems
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #13534 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I move this to https://bugs.ruby-lang.org/issues/16012. ---------------------------------------- Feature #13534: Checking installation results of default gems https://bugs.ruby-lang.org/issues/13534#change-101459 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- It's a reminder. I merged rubygems-2.6.12 at r58530. But it backports was removed `test_realworld_default_gem` from original release. Because `test_realworld_default_gem` verifies installation results of default gems. So ruby test suite is not supported after `make install` environment. Therefore, We should add test suite of `tool/rbinstall.rb`for default gems/bundled gems/rdoc etc. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112026] [Ruby master Feature#6590] Dealing with bigdecimal, etc gems in JRuby
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #6590 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Third Party's Issue We can work bigdecimal for JRuby like * https://github.com/ruby/psych (psych contained java implementation and publish jar file) or * https://github.com/ruby/date (date contained empty file for JRuby) or other approach. We should move this issue to https://github.com/ruby/bigdecimal/issues/169. ---------------------------------------- Feature #6590: Dealing with bigdecimal, etc gems in JRuby https://bugs.ruby-lang.org/issues/6590#change-101458 * Author: headius (Charles Nutter) * Status: Third Party's Issue * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Hello! http://jira.codehaus.org/browse/JRUBY-6704 We have a need to make the "bigdecimal" gem work for JRuby, so that distros (like Red Hat, mentioned in the above bug) and users can have the same gemspec for JRuby with updated bigdecimal gem references. I'm not sure the best way to proceed. The bigdecimal source and gemspec all come from MRI source, and are not versioned separately. That means we can't simply share a repository for the JRuby bits. We could maintain a forked version in our forked "jruby/ruby" repository, but that wouldn't be part of the bigdecimal release cycle then. So I'm looking to you for guidance. The BigDecimal lib is here in JRuby: https://github.com/jruby/jruby/tree/master/src/org/jruby/ext/bigdecimal It might be simplest if for now there's a dummy "bigdecimal" gem pushed for JRuby that does not contain anything, since we would have other complications if we tried to remove BigDecimal from JRuby proper (it is referenced elsewhere int eh code, etc). Thoughts? - Charlie ---Files-------------------------------- noname (500 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112025] [Ruby master Bug#18355] require("pathname") within rack application chnages behaviors of Pathname methods, such as absolute?(), when there are two versions of 'pathname' gem installed.
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #18355 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Feedback Can you try it with the latest version of RubyGems/Bundler? You can do it with: ``` $ gem update --system ``` ---------------------------------------- Bug #18355: require("pathname") within rack application chnages behaviors of Pathname methods, such as absolute?(), when there are two versions of 'pathname' gem installed. https://bugs.ruby-lang.org/issues/18355#change-101457 * Author: ume-san (Toshi Umehara) * Status: Feedback * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Environment Ruby 3.0.2 is installed on Fedora 34 from source. 'gem update' is conducted, and there are two versions of 'pathname' gems (0.2.0, default: 0.1.0) installed as follows. ``` > uname -a Linux localhost.localdomain 5.14.18-200.fc34.x86_64 #1 SMP Fri Nov 12 16:48:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] > gem update --system > gem update > gem list ... pathname (0.2.0, default: 0.1.0) ... ``` ## Code The following files, Gemfile and config.ru, are placed in the same directory. ``` # Gemfile source 'https://rubygems.org/' gem 'rack' gem 'webrick' ``` ``` # config.ru class Application def call(env) status = 200 headers = { "Content-Type" => "text/html" } path = Dir.pwd() pathname1 = Pathname.new(path) require("pathname") pathname2 = Pathname.new(path) body = ["#{pathname1.absolute?} #{pathname2.absolute?}"] [status, headers, body] end end run Application.new ``` ## Command Web server starts using the following commands. ``` bundle config set --local path 'vendor/bundle' bundle install bundle exec rackup -s webrick ``` * Output on the console ``` [2021-11-21 09:44:13] INFO WEBrick 1.7.0 [2021-11-21 09:44:13] INFO ruby 3.0.2 (2021-07-07) [x86_64-linux] [2021-11-21 09:44:13] INFO WEBrick::HTTPServer#start: pid=2770 port=9292 ``` ## Expected Result Accessing localhost:9292 using a web browser , 'true true' is an expected result on the browser, because pathname1 and pathanme2 are generated from the same absolute path in the above code. ``` true true ``` ## Actual Result Accessing localhost:9292 shows the following messages on the browser and the console. After 'require("pathname")', Pathname.absolute?() retuns false, even if represents an absolute path. * On the browser ``` true false ``` * On the console ``` /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:20: warning: already initialized constant Pathname::TO_PATH /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:20: warning: previous definition of TO_PATH was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:22: warning: already initialized constant Pathname::SAME_PATHS /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:22: warning: previous definition of SAME_PATHS was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:34: warning: already initialized constant Pathname::SEPARATOR_LIST /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:34: warning: previous definition of SEPARATOR_LIST was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:35: warning: already initialized constant Pathname::SEPARATOR_PAT /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:35: warning: previous definition of SEPARATOR_PAT was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:41: warning: already initialized constant Pathname::ABSOLUTE_PATH /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:41: warning: previous definition of ABSOLUTE_PATH was here 127.0.0.1 - - [21/Nov/2021:09:44:20 +0900] "GET / HTTP/1.1" 200 10 0.0339 ``` ## Segmentation fault Moreover, press Ctrl-c to stop the Rack application, the application causes a segmentation fault. The segmentation fault message is attached. ## Notes Uninstalling version 0.2.0 of pathname gem solves the problem above. Therefore, I guess having two versions of pathname gems causes this behavior. ``` gem uninstall pathname --version=0.2.0 ``` * Start the Rack application again ``` bundle exec rackup -s webrick ``` * Output on the browser The expected output is obtained on the browser, without warning messages on the console. ``` true true ``` ---Files-------------------------------- segmentation_fault.txt (51.1 KB) -- https://bugs.ruby-lang.org/

1 0