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

[ruby-core:112211] [Ruby master Bug#19411] GC issue with moved objects
by luke-gru (Luke Gruber) 04 Jan '24

04 Jan '24

Issue #19411 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19411: GC issue with moved objects https://bugs.ruby-lang.org/issues/19411 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This crashes: ```ruby class Obj def initialize @obj = 3 end end GC.stress = true r = Ractor.new do obj = receive p obj end obj = Obj.new r.send(obj, move: true) r.take ``` It only crashes with nested objects, if you remove the ivar set in `initialize` it works fine. Maybe missing `RB_GC_GUARD`? -- https://bugs.ruby-lang.org/

1 2

[ruby-core:116018] [Ruby master Feature#15927] Allow string keys to be used for String#% and sprintf methods
by luke-gru (Luke Gruber) 04 Jan '24

04 Jan '24

Issue #15927 has been updated by luke-gru (Luke Gruber). This can be closed as I agree with the feedback given. Thanks! ---------------------------------------- Feature #15927: Allow string keys to be used for String#% and sprintf methods https://bugs.ruby-lang.org/issues/15927#change-106008 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal ---------------------------------------- Right now, in the methods sprintf() and String#%, only symbol keys can be used for named interpolation. For example (from the example documentation): "foo = %{foo}" % { :foo => 'bar' } #=> "foo = bar" String keys do not work like this: "foo = %{foo}" % { 'foo' => 'bar' } #=> raises KeyError I think string keys should work just the same as symbol keys here. I've created a PR on github for this, perhaps misguidedly, but if can be found here: https://github.com/ruby/ruby/pull/2238 My argument for this feature is that String#gsub() and family works with string keys if given a Hash, for example: "chocolate ice cream".gsub(/\bc/, { 'c' => 'C' }) #=> 'Chocolate ice Cream' Also, I don't like having to symbolize keys in strings unnecessarily, but maybe that just goes back to when Ruby couldn't GC some symbols. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116011] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by matheusrich (Matheus Richard) 04 Jan '24

04 Jan '24

Issue #18035 has been updated by matheusrich (Matheus Richard). I'm not sure this was already mentioned, but this feels related to 3.2's Data class. If this is accepted, should Data classes all be immutable? To quote [the docs](https://docs.ruby-lang.org/en/3.2/Data.html): > Data provides no member writers, or enumerators: it is meant to be a storage for immutable atomic values. But note that if some of data members is of a mutable class, Data does no additional immutability enforcement: > > ```rb > Event = Data.define(:time, :weekdays) > event = Event.new('18:00', %w[Tue Wed Fri]) > #=> #<data Event time="18:00", weekdays=["Tue", "Wed", "Fri"]> > > # There is no #time= or #weekdays= accessors, but changes are > # still possible: > event.weekdays << 'Sat' > event > #=> #<data Event time="18:00", weekdays=["Tue", "Wed", "Fri", "Sat"]> > ``` ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-106004 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115671] [Ruby master Feature#20054] Replace the use of `def` in endless method definitions with a new sigil
by sawa (Tsuyoshi Sawada) 03 Jan '24

03 Jan '24

Issue #20054 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #20054: Replace the use of `def` in endless method definitions with a new sigil https://bugs.ruby-lang.org/issues/20054 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to remove the use of keyword `def` from the syntax of endless method definition, and introduce a new sigil instead of it. There are several possibilities for what character to use as the sigil, but the most seemingly promising one to me at this point is the colon. So, instead of: ```rb def foo = method_body ``` I propose to write ```rb :foo = method_body ``` There a few reasons to dispense with `def` in endless method definition. First, the current syntax for endless method definition looks too similar to conventional method definition. Without endless method definition, we could already define a method in a single line: ```rb def foo; method_body end ``` and compared to this, what the endless method definition does is that, it only saves you from typing the `end` keyword just by replacing the semicolon with an equal sign. This actually had not made much sense to me. Just saving you from typing the keyword `end` looks too small of a change for introducing new syntax. In order for endless method definition syntax to be justified (as a shorthand for conventional method definition), it needs to save more typing. Second, in #19392, some people are claiming to change the precedence involving endless method definition. I agree with Matz and other developers who support the current precedence in which: ```rb def foo = bar and baz ``` is interpreted as: ```rb (def foo = bar) and baz ``` and I understand that the controversy is due to the look and feel of the keyword `def`. `def` has lower precedence than `and` in conventional method definition, although `=` has higher precedence than `and` in variable/constant assignment. Mixing the low-precedence `def` and the high-precedence `=` into a single syntax was the cause of the trouble, according to my opinion. Thence, we should get rid of `def`. Once we do so, we need to distinguish endless method definition from variable/constant assignment in a new way. What came to my mind was to use a single character: a sigil. Especially, using the colon seems to make sense to me for several reasons: Most importantly, assignment to a symbol is impossible, and it currently raises a syntax error, so it would not conflict with variable/constant assignment syntax. Within Ruby syntax, symbol is naturally used to represent a method name. For example, in `foo(&:bar)` constructions, users are used to passing a method name as a symbol. Also, a method definition returns a symbol representing the method name. So, making the endless method definition syntax look superficially like an "assignment to a symbol" would make sense. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:116002] [Ruby master Feature#16495] Inconsistent quotes in error messages
by joshuap (Josh Wood) 03 Jan '24

03 Jan '24

Issue #16495 has been updated by joshuap (Josh Wood). ivoanjo (Ivo Anjo) wrote in #note-25: > matz (Yukihiro Matsumoto) wrote in #note-7: > > It was something cultural. I admit nowadays very few people use backquote as a left-hand quote, but it used to be. I also admit consistent quotes are easier for our eyes when using recent major fonts. But changing those quotes may affect existing log parsers. We have to estimate how big is the influence of the changes. > > > > Matz. > > On the topic of impacting the ecosystem, there have been quite a few changes to how exceptions have been displayed recently: > > * https://bugs.ruby-lang.org/issues/17930 > * https://bugs.ruby-lang.org/issues/18564 > > and even more being discussed https://bugs.ruby-lang.org/issues/19117 . > > Overall the impact on the ecosystem seemed quite small, and the gain in usability was nice. So changing the `` ` `` to a `'` doesn't seem like it would be worse than any of those changes. To chime in here, at Honeybadger we use this regular expression to parse the Ruby backtrace: https://github.com/honeybadger-io/honeybadger-ruby/blob/edc815c136c5d61fb4e… I don't think it should be too difficult for us to support both the old and new quote formats. As a Ruby user myself, I always found the backtick to be odd, and wasn't aware of the history, which is fascinating. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-105997 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115994] [Ruby master Feature#16495] Inconsistent quotes in error messages
by mdalessio (Mike Dalessio) 03 Jan '24

03 Jan '24

Issue #16495 has been updated by mdalessio (Mike Dalessio). It may be interesting to note that the Prism parser has adopted a style guide for error messages, which avoids using the mixed quotes, and uses backticks around token literals to render well in markdown. https://github.com/ruby/prism/blob/main/src/diagnostic.c ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-105959 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115993] [Ruby master Feature#16495] Inconsistent quotes in error messages
by ivoanjo (Ivo Anjo) 03 Jan '24

03 Jan '24

Issue #16495 has been updated by ivoanjo (Ivo Anjo). matz (Yukihiro Matsumoto) wrote in #note-7: > It was something cultural. I admit nowadays very few people use backquote as a left-hand quote, but it used to be. I also admit consistent quotes are easier for our eyes when using recent major fonts. But changing those quotes may affect existing log parsers. We have to estimate how big is the influence of the changes. > > Matz. On the topic of impacting the ecosystem, there have been quite a few changes to how exceptions have been displayed recently: * https://bugs.ruby-lang.org/issues/17930 * https://bugs.ruby-lang.org/issues/18564 and even more being discussed https://bugs.ruby-lang.org/issues/19117 . Overall the impact on the ecosystem seemed quite small, and the gain in usability was nice. So changing the `` ` `` to a `'` doesn't seem like it would be worse than any of those changes. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-105958 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115988] [Ruby master Bug#20110] Issue 193
by jay232857 (jay singh) 02 Jan '24

02 Jan '24

Issue #20110 has been reported by jay232857 (jay singh). ---------------------------------------- Bug #20110: Issue 193 https://bugs.ruby-lang.org/issues/20110 * Author: jay232857 (jay singh) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Tiger Shipping Containers has been Australia’s leading container company for over 30 years. We sell containers, hire containers, and modify containers, both new and 2nd hand, in 40ft, 20ft and 10ft sizes. With container delivery available (often within 24 hours) right across Australia. When you purchase a container from Tiger Shipping Containers, you do so safe in the knowledge that you’re buying from the largest container wholesaler in Australia. And as the country’s preeminent container wholesaler, we are in the very fortunate position of being able to get container stock into our various depots around the country in quantities that that nobody else can. And because we buy containers in bulk, it allows us to heavily discount our stock when we sell direct to the public. [[https://www.tigershippingcontainers.com.au/]] Tiger Shipping Containers has the container stock you need in stock right now. We have the (local) depots around the country to allow us to deliver your container quickly (often with 24 hours!). And as Australia’s largest container wholesaler we can discount our containers and sell them at a price that is impossible for our competition to match. So whether you’re buying a new or used container, or simply hiring a container for a set period of time, Tiger Shipping Containers is the only call you’ll ever have to make. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:115987] [Ruby master Bug#20109] Issue 101
by nina569 (nina cooper) 02 Jan '24

02 Jan '24

Issue #20109 has been reported by nina569 (nina cooper). ---------------------------------------- Bug #20109: Issue 101 https://bugs.ruby-lang.org/issues/20109 * Author: nina569 (nina cooper) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Manually keeping track of unique IDs is almost next to impossible but something like this example has the potential to categorize per functionality and testing stage and will expand and contract the list (to an extent.) On the lookout for a tiles shop in Sydney for your hotel [[reception]] project? Unsure about which tiles to use for your new house? Searching for the right tiles that would fit the color scheme of your bathroom renovation at home? https://tilearte.com.au/ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115980] [Ruby master Misc#17815] Snapcraft Ruby plugin
by paddor (Patrik Wenger) 30 Dec '23

30 Dec '23

Issue #17815 has been updated by paddor (Patrik Wenger). This can be closed. I've implemented a Ruby build plugin on v1 and v2. ---------------------------------------- Misc #17815: Snapcraft Ruby plugin https://bugs.ruby-lang.org/issues/17815#change-105943 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal ---------------------------------------- I'm working on a Ruby build plugin for the Snapcraft v2 plugin AP, since the v1 Ruby plugin does not work on the Ubuntu `core20` image. The v2 API only allows to influence the build step, which means there's no nice way for the plugin to set environment variables that apply during runtime. The problem is that the final paths to Ruby's stdlib are unknown during compile time. I've got it to work by renaming the `ruby` executable to `ruby.bare` and creating a wrapper script `ruby` that sets the `$RUBYLIB` and `$GEM_PATH` env variables based on `$SNAP` before `exec`ing `ruby.bare`. I don't like that it requires a wrapper script though, since it would have to awkwardly determine the arch-specific stdlib directory to support any platform. The current wrapper script is this: ```sh #!/bin/sh export RUBYLIB="$SNAP/lib/ruby/snap:$SNAP/lib/ruby/snap/x86_64-linux:$RUBYLIB" export GEM_PATH="$SNAP/lib/ruby/gems/snap:$GEM_PATH" exec `dirname $0`/ruby.bare "$@" ``` What possible solutions are there? I could maybe fix the shebangs of Ruby executables like `gem` and `bundle`, but not `ruby` itself since it's binary. Also, I'm not sure if env variable expansion even works in shebang. Can the configure script's `--with-search-path` be made to support env variable expansion during runtime? That still wouldn't solve the issue about the arch-specific directory. Python apparently determines its load paths relative to the executable being run. Does Ruby support anything like that? Any other ideas? Current state: https://github.com/paddor/snapcraft-ruby-plugin-v2 -- https://bugs.ruby-lang.org/

1 0