[#100689] [Ruby master Feature#17303] Make webrick to bundled gems or remove from stdlib — hsbt@...
Issue #17303 has been reported by hsbt (Hiroshi SHIBATA).
11 messages
2020/11/02
[#100852] [Ruby master Feature#17326] Add Kernel#must! to the standard library — zimmerman.jake@...
Issue #17326 has been reported by jez (Jake Zimmerman).
24 messages
2020/11/14
[#100930] [Ruby master Feature#17333] Enumerable#many? — masafumi.o1988@...
Issue #17333 has been reported by okuramasafumi (Masafumi OKURA).
10 messages
2020/11/18
[#101071] [Ruby master Feature#17342] Hash#fetch_set — hunter_spawn@...
Issue #17342 has been reported by MaxLap (Maxime Lapointe).
26 messages
2020/11/25
[ruby-core:100956] [Ruby master Feature#17143] Improve support for warning categories
From:
merch-redmine@...
Date:
2020-11-20 05:28:12 UTC
List:
ruby-core #100956
Issue #17143 has been updated by jeremyevans0 (Jeremy Evans). naruse (Yui NARUSE) wrote in #note-13: > In regard to #17055, Instead of new feature to suppress warning, how about assuming `@foo = nil` is that. `@foo = nil` sets the instance variable, with the negative performance implications of doing so. See https://bugs.ruby-lang.org/issues/17055#note-13. This is a realistic benchmark (not a microbenchmark) that shows it is 100-150% faster to not set instance variables to nil when using Sequel with PostgreSQL to return rows from the database. The whole point of suppressing instance variable warnings is to allow the highest possible performance without warnings. Similarly, the whole point of suppressing method redefinition warnings is to allow atomic method replacement without alias hacks. > `instance_variable_get` and so on should also be mimicked. I'm not sure I understand this point, could you explain? ---------------------------------------- Feature #17143: Improve support for warning categories https://bugs.ruby-lang.org/issues/17143#change-88613 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- Support was recently added for Warning.warn to accept a `category` keyword. However, the initial implementation was limited to having `rb_warn_deprecated` and `rb_warn_deprecated_to_remove` use the `:deprecated` value for the `category` keyword. It doesn't make sense to me to have a `category` keyword if it is only used for deprecation, so I propose we extend the support so that `Kernel#warn` accepts a category keyword (for Ruby-level warnings) and `rb_category_warn` and `rb_category_warning` functions be added to the C-API (for C-level warnings). I also propose that we change existing `rb_warn` and `rb_warning` calls to `rb_category_warn` and `rb_category_warning`, so that all warnings issued by core Ruby are issued with an appropriate category. I have implemented support for this in a pull request: https://github.com/ruby/ruby/pull/3508 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>