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

[ruby-core:112546] [Ruby master Bug#19460] inline method cache won't let class be garbage collected
by luke-gru (Luke Gruber) 23 Feb '23

23 Feb '23

Issue #19460 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19460: inline method cache won't let class be garbage collected https://bugs.ruby-lang.org/issues/19460 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'm working on something where I need to remove a class and release all memory related to that class. I've stumbled upon a limitation where in some instances I cannot get the class to be GC'd. The problem (I think) is that inline method caches cache the class, and even if the class would otherwise be gone, it stays. For example: ```ruby class A def do_something self.call_other # inline cache caches class A, so now A is marked every time cache is marked end def call_other end end a = A.new a.send(:do_something) # don't make normal call, use send so no inline cache used here a_id = A.object_id a = nil Object.send(:remove_const, :A) # A should be able to be released now. 10.times { GC.start } a_ref = ObjectSpace._id2ref(a_id) rescue nil puts "a_ref: #{a_ref.class}" ```ruby One solution to this would be if inline caches are inside methods, only mark them when the method itself is marked. I'm guessing they're marked independently right now. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:112558] [Ruby master Feature#18070] `attr` should be removed
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #18070 has been updated by rubyFeedback (robert heiler). There may be backwards compatibility considerations. Personally I never use attr. I use the longer variants, but even these I use less often compared to older code. I tend to put variables for larger classes into an internal hash usually these days. Perhaps if backwards compatibility is a concern, there should be a deprecation window announced, before it may then be removed (if it is decided to remove it)? ---------------------------------------- Feature #18070: `attr` should be removed https://bugs.ruby-lang.org/issues/18070#change-102008 * Author: schwad (Nick Schwaderer) * Status: Open * Priority: Normal ---------------------------------------- I'm digging through some older Ruby versions and discovered that `attr` was deprecated in Ruby 1.9. We still are seeing support for it in Ruby 3.0 Unless there are internals that require its existence, is it time to remove this deprecated feature? If there's agreement, I'm more than happy to fire up the PR myself. (Also happy to be corrected if there's something I'm missing here :) ) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112557] [Ruby master Feature#18136] take_while_after
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #18136 has been updated by rubyFeedback (robert heiler). I think one big problem with the proposed name such as the three word one is that they are somewhat rare and difficult to remember. In ruby we often have one word, or two words for methods. We may have some three words if I remember correctly, but these are quite rare, and it is a LOT harder to understand "take_while_after" or "do_this_that", than comparable ".upto()" or ".downto()" and so forth. We kind of have combined "instructions" such as: [3,4,5].each.with_index These are a bit different though. We could of course call such a combined instruction via: [3,4,5].each_with_index so just a single method with three words. But I think semantically it is easier to use .each, standalone as we do now, and then "aggregate" onto it, such as via .with_index. That conveys the meaning quite clearly. With three word names, as a single method, I think it quite a lot more difficult to convey meaning. > I'd rather choose an obvious name, like take_until_after. I think it has a very similar problem as take_while_after. ---------------------------------------- Feature #18136: take_while_after https://bugs.ruby-lang.org/issues/18136#change-102007 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Sorry, I already tried that once (#16441) but I failed to produce the persuasive example. So I am back with a couple of them, much simpler and clear than my initial. **The proposal itself:** Have `take_while_after` which behaves like `take_while` but also includes the last element (first where the condition failed). Reason: there are a lot of cases where "the last good item" in enumeration is the distinctive one (one where enumeration should stop, but the item is still good. **Example 1:** Take pages from paginated API, the last page will have less items than the rest (and that's how we know it is the last): ```ruby (0..).lazy .map { |offset| get_page(offset, limit) } .take_while_after { |response| response.count == limit } # the last will have, say, 10 items, but should still be included! .map { process response somehow } ``` **Example 2:** Same as above, but "we should continue pagination" is specified with a separate data key "can_continue": ```ruby (0..).lazy .map { |offset| get_page(offset, limit) } .take_while_after { |response| response['can_continue'] } # the last will have can_continue=false, but still has data .map { process response somehow } ``` **Exampe 3:** Taking a sentence from a list of tokens like this: ```ruby tokens = [ {text: 'Ruby', type: :word}, {text: 'is', type: :word}, {text: 'cool', type: :word}, {text: '.', type: :punctuation, ends_sentence: true}, {text: 'Rust', type: :word}, # ... ] sentence = tokens.take_while_after { !_1[:ends_sentence] } ``` (I can get more if it is necessary!) Neither of those can be solved by "Using `take_while` with proper condition.", as @matz suggested here: https://bugs.ruby-lang.org/issues/16441#note-9 I typically solve it by `slice_after { condition }.first`, but that's a) uglier and b) greedy when we are working with lazy enumerator (so for API examples, all paginated pages would be fetched at once, and only then processed). Another consideration in #16441 was an unfortunate naming. I am leaving it to discussion, though I tend to like `#take_upto` from #16446. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112556] [Ruby master Feature#17859] Start IRB when running just `ruby`
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #17859 has been updated by rubyFeedback (robert heiler). I don't have a strong opinion on the topic. I am fine either way. Both seem to have a valid point of view, e. g. the "it is convenient" approach. This is kind of true. But, as said, I don't really have any particularly strong pro or con on it, be it a change, or no change. I wanted to comment on two other statements, though: (1) The "it may be slow". Well, one could focus on a "bare irb" or "base irb" behaviour, such as zverok showed (e. g. "python which loads instantaneously, has no syntax highlight, and very simplistic autocomplete"). People could modify the behaviour via irbrc and load add-ons. I once even loaded all my local gems by also using Thread.new {} for loading them, since some took some time, and I thought I could just "insta-start" irb, and type commands, while background loading could proceed. It did not seem to work quite in the way how I thought it would be, so I switched to a "minimal IRB" again, where I really just start the things I need on a daily basis, and load other things only when I need it. I don't know whether irb is slow or not compared to python startup, but I feel that this question can be approached, even if it is just a mini-irb with less functionality. The main question should be whether it is worth to change the default behaviour, e. g. if more newcomers would think this is better, than typing a separate command (e. g. irb). That should be the primary question, the other questions are secondary to that one, I would think. (2) In regards to the "war", let's call it rather a "difference in approach" (irb versus pry). The way how I see it irb adopted what seemed useful from pry, even before the later rewrite that took place, without necessarily going the full introspection route that pry adopted from the get go. So I see these two more as a separate projects really, but irb learning from pry more than pry would learn from irb (since it has a slightly different use case). I don't think this is a bad thing. If anyone remembers, there was a time we did not have BasicObject, and if memory serves me well _why was important in suggesting it, as he was testing an interactive ruby on a website, and there having some "vanilla state" seemed important (probably also with SAFETY or what old security checks were still in place, to get it to work in a browser; of course since then we can do so; I think there is a project on github that does that, hsbt contributed to it if I remember correctly, but I forgot the name of that project). ---------------------------------------- Feature #17859: Start IRB when running just `ruby` https://bugs.ruby-lang.org/issues/17859#change-102006 * Author: deivid (David Rodríguez) * Status: Open * Priority: Normal ---------------------------------------- Compare python: ``` $ python Python 3.8.3 (default, Jul 8 2020, 16:49:12) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ``` To ruby: ``` $ ruby # just hangs ``` I think firing up a console it's a good default behaviour for beginners. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111225] [Ruby master Bug#19189] Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime
by mistydemeo (Misty De Meo) 23 Feb '23

23 Feb '23

Issue #19189 has been reported by mistydemeo (Misty De Meo). ---------------------------------------- Bug #19189: Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime https://bugs.ruby-lang.org/issues/19189 * Author: mistydemeo (Misty De Meo) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Starting with Ruby 3.1.3, mkmf.rb calls to `pkg-config` will fail if `pkg-config` wasn't present on the system at the time it was built. Prior to that version, even if Ruby itself wasn't configured with `pkg-config`, mkmf.rb would be able to correctly pick it up from the `PATH`. This was introduced by https://github.com/ruby/ruby/commit/7f1ca666424849134990d022266bcd4d6636465f and its Ruby 3.1.3 equivalent, https://github.com/ruby/ruby/commit/3914581213e3aea138b02941b41e62c15461af27. I've confirmed that reverting this specific change fixes the problem. This broke a Ruby deployment which is built in a minimal Docker environment with no `pkg-config`, but which is later copied into a system with `pkg-config` present. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:112550] [Ruby master Bug#18629] block args array splatting assigns to higher scope _ var
by nagachika (Tomoyuki Chikanaga) 23 Feb '23

23 Feb '23

Issue #18629 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED to 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONE ruby_3_1 536f5ba0d48c033e63398d1751aebd0a11bcc6ff merged revision(s) 3ddf6ad4d2f6dae4caa00b8c407768c7062099a0. ---------------------------------------- Bug #18629: block args array splatting assigns to higher scope _ var https://bugs.ruby-lang.org/issues/18629#change-101997 * Author: Nakilon (Victor Maslov) * Status: Closed * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONE ---------------------------------------- ``` ruby v = 1; [[2]].each{ |(v)| }; p v _ = 1; [[2]].each{ |(_)| }; p _ ``` prints ``` 1 2 ``` You can see here that `v` is still `1` but `_` isn't shadowed properly and is being assigned `2`. Reproducible from 2.3.8 to 3.0.2 (macOS rbenv) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112549] [Ruby master Bug#18765] Wrong description introduced by https://github.com/ruby/ruby/pull/4938/files
by nagachika (Tomoyuki Chikanaga) 23 Feb '23

23 Feb '23

Issue #18765 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: DONTNEED, 3.0: DONTNEED, 3.1: REQUIRED to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONE ruby_3_1 9f072e9ae1bae2d76334c9e97a47280779768859 merged revision(s) 8038d5e40a079d60dfcf7cab1155528959760c28. ---------------------------------------- Bug #18765: Wrong description introduced by https://github.com/ruby/ruby/pull/4938/files https://bugs.ruby-lang.org/issues/18765#change-101996 * Author: sawa (Tsuyoshi Sawada) * Status: Closed * Priority: Normal * Assignee: burdettelamar(a)yahoo.com (Burdette Lamar) * ruby -v: 3.1.0 * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONE ---------------------------------------- Commit https://github.com/ruby/ruby/pull/4938/files introduced problems and made the description wrong. 1) For methods `slice_after` and `slice_when`, it introduces expressions like "partition elements into arrays ('slices')", and for method `chunk_while`, "partition elements into arrays ('chunks')". It suggests to call the resulting elements using different words depending on the name of the method. But that does not make sense. They are all simply arrays, and there is no need to distinguish a "slice array" from a "chunk array". (They can all be called an "array", "slice", or "chunk", or whatever.) Perhaps, it is attempting to explain where the method names came from, under the assumption that the words "slice" and "chunk" in these method names are nouns. If so, that is wrong. The succeeding parts "when (block)" and "while (block)" are (to correspond to English) adverbial clauses, not adjectival (relative) clauses; hence, these "slice" and "chunk" must be interpreted as verbs, not nouns. In fact, "a slice when y is not a successor of x" or "a chunk while y is a successor of x" does not make sense, whereas "slice it when y is not a successor of x" and "chunk them while y is a successor of x" do make sense. The difference between the "slice" and "chunk" methods lies in the process, not the return value. If you want to use these words, it can be something like "slice the receiver into arrays when the block returns a truthy value" and "chunk the elements together while the block returns a truthy value". 2) In the description of `slice_when` and `chunk_while`, it says "it calls the block with each element and its successor", but that is not true. If you are going to phrase it that way, then it only calls each element except for the last one. 3) In the description of `slice_when`, it says "begins a new slice if and only if the block returns a truthy value", but that is not true. Regardless of the value of the block, the first element always begins a new "slice". 4) Most crucially, in the description of `chunk_while`, the expression "begins a new chunk if and only if the block returns a truthy value" is entirely wrong. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111053] [Ruby master Bug#19158] Ruby 3.1.3 installs wrong gemspec for debug gem
by deivid 23 Feb '23

23 Feb '23

Issue #19158 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #19158: Ruby 3.1.3 installs wrong gemspec for debug gem https://bugs.ruby-lang.org/issues/19158 * Author: deivid (David Rodríguez) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- A pristine installation of Ruby 3.1.3 shows an installed `debug-1.6.3.gemspec` file that claims that debug-1.6.3 has no dependencies. This is incorrect, and causes issues for Bundler as reported at https://github.com/rubygems/rubygems/issues/6082. An issue workaround is to manually reinstall the gem with `gem install debug:1.6.3`. That will reinstall the gem, including a correct gemspec file. This is the file diff before and after reinstalling the gem ```diff --- old.gemspec 2022-11-29 13:54:36 +++ /Users/deivid/.asdf/installs/ruby/3.1.3/lib/ruby/gems/3.1.0/specifications/debug-1.6.3.gemspec 2022-11-29 13:55:25 @@ -24,4 +24,16 @@ s.summary = "Debugging functionality for Ruby".freeze s.installed_by_version = "3.3.26" if s.respond_to? :installed_by_version + + if s.respond_to? :specification_version then + s.specification_version = 4 + end + + if s.respond_to? :add_runtime_dependency then + s.add_runtime_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_runtime_dependency(%q<reline>.freeze, [">= 0.3.1"]) + else + s.add_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_dependency(%q<reline>.freeze, [">= 0.3.1"]) + end end ``` In general, the files installed by ruby-core for bundled gems should be identical to the ones installed by explicit `gem install`. This issue is also present in master and I'm guessing it was introduced by https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53 (backported at https://github.com/ruby/ruby/commit/2d26e45135af8b427d9ccc6d47082c21be8b9c74) -- https://bugs.ruby-lang.org/

3 9

[ruby-core:111022] [Ruby master Bug#19153] Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot
by cpinto (Celso Pinto) 23 Feb '23

23 Feb '23

Issue #19153 has been reported by cpinto (Celso Pinto). ---------------------------------------- Bug #19153: Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot https://bugs.ruby-lang.org/issues/19153 * Author: cpinto (Celso Pinto) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.7p221 (2022-11-24 revision 168ec2b1e5) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The rspec tests of our Rails app started failing with an ArgumentError after upgrading to 2.7.7. On inspection, the issue seems to be caused by CGI::Cookie.domain=: ``` def domain=(str) if str and ((str = str.b).bytesize > 255 or !DOMAIN_VALUE_RE.match?(str)) raise ArgumentError, "invalid domain: #{str.dump}" end @domain = str end ``` Setting a breakpoint: 0> str => ".example.com" 0> DOMAIN_VALUE_RE => /\A(?<label>(?!-)[-A-Za-z0-9]+(?<!-))(?:\.\g<label>)*\z/ 0> DOMAIN_VALUE_RE.match?(str) => false 0> DOMAIN_VALUE_RE.match?('example.com') => true -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112537] [Ruby master Misc#18761] provide an example wasm project
by rubyFeedback (robert heiler) 22 Feb '23

22 Feb '23

Issue #18761 has been updated by rubyFeedback (robert heiler). > need more getting started instructions? I think it may be helpful if there would be something like a "mini-tutorial", in the sense that you could go from a super simple use case (hello world), towards something that is a bit more useful (something like tic-tac-toe, in the browser, or even just something simpler, like a mini-calculator), to a tiny bit more advanced (but not too overly complicated). Right now the documentation only has "Create and save index.html page with the following contents", but even when you do this, and then load it into your browser, you don't see anything happening. So something is missing. This may be super-trivial for WASM folks who already understand how this works, but for anyone new to the topic, it kind of means that you need to go to another language if you want to understand how this all works right now. Which is unfortunate, because it may be that WASM works well, but this is not shown to others how this can be done, because there is sparsely any documentation. > You can find pre-compiled wasm files on GitHub: > https://github.com/ruby/ruby.wasm/releases The problem here is that the README at https://github.com/ruby/ruby.wasm does not really explain what one can do with this. It seems as if this is all geared more towards advanced users. Interestingly, I checked python + WASM, and the documentation it shows here: https://pythondev.readthedocs.io/wasm.html Is also very, very bad. I don't know why the WASM documentation is in general so bad. The only exception here is mozilla, which actually has a very decent documentation here: https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_A… So it is a bit as if one has to read these other websites first (such as the mozilla one) before being able to dive into the ruby-wasm or python-wasm aspect of it. ---------------------------------------- Misc #18761: provide an example wasm project https://bugs.ruby-lang.org/issues/18761#change-101984 * Author: grosser (Michael Grosser) * Status: Open * Priority: Normal * Assignee: katei (Yuta Saito) ---------------------------------------- Neither the release notes nor the wasm/README.md include any runnable examples. Please provide a docker image that can be used to generate a wasm binary (even if it's just "hello world"), to show how this is supposed to work. -- https://bugs.ruby-lang.org/

1 0