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

[ruby-core:112480] [Ruby master Bug#19449] en-us
by Kongpcmail (KAMPANAT THUMWONG) 17 Feb '23

17 Feb '23

Issue #19449 has been reported by Kongpcmail (KAMPANAT THUMWONG). ---------------------------------------- Bug #19449: en-us https://bugs.ruby-lang.org/issues/19449 * Author: Kongpcmail (KAMPANAT THUMWONG) * Status: Open * Priority: Normal * ruby -v: -vomm * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- KAMPANAT THUMWONG ---Files-------------------------------- FFX for Families.en.txt (941 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112476] [Ruby master Bug#19041] Weakref is still alive after major garbage collection
by parker (Parker Finch) 17 Feb '23

17 Feb '23

Issue #19041 has been updated by parker (Parker Finch). File manifest_weakref_issue.rb added Hi @tenderlovemaking! I'm having difficulty interpreting the results of the `ObjectSpace` dump and I'm hoping you can help. I've adjusted the script to print out the address of the underlying object, and then (when the issue manifests) print all lines from `ObjectSpace.dump_all` that match that address. The code is attached, here's some example output: ``` Ruby version: 3.3.0 Iteration: 0 Object address: 0x1051cd788 Inner iterations: 1 Iteration: 1 Object address: 0x105205ae8 Inner iterations: 1 Inner iterations: 2 Inner iterations: 3 {"address":"0x105205ae8", "type":"OBJECT", "shape_id":5, "slot_size":40, "class":"0x1029bfe80", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} {"address":"0x10520da90", "type":"STRING", "shape_id":0, "slot_size":40, "class":"0x1029beda0", "embedded":true, "bytesize":11, "value":"0x105205ae8", "encoding":"UTF-8", "coderange":"7bit", "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} ``` In that example, the underlying object was at `0x105205ae8`. But as far as I can tell, there's nothing else that points at it. (The other object there is the String used to hold that address.) I would have expected that, if nothing was referencing it, it would be collected by GC. One interesting tidbit is that just calling `ObjectSpace.dump_all` prevents the issue from manifesting. Is it possible that something _was_ referencing the object address, then running `dump_all` caused that reference to be removed? ---------------------------------------- Bug #19041: Weakref is still alive after major garbage collection https://bugs.ruby-lang.org/issues/19041#change-101919 * Author: parker (Parker Finch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I am able to get into an infinite loop waiting for garbage collection to take a WeakRef. ### Reproduction Process The following script prints a "0", then a "1", and then hangs forever. I expect it to keep printing numbers. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) GC.start while obj.weakref_alive? iterations += 1 end ``` ### Ruby Version I have tested this on Ruby 3.1.2, 3.1.0, 3.0.4, 3.0.0, 2.7.6, and 2.7.0 on macOS. All exhibit this behavior. ### Further Investigation #### Sleeping Sleeping before the garbage collection allows the loop to continue. The below exhibits the expected behavior: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (sleep(0.5); GC.start) while obj.weakref_alive? iterations += 1 end ``` However, sleeping _after_ the garbage collection still shows the buggy behavior (loop hangs): ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (GC.start; sleep(0.5)) while obj.weakref_alive? iterations += 1 end ``` #### Running Garbage Collection Multiple Times Explicitly running garbage collection multiple times allows the loop to continue. This has the expected behavior, more numbers continue to be printed: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) while obj.weakref_alive? GC.start GC.start GC.start end iterations += 1 end ``` However, with certain rubies, running those garbage collection calls in a `times` block prevents even a single iteration from completing. The following prints only "0" with ruby 3.0.4 on macOS, ruby 2.7.6 on macOS, and ruby 3.1.2 on linux (`ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]` on a virtual machine). It shows the expected behavior on ruby 3.1.2 on macOS. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) 3.times { GC.start } while obj.weakref_alive? iterations += 1 end ``` ---Files-------------------------------- manifest_weakref_issue.rb (1.52 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112474] [Ruby master Bug#19446] Remove `compiler_wd` related warnings in `tool/update-deps`
by eightbitraptor (Matthew Valentine-House) 17 Feb '23

17 Feb '23

Issue #19446 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19446: Remove `compiler_wd` related warnings in `tool/update-deps` https://bugs.ruby-lang.org/issues/19446 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Github PR #7331](https://github.com/ruby/ruby/pull/7331) The update deps tool uses intermediary build files to verify dependencies. When these `*.i` files are generated by `gcc` the second line is always of the form ``` # 1 "/home/runner/work/ruby/ruby//" ``` Which `update-deps` attempts to parse out and set as the compiler working directory. It iterates through the intermediary files and sets `compiler_wd` in this loop: ```ruby compiler_wd = nil path_i.each_line {|line| next if /\A\# \d+ "(.*)"/ !~ line dep = $1 next if %r{\A<.*>\z} =~ dep # omit <command-line>, etc. next if /\.e?rb\z/ =~ dep compiler_wd ||= dep files[dep] = true } ``` This will always end up setting `compiler_wd` to the first line in the file, rather than the second, which means the subsequent check for the special gcc compiler dir line will fail, that line will be left in the resulting dependancy lists and manifests later on as warnings. We can see these by looking at any Github Actions Check Dependancies run [like this one](https://github.com/ruby/ruby/actions/runs/4200439119/jobs/7286451096). The warnings look like this ``` warning: file not found: /home/runner/work/ruby/ruby// warning: file not found: /home/runner/work/ruby/ruby// warning: file not found: /home/runner/work/ruby/ruby// ... ( ~350 lines of this) ``` The referenced PR fixes the way `compiler_wd` is set, in order to get rid of the warnings. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112469] [Ruby master Feature#18597] Strings need a named method like `dup` that doesn't duplicate if receiver is mutable
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18597 has been updated by rubyFeedback (robert heiler). > And it feels like I cannot convince anyone here with any amount of rationale Ultimately you only have to convince matz, so you could ignore what others write. But one reason why there was a reference to real-needs is that the ruby core/dev team said that they focus on real needs (although they may evaluate what is real and what is not ultimately, as well as the cost of addition of methods). My personal opinion is that, usage aside, the .dup_if_immutable feels very clunky. The simplest variant is of course the oldschool ruby: string_object << "More content." I use this pattern, which is a bit verbose: string_object = string_object.dup if string_object.frozen? Then there is that +@ variant. I avoid it, but I guess one reason why it is used is because it is quite short. From a user's perspective, the << usage in oldschool ruby before frozen string is the most convenient, but the primary reason why it was changed was due to speed/efficiency. And other languages such as python have immutable strings too so it's a real concern. ---------------------------------------- Feature #18597: Strings need a named method like `dup` that doesn't duplicate if receiver is mutable https://bugs.ruby-lang.org/issues/18597#change-101914 * Author: danh337 (Dan H) * Status: Open * Priority: Normal ---------------------------------------- This is related to #16295, but focuses only on the `.+@` part. Currently we can use `.dup` in a method chain when we need to mutate a String. However there are cases where the code's context *expects* the String to be mutated. In cases like this, `.dup` always works, but we don't want to duplicate a String that is already mutable. Since `.+@` looks more like an operator, it can be unintuitive in a method chain, so this is asking for a new named method that can be used in its place, instead of always `.dup`. For example: ``` def add_result_text(buffer, new_result) text = "#{new_result.count} #{new_result.input} #{do_fancy_calc(new_result)}\n" buffer.dup_if_immutable << text # ^^^^^^^^^^^^^^^^ new method? end buffer = "" # ...maybe immutable get_lots_of_results.each do |result| buffer = add_result_text(buffer, result) # In case it was dup'ed end ``` ---Files-------------------------------- driver.rb (12.3 KB) driver.rb (12.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112468] [Ruby master Feature#18690] Allow `Kernel#then` to take arguments
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18690 has been updated by rubyFeedback (robert heiler). I do not have any strong opinions either way, but Benoit wrote: > The last example is just: p.call(honyarara, fugafugafuga, hogehogehoge) > isn't it? And that's a lot more readable IMHO. Versus: honyarara.then(fugafugafuga, hogehogehoge, &p) And I am not sure the .call() is per se more readable. I agree about the trailing &p part; that one looks a bit weird. I guess it is just the block. But ignoring this, if it is merely between .call versus .then, then I think .then may be quite explicit and perhaps "more readable", whatever that means. So I am not sure that .call() is implicitely more readable than .then(). Although, I think one problem is that some ruby authors write code like: if condition then do_something end Or something like that. I never used that style, but some folks used that style in the past. So perhaps it's not quite so readable if we include the totality of the syntax out there. zverok wrote: 3.then.with_object(4).with_object(5).map { |(x, y), z| x + y + z }.first Is this still ruby though? :P ---------------------------------------- Feature #18690: Allow `Kernel#then` to take arguments https://bugs.ruby-lang.org/issues/18690#change-101913 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#then` passes the receiver to the block as its first positional block parameter. ```ruby 1.5.then{|x| Math.atan(x)} ``` I would like to propose to let `then` take arguments, which would be passed to the block as the other block parameters. ```ruby 3.then(4){|x, y| Math.hypot(x, y)} ``` There are two uses. First, to separate bulky or repeated parameters from the routine. Instead of writing: ```ruby honyarara.then{|x| foo(x) bar(fugafugafuga) baz(hogehogehoge) qux(x, fugafugafuga, hogehogehoge) } ``` we can then write: ```ruby honyarara.then(fugafugafuga, hogehogehoge){|x, y, z| foo(x) bar(y) baz(x) qux(x, y, z) } ``` Second, to use a proc with multiple parameters when, for some reason, you do not want to define a method to do it: ```ruby p = ->(x, y, z){ foo(x) bar(y) baz(x) qux(x, y, z) } honyarara.then(fugafugafuga, hogehogehoge, &p) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112467] [Ruby master Feature#18841] Proposal: autoload_relative
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18841 has been updated by rubyFeedback (robert heiler). I am not sure we should add more methods from within that family (autoload-family). Personally I would even remove require_relative, but I guess too much code depends on it nowadays. ---------------------------------------- Feature #18841: Proposal: autoload_relative https://bugs.ruby-lang.org/issues/18841#change-101912 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal ---------------------------------------- In my experience, autoloads often reflect an existing hierarchical structure. If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_re…. (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_sup…) I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112466] [Ruby master Feature#19024] Proposal: Import Modules
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #19024 has been updated by rubyFeedback (robert heiler). Personally I think it may be better to leave require(), load() and require_relative() unchanged as-is, and instead add a new, more sophisticated way for ruby to handle loading of stuff in general. That one should then ideally be as flexible as possible, and "extensible" for the future. It could then also allow all of our needs and wants. Many years ago, for instance, I wanted to be able to load up a specific module, but instantly, upon load-time, assign it a new different name. We can kind of simulate that way e. g. require 'foobar' Barfoo = Foobar # and then setting Foobar to nil, I suppose, or # something like that But I wanted that on the require/load situation. We could also integrate autoload-like behaviour into it. And so on and so forth. That could also mean to load ruby code "outside" of any "namespace". Such as "anonymous loading" not polluting the namespace. I am not sure we should add "import" as such, though. People will ask when to use include, and extend, and then import. So I kind of agree with fxn that we should leave require and load as it is, and instead think about more flexible loading/requiring of code as-is. Another feature I wanted to have is that we can assign "authors" to a namespace - not in a way to deny people from using them, but simply to be able to track who made modifications where and when. In some ways this is similar to how refinements can be thought of - we can think of them as "isolated namespace changes" but allowing us more control over the code changes (if we ignore the syntax; I always found the syntax odd for refinements). Perhaps we should create a more unified proposal eventually that can unify all the different ideas, pros and cons, for matz to think about what the best approach would be. One thing austin wrote: > I don’t see any value in namespacing beyond what Ruby has > through modules and classes. I certainly don’t see any > value in the ability to load more than one version of a > piece of code at a time under a different namespace (this > is, IMO, one of the worst parts of JavaScript). Well, refinements already does that to some extent; and I can see the potential value in knowing who made modifications where and when. Right now we all have one unified namespace. This can lead to problems sometimes. I agree it is not a huge problem per se, but when I write: class Colors And some other package is: module Colors and I already included that, then there are some problems. (Or, both use class, or module, and then I may overwrite some toplevel method or a similar problem.) It's not a huge problem per se, mind you, but in these cases, being able to "tap" into a class or module and see where changes were made, when, by whom, and in which package/file, can be useful in my opinion. That is not to say I agree with the proposal here per se, but I wanted to comment on whether there may be use cases - and I think there are. I don't know of a good syntax-way to tap into any of that though. I just think we should be open about different ways how to load up code in ruby, because there are definitely use cases that are not fully covered by require and load. (I use require() about 98% of the time, and I avoid autoload, because I found that the cognitive load of having to remember how to use it offsets the benefits it brings; I also don't need require_relative. I do sometimes need to use load(), e. g. dynamic reloading of code if you need it, but I can see different use cases most assuredly.) ---------------------------------------- Feature #19024: Proposal: Import Modules https://bugs.ruby-lang.org/issues/19024#change-101911 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- There is no general way in Ruby to load code outside of the globally-shared namespace. This makes it hard to isolate components of an application from each other and from the application itself, leading to complicated relationships that can become intractable as applications grow in size. The growing popularity of a gem like [Packwerk](https://github.com/shopify/packwerk), which provides a new concept of "package" to enforce boundaries statically in CI, is evidence that this is a real problem. But introducing a new packaging concept and CI step is at best only a partial solution, with downsides: it adds complexity and cognitive overhead that wouldn't be necessary if Ruby provided better packaging itself (as Matz has suggested [it should](https://youtu.be/Dp12a3KGNFw?t=2956)). There is _one_ limited way in Ruby currently to load code without polluting the global namespace: `load` with the `wrap` parameter, which as of https://bugs.ruby-lang.org/issues/6210 can now be a module. However, this option does not apply transitively to `require` calls within the loaded file, so its usefulness is limited. My proposal here is to enable module imports by doing the following: 1. apply the `wrap` module namespace transitively to `require`s inside the loaded code, including native extensions (or provide a new flag or method that would do this), 2. make the `wrap` module the toplevel context for code loaded under it, so `::Foo` resolves to `<top_wrapper>::Foo` in loaded code (or, again, provide a new flag or method that would do this). _Also make this apply when code under the wrapper module is called outside of the load process (when `top_wrapper` is no longer set) — this may be quite hard to do_. 3. resolve `name` on anonymous modules under the wrapped module to their names without the top wrapper module, so `<top_wrapper>::Foo.name` evaluates to `"Foo"`. There may be other ways to handle this problem, but a gem like Rails uses `name` to resolve filenames and fails when anonymous modules return something like `#<Module: ...>::ActiveRecord` instead of just `ActiveRecord`. I have roughly implemented these three things in [this patch](https://github.com/ruby/ruby/compare/master...shioyama:ruby:import_m…. This implementation is incomplete (it does not cover the last highlighted part of 2) but provides enough of a basis to implement an `import` method, which I have done in a gem called [Im](https://github.com/shioyama/im). Im provides an `import` method which can be used to import gem code under a namespace: ```ruby require "im" extend Im active_model = import "active_model" #=> <#Im::Import root: active_model> ActiveModel #=> NameError active_model::ActiveModel #=> ActiveModel active_record = import "active_record" #=> <#Im::Import root: active_record> # Constants defined in the same file under different imports point to the same objects active_record::ActiveModel == active_model::ActiveModel #=> true ``` With the constants all loaded under an anonymous namespace, any code importing the gem can name constants however it likes: ```ruby class Post < active_record::ActiveRecord::Base end AR = active_record::ActiveRecord Post.superclass #=> AR::Base ``` Note that this enables the importer to completely determine the naming for every constant it imports. So gems can opt to hide their dependencies by "anchoring" them inside their own namespace, like this: ```ruby # in lib/my_gem.rb module MyGem dep = import "my_gem_dependency" # my_gem_dependency is "anchored" under the MyGem namespace, so not exposed to users # of the gem unless they also require it. MyGemDependency = dep #... end ``` There are a couple important implementation decisions in the gem: 1. _Only load code once._ When the same file is imported again (either directly or transitively), "copy" constants from previously imported namespace to the new namespace using a registry which maps which namespace (import) was used to load which file (as shown above with activerecord/activemodel). This is necessary to ensure that different imports can "see" shared files. A similar registry is used to track autoloads so that they work correctly when used from imported code. 2. Toplevel core types (`NilClass`, `TrueClass`, `FalseClass`, `String`, etc) are "aliased" to constants under each import module to make them available. Thus there can be side-effects of importing code, but this allows a gem like Rails to monkeypatch core classes which it needs to do for it to work. 3. `Object.const_missing` is patched to check the caller location and resolve to the constant defined under an import, if there is an import defined for that file. To be clear: **I think 1) should be implemented in Ruby, but not 2) and 3).** The last one (`Object.const_missing`) is a hack to support the case where a toplevel constant is referenced from a method called in imported code (at which point the `top_wrapper` is not active.) I know this is a big proposal, and there are strong opinions held. I would really appreciate constructive feedback on this general idea. Notes from September's Developers Meeting: https://github.com/ruby/dev-meeting-log/blob/master/DevMeeting-2022-09-22.m… See also similar discussion in: https://bugs.ruby-lang.org/issues/10320 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112441] [Ruby master Feature#13620] Simplifying MRI's build system: always make install
by Eregon (Benoit Daloze) 15 Feb '23

15 Feb '23

Issue #13620 has been updated by Eregon (Benoit Daloze). FWIW, here is another terrible hack due to trying to run before files have a proper Ruby home structure: https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53 and reported as #19158. ---------------------------------------- Feature #13620: Simplifying MRI's build system: always make install https://bugs.ruby-lang.org/issues/13620#change-101885 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- Hello all, I've been bitten recently when modifying ruby/spec or in #13570 by the sheer number of different configurations to build and test in MRI. Currently, I know 4 of them, and I can tell you it is a big headache to make it work on all of them: * in-source-dir build, running tool/runruby.rb * in-source-dir build, running the installed ruby * out-of-source build, running tool/runruby.rb * out-of-source build, running the installed ruby I just compiled latest MRI this morning, and here are the times: * time make -j 8: make -j 8 373.22s user 30.88s system 404% cpu 1:39.99 total * time make -j 8 install-nodoc make -j 8 install-nodoc 3.29s user 0.55s system 259% cpu 1.477 total So I am wondering, should we just test with the installed ruby since installing it takes only marginally more time than building? The current complexity of runruby.rb, the generated ./rbconfig.rb, etc, all to support testing from the built ruby seems not worth it. It also means all the tests need to accommodate this different layout and are essentially testing a ruby layout that nobody uses in production. On the other hand, testing the installed ruby would test something which is much closer to what is released and used in production, and massively simplify the setup to test by making installed layout assumptions hold (e.g.: RbConfig.ruby points to the current ruby and ruby needs no flags to execute correctly). Did I miss something? I also wish we could choose one of in-source/out-of-source and not having to support both, but let's talk about make/make install first. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112426] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by rubyFeedback (robert heiler) 14 Feb '23

14 Feb '23

Issue #18980 has been updated by rubyFeedback (robert heiler). If I recall correctly I suggested @1 @2 and so forth. At a later time _1 _2 and so forth was added, which is not entirely the same. I then realised that the suggestion was actually much older than my suggestion, and the ruby core team often said they may build upon suggestions and modify it. What surprised me was that one of my use case was not implemented, at the least back then. Which was: @large_collection_as_an_array.each {|cats_with_a_fluffy_tail, dogs_with_cute_ears, ships_with_red_painting, cars_without_a_door| } For such a situation, in particular in IRB as well as in quick debugging, I wanted to be able to refer to the element at hand quickly, without having to remember the name as such. So I could then do: pp @1 pp @3 And so on. Unfortunately it seems as if that was not considered, and it was (back then at the least) made forbidden to assign proper (long) names to the block variables. The syntax was also changed; I find _1 _2 a bit hard to read. I should note that I remember the other proposal about "it". I don't have a strong opinion against it. But I also don't feel particularly committed towards wanting to use it. The whole point of @1 @2 was actually to help in prototyping, e. g. to be faster when you write code initially. It's not a huge saving of time, admittedly so, but it does help, and I think in particular for IRB it can really be helpful (I'd wish we could still use _1 _2 and so forth together with real names of the variables; my use case was that I am fine with the initial block names, and I would keep them, but in the middle of writing more code, I just want to refer to the variable without necessarily always needing to remember the name. I have to scroll back with my crappy editor.) maedi wrote: > I see that $. is already a pre-defined variable which would > make $.method_name difficult to parse. All $-variables are quite hard to remember. With @1 or _1 this is a bit different because, like in a regex, you just refer to some specific group by number rather than a name. (Or just syntax, as is the case with the various $: $< and what not.) maedi wrote: > Though I still like _@. That one trips my brain up. I think we should be conservative about syntax. Perlisms can be useful due to begin succinct, but readability is also a useful metric to have. What surprised me the most is that people began to include _1 _2 and so forth in real production code. To me it is purely a method of testing and debugging aid; but I guess the moment you add functionality someone is going to use it, and a few of these change their style to include these. maedi wrote: > Another thing you could do which is very Ruby is provide a > special block param that acts as an object and interact > with that: I have no real problem with "it", even though I most likely won't use it. But we could use "it" also as reference object via [] method e. g. it[0], it[1] in addition to "normal" use of "it". adiel wrote: Over time I decided to always use a variable named x for such purposes: map.keys.select{|x| x =~ /foo/}. ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-101874 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. ### Why I don't use `_1` I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. ## Proposal Hoping to introduce `it` as an alternative to `_1` later, experiment with warning `#it` method calls without any arguments or blocks. If nobody sees serious problems after some warning period, we'll implement `it` as follows: ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112422] [Ruby master Feature#17853] Add Thread#thread_id
by Eregon (Benoit Daloze) 14 Feb '23

14 Feb '23

Issue #17853 has been updated by Eregon (Benoit Daloze). FWIW, it seems the `Thread#inspect` change wasn't merged. ---------------------------------------- Feature #17853: Add Thread#thread_id https://bugs.ruby-lang.org/issues/17853#change-101870 * Author: komamitsu (Mitsunori Komatsu) * Status: Closed * Priority: Normal ---------------------------------------- # Abstract New method `Thread#thread_id` to get associated native thread id (LWP.) It might return `nil` if OS doesn't support thread id or equivalent. # Background When I tried to investigate which Ruby thread of an application is busy, I did the following steps - checked the CPU usage of the Ruby application's threads using `ps -eLf` or `top` (with H key) and got which thread is busy - dumped all the threads of the application using https://github.com/frsyuki/sigdump - tried to find a busy thread in the thread dump result, but the thread dump doesn't contain thread id... `Thread` class itself has no method to get associated thread id. If the class has `#thread_id` or something, I can create a PR on `sigdump` project to add `thread id` in thread dump output to make investigations with thread dump much easier. `Thread#name` may seem an alternative to `Thread#thread_id`, but `Thread#name` just returns a value that's set through `Thread#name=` while `Thread#thread_id` returns a thread id that OS or something has assigned. In case of Java, thread dump created by `jcmd ${pid} Thread.print` contains `nid` field which is an associated native thread id ``` "http-bio-80-exec-77" daemon prio=6 tid=0x0000000026f29000 nid=0xbd0 runnable [0x0000000020c7f000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:516) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501) at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:167) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:946) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:315) - locked <0x00000007b16e3e88> (a org.apache.tomcat.util.net.SocketWrapper) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ``` -- https://bugs.ruby-lang.org/

1 0