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

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

30 Jan '23

Issue #15778 has been updated by st0012 (Stan Lo). I had a chance to chat with multiple people about this proposal, so I want to share what I found here: - From chatting with @maximecb, my understanding is that such feature requires Ruby to keep all the frames on the stack in an accessible format, which will limit the optimisation YJIT could do. This is fine for development, but using it in production with YJIT "might" not be ideal. - Rails would be happy to use such feature to enrich its exception backtrace in log, which will be helpful in development. - In production, in addition to the potential issue with YJIT, more things like data scrubbing needs to be considered. ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-101560 * 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:112115] [Ruby master Misc#19391] IO #write/#read behaviour when binmode and encoding are explicitly specified
by andrykonchin (Andrew Konchin) 30 Jan '23

30 Jan '23

Issue #19391 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #19391: IO #write/#read behaviour when binmode and encoding are explicitly specified https://bugs.ruby-lang.org/issues/19391 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal ---------------------------------------- I have a question about how `IO` operations are supposed to behave when file is opened in binary mode but encoding is specified too. Documentation of `b` option of `IO.new` method and of `IO#binmode` method is a bit not synchronised and confusing: `IO.open`: ``` "b" Binary file mode Suppresses EOL <-> CRLF conversion on Windows. And sets external encoding to ASCII-8BIT unless explicitly specified. ``` `IO#binmode`: ``` Puts ios into binary mode. Once a stream is in binary mode, it cannot be reset to nonbinary mode. newline conversion disabled encoding conversion disabled content is treated as ASCII-8BIT ``` So `unless explicitly specified` and `encoding conversion disabled` are a bit contradictory. Right now I observe that `IO.write` still encodes an input string in explicitly specified encoding (with `encoding` option) even if binary mode is set (with `binmode` option) ```ruby File.open(@filename, "w", encoding: Encoding::UTF_32LE, binmode: true) do |file| file.write("hi") end File.binread(@filename) # => "h\u0000\u0000\u0000i\u0000\u0000\u0000" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112113] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by mame (Yusuke Endoh) 30 Jan '23

30 Jan '23

Issue #18285 has been updated by mame (Yusuke Endoh). I have updated my PR: https://github.com/ruby/ruby/pull/6950 As I was working on updating the PR, the following message change caught my attention. ``` old: undefined method `foo' for main:Object new: undefined method `foo' for #<Object:0x00007f230602cd28> ``` Because the toplevel (`main`) is an extended object, `any_to_s` rule is applied. But I think the new message is too confusing. I talked with @matz, and we decided to handle the toplevel specially: ``` new: undefined method `foo' for main ``` I found no other confusing examples during updating my PR. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101550 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112112] [Ruby master Misc#16671] BASERUBY version policy
by hsbt (Hiroshi SHIBATA) 30 Jan '23

30 Jan '23

Issue #16671 has been updated by hsbt (Hiroshi SHIBATA). CentOS 7 will be EOL at 2024/06 and CentOS 8+ will be not provided in the future. I know Red Hat switched them to CentOS Stream. Unfortunately, CentOS Stream (and RHEL) is not major distribution for Ruby developers. ---------------------------------------- Misc #16671: BASERUBY version policy https://bugs.ruby-lang.org/issues/16671#change-101549 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Ruby 2.7 (MRI) requires Ruby 2.2 or later (== BASERUBY) to build from repository. Tarball does not need any installed Ruby. To build latest Ruby from repository, you need to build Ruby 2.2 and later from a tarball. Can we make the BASERUBY version update policy? # Background To use `ISeq#to_a` (specific format) Ruby 2.2 or later is needed from Ruby 2.7. The oldest version used by RubyCI machines was Ruby 2.2, so I determined update. I needed to file a ticket about this version bump, sorry. --- related: https://bugs.ruby-lang.org/issues/16668 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112111] [Ruby master Misc#16671] BASERUBY version policy
by vo.x (Vit Ondruch) 30 Jan '23

30 Jan '23

Issue #16671 has been updated by vo.x (Vit Ondruch). Why Ubuntu / Debian and not CentOS / RHEL 7? IOW I think it would be probably better to base the policy on Ruby releases then on external factor such as Linux distribution versions. ---------------------------------------- Misc #16671: BASERUBY version policy https://bugs.ruby-lang.org/issues/16671#change-101548 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Ruby 2.7 (MRI) requires Ruby 2.2 or later (== BASERUBY) to build from repository. Tarball does not need any installed Ruby. To build latest Ruby from repository, you need to build Ruby 2.2 and later from a tarball. Can we make the BASERUBY version update policy? # Background To use `ISeq#to_a` (specific format) Ruby 2.2 or later is needed from Ruby 2.7. The oldest version used by RubyCI machines was Ruby 2.2, so I determined update. I needed to file a ticket about this version bump, sorry. --- related: https://bugs.ruby-lang.org/issues/16668 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112106] [Ruby master Misc#16671] BASERUBY version policy
by matz (Yukihiro Matsumoto) 30 Jan '23

30 Jan '23

Issue #16671 has been updated by matz (Yukihiro Matsumoto). I agree with upgrading BASERUBY. The version should be determined by the latest version of the distribution (Debian?). Matz. ---------------------------------------- Misc #16671: BASERUBY version policy https://bugs.ruby-lang.org/issues/16671#change-101543 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Ruby 2.7 (MRI) requires Ruby 2.2 or later (== BASERUBY) to build from repository. Tarball does not need any installed Ruby. To build latest Ruby from repository, you need to build Ruby 2.2 and later from a tarball. Can we make the BASERUBY version update policy? # Background To use `ISeq#to_a` (specific format) Ruby 2.2 or later is needed from Ruby 2.7. The oldest version used by RubyCI machines was Ruby 2.2, so I determined update. I needed to file a ticket about this version bump, sorry. --- related: https://bugs.ruby-lang.org/issues/16668 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112102] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC
by andrykonchin (Andrew Konchin) 29 Jan '23

29 Jan '23

Issue #19096 has been updated by andrykonchin (Andrew Konchin). @nobu Thank you! ---------------------------------------- Misc #19096: [Question] Time with `-00:00` offset is in UTC https://bugs.ruby-lang.org/issues/19096#change-101539 * Author: andrykonchin (Andrew Konchin) * Status: Closed * Priority: Normal ---------------------------------------- It's a bit unexpected but ```ruby Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => true ``` But time with `+00:00` or `0` offset is treated as not UTC time: ```ruby Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false ``` Is it an intentional behaviour? In this case could you please clarify the reason why it works this way? --- ``` ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112101] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC
by nobu (Nobuyoshi Nakada) 28 Jan '23

28 Jan '23

Issue #19096 has been updated by nobu (Nobuyoshi Nakada). Status changed from Open to Closed It is commit:git|296a2cab. See also the related [changesets](https://bugs.ruby-lang.org/issues/17544?tab=changesets). ---------------------------------------- Misc #19096: [Question] Time with `-00:00` offset is in UTC https://bugs.ruby-lang.org/issues/19096#change-101538 * Author: andrykonchin (Andrew Konchin) * Status: Closed * Priority: Normal ---------------------------------------- It's a bit unexpected but ```ruby Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => true ``` But time with `+00:00` or `0` offset is treated as not UTC time: ```ruby Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false ``` Is it an intentional behaviour? In this case could you please clarify the reason why it works this way? --- ``` ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112100] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC
by andrykonchin (Andrew Konchin) 28 Jan '23

28 Jan '23

Issue #19096 has been updated by andrykonchin (Andrew Konchin). @zverok Thank you for pointing at the original ticket. TBH I was waiting so long for some official confirmation because I haven't found any mentioning that https://bugs.ruby-lang.org/issues/17544 affects not only `Time#strftime` method but also a way how `utc offset` argument (in Time construction methods) is handled. Even [added tests](https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revis… don't check this behaviour. ---------------------------------------- Misc #19096: [Question] Time with `-00:00` offset is in UTC https://bugs.ruby-lang.org/issues/19096#change-101536 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal ---------------------------------------- It's a bit unexpected but ```ruby Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => true ``` But time with `+00:00` or `0` offset is treated as not UTC time: ```ruby Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false ``` Is it an intentional behaviour? In this case could you please clarify the reason why it works this way? --- ``` ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111287] [Ruby master Bug#19235] StringIO.new(encoding: "ext_enc:int_enc") doesn't set external encoding
by andrykonchin (Andrew Konchin) 28 Jan '23

28 Jan '23

Issue #19235 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19235: StringIO.new(encoding: "ext_enc:int_enc") doesn't set external encoding https://bugs.ruby-lang.org/issues/19235 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.1.2 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I noticed a divergence between IO `:encoding` option documentation and StringIO's behaviour: ```ruby io = StringIO.new('', 'w', encoding: 'utf-8:ISO-8859-1') io.external_encoding # => #<Encoding:ISO-8859-1> ``` The IO class behaves in expected way: ```ruby f = File.open("test.txt", 'w', encoding: 'UTF-8:ISO-8859-1') f.external_encoding # => #<Encoding:UTF-8> ``` -- https://bugs.ruby-lang.org/

2 3