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

[ruby-core:115757] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Giving `$!` dynamic scope is equally likely to cause subtle bugs, so no matter what we do here, there is a chance to cause compatibility issues. Deprecation is explicit and gives people a chance to fix the code, which in most cases that I reviewed, is buggy. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105695 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115756] [Ruby master Feature#18083] Capture error in ensure block.
by jeremyevans0 (Jeremy Evans) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by jeremyevans0 (Jeremy Evans). ioquatix (Samuel Williams) wrote in #note-29: > In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". > > If the answer is YES, we should implement it. > > If the answer is NO, we should deprecate and remove `$!`. This perspective ignores backwards compatibility. If the answer is NO, we would still need to determine if the benefit of removing `$!` exceeds the cost of the loss of backwards compatibility. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105694 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115755] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). `$!` is non-trivial to implement - can have performance implications, and dynamic scope might make it more expensive. cc @Eregon @headius can we get your input? Giving `$!` dynamic scope mitigates the problem but still seems to encourage an approach that @matz has said he was against. Specifically, he was against `ensure => exception` and this is just a variant of that approach. In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". If the answer is YES, we should implement it. If the answer is NO, we should deprecate and remove `$!`. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105693 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115752] [Ruby master Feature#18083] Capture error in ensure block.
by Dan0042 (Daniel DeLorme) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by Dan0042 (Daniel DeLorme). ko1 (Koichi Sasada) wrote in #note-20: > my proposal is introducing dynamic scope, not syntactical scope like: I think this is a good idea, definitely an improvement over the current situation. `$!` is already always correct inside a `rescue` clause, and that would make it always correct inside the `ensure` clause. But I want to confirm if this would be the expected behavior: ```ruby #1 p $! #=> A begin # no raise ensure p $! #=> nil (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) #2 p $! #=> A begin raise "B" rescue p $! #=> B #not re-raised ensure p $! #=> B (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) ``` ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105683 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115748] [Ruby master Feature#18083] Capture error in ensure block.
by kddnewton (Kevin Newton) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by kddnewton (Kevin Newton). If you're already using global variables, we could add another global variable that gets set in `ensure` blocks that determines if an error was raised. That way you could safely check `$!`. That wouldn't require a syntax change. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105680 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115747] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Here is a good example of why `$!` is dangerous: https://github.com/ruby/net-ftp/pull/24 I believe the merged fix is also wrong, since flow control can exit without closing the connection. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105679 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115739] Ruby 3.2.2 Solaris-Sparc Compilation Error in iseq.c
by Jay Mav 14 Dec '23

14 Dec '23

Hello, Building Ruby 3.2.2 on Solaris-Sparc 32-bit with Developer Studio 12.6. Issues: 1) compilation of iseq.c fails due to variable definition in macro OPTION: #define SET_COMPILE_OPTION(o, h, mem) \ { VALUE flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } SET_COMPILE_OPTION(option, opt, inline_const_cache); SET_COMPILE_OPTION(option, opt, peephole_optimization); SET_COMPILE_OPTION(option, opt, tailcall_optimization); SET_COMPILE_OPTION(option, opt, specialized_instruction); SET_COMPILE_OPTION(option, opt, operands_unification); SET_COMPILE_OPTION(option, opt, instructions_unification); SET_COMPILE_OPTION(option, opt, stack_caching); SET_COMPILE_OPTION(option, opt, frozen_string_literal); SET_COMPILE_OPTION(option, opt, debug_frozen_string_literal); SET_COMPILE_OPTION(option, opt, coverage_enabled); "iseq.c", line 812: identifier redefined: flag current : unsigned long ... If the definition of flag is moved outside of the macro: VALUE flag; #define SET_COMPILE_OPTION(o, h, mem) \ { flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } then iseq.c gets compiled. What's the correct fix for this macro? 2) After fixing the above error, the build progresses but fails in linking miniruby linking miniruby Undefined first referenced symbol in file .L13046 iseq.o It is not clear what .L13046 represents. Can any one please share how this issue can be resolved? Thanks.

2 1

[ruby-core:115710] [Ruby master Bug#20060] bundled_gems.rb is not working with Bootsnap
by hsbt (Hiroshi SHIBATA) 13 Dec '23

13 Dec '23

Issue #20060 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20060: bundled_gems.rb is not working with Bootsnap https://bugs.ruby-lang.org/issues/20060 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Addressed from https://github.com/ruby/ruby/pull/9163#issuecomment-1850924893 `bundled_gems.rb` of 3.3.0-rc1 couldn't handle full paths by Bootsnap. ``` $ rails new example (snip) rails importmap:install bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." (snip) ``` It's working with DISABLE_BOOTSNAP=1. But we should resolve it with under the bootsnap. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115733] [Ruby master Feature#13383] [PATCH] Module#source_location
by matheusrich (Matheus Richard) 13 Dec '23

13 Dec '23

Issue #13383 has been updated by matheusrich (Matheus Richard). I want to bring this up again. This feature feels very natural to me, and it was surprising that `Module#source_locations` isn't implemented yet. What can we do to move this forward? ---------------------------------------- Feature #13383: [PATCH] Module#source_location https://bugs.ruby-lang.org/issues/13383#change-105666 * Author: koba789 (Hidekazu Kobayashi) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- # Abstract It can inspect where the module or class is defined. # Background In debugging or development an application, I usually want to find out where the class definition of using library. There is Method#source_location but I could not find **Class** easily. # Implementation In Github: https://github.com/ruby/ruby/pull/1562 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115197] [Ruby master Misc#19980] Is the Ruby 3.3 ABI frozen?
by mdalessio (Mike Dalessio) 13 Dec '23

13 Dec '23

Issue #19980 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Misc #19980: Is the Ruby 3.3 ABI frozen? https://bugs.ruby-lang.org/issues/19980 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal ---------------------------------------- I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic. In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)) In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby. This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released. To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105) Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released? Thank you for any guidance you can provide. -- https://bugs.ruby-lang.org/

3 6