[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116340] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
From:
"byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Date:
2024-01-19 19:48:55 UTC
List:
ruby-core #116340
Issue #19117 has been updated by byroot (Jean Boussier).
> That's just how Ruby code is written nowadays.
It's a common pattern for classes that are long enough, but it's also very common to cram multiple smaller classes in the same file, or multiple classes that are alternative implementations of the same interface.
The pattern is very common in Rails project because the autoloader forces you into a convention, but in gems or non-rails projects, anything goes.
And even in Rails projects, it's common not to extra small sub constants in their own file:
```ruby
# user.rb
class User
class Permission
# a dozen lines, not worth creating `user/permission.rb`
end
end
```
And that also include numerous methods from the Ruby standard libraries, e.g.: `shellwords`
```
>> foo.shelljoin(1)
/Users/byroot/.rbenv/versions/3.3.0/lib/ruby/3.3.0/shellwords.rb:239:in `shelljoin': wrong number of arguments (given 1, expected 0) (ArgumentError)
```
Good luck guessing what `shelljoin` was called on.
With this patch it would be:
```
>> foo.shelljoin(1)
/Users/byroot/.rbenv/versions/3.3.0/lib/ruby/3.3.0/shellwords.rb:239:in `Array#shelljoin': wrong number of arguments (given 1, expected 0) (ArgumentError)
```
In other words, the `Class#method` pattern make it super easy to lookup the documentation, the path and line number, not so much. Personally I spend half my time opening the source of my dependencies, but for less confirmed users, opening the stdlib to read the source isn't a nice value proposition.
----------------------------------------
Feature #19117: Include the method owner in backtraces, not just the method name
https://bugs.ruby-lang.org/issues/19117#change-106365
* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
* Target version: 3.4
----------------------------------------
```
module Foo
class Bar
def inspect
1 + '1'
end
end
end
p Foo::Bar.new
```
This code produce the following backtrace:
```
/tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError)
from /tmp/foo.rb:4:in `inspect'
from /tmp/foo.rb:9:in `p'
from /tmp/foo.rb:9:in `<main>'
```
This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on.
I propose that we also include the owner name:
```
/tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError)
from /tmp/foo.rb:4:in `Foo::Bar#inspect'
from /tmp/foo.rb:9:in `Kernel#p'
from /tmp/foo.rb:9:in `<main>'
```
I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code.
This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/