Issue #19985 has been reported by vo.x (Vit Ondruch).
----------------------------------------
Feature #19985: Support `Pathname` for `require`
https://bugs.ruby-lang.org/issues/19985
* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
It seems that RubyGems / Bundler `require` method overrides of accept `Pathname` as and argument
~~~
$ ruby -rpathname -e '
pa = Pathname.new("test")
require pa
'
<internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- test (LoadError)
from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require'
from -e:3:in `<main>'
~~~
while plain Ruby require does not:
~~~
$ ruby --disable-gems -rpathname -e '
pa = Pathname.new("test")
require pa
'
-e:3:in `require': no implicit conversion of Pathname into String (TypeError)
from -e:3:in `<main>'
~~~
This inconsistency is surprising. It seems that RubyGems / Bundler developers think [1] that Ruby `require` should also accept `Pathname`.
~~~
$ ruby -v
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
~~~
[1]: https://github.com/rubygems/rubygems/pull/7128
--
https://bugs.ruby-lang.org/
Issue #14548 has been updated by knu (Akinori MUSHA).
Status changed from Rejected to Open
Assignee set to matz (Yukihiro Matsumoto)
Can we reconsider this? JavaScript already introduced this syntax a while ago and we are already getting pretty much used to it.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators…
```javascript
obj.val?.prop
obj.val?.[expr]
obj.func?.(args)
```
I know `ary&.[]` is ambiguous, but it's extremely rare to call `[]` with no arguments, so let's just keep the compatibility and allow it to swallow the following arguments if any.
----------------------------------------
Feature #14548: Allow some_array&.[1] to be a valid syntax
https://bugs.ruby-lang.org/issues/14548#change-105233
* Author: rosenfeld (Rodrigo Rosenfeld Rosas)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
Currently, Ruby allows accessing an array's index while testing whether the array is not nil with this syntax: `my_array&.[](1)`. I've always found this awkward but didn't mind about suggesting anything to improve this.
I was just reading about how JavaScript is probably going to support myArray?.[1] and found that it read good enough for me.
So I'd like to propose about the same syntax, replacing ?. with the Ruby equivalent &. instead. How does that look like to you?
--
https://bugs.ruby-lang.org/
Issue #14602 has been updated by mame (Yusuke Endoh).
As far as I understand, Matz expects that, for a tree structure:
* `dig_*` touches only nodes on a specific path,
* `deep_*` touches all nodes.
----------------------------------------
Feature #14602: Version of dig that raises error if a key is not present
https://bugs.ruby-lang.org/issues/14602#change-105226
* Author: amcaplan (Ariel Caplan)
* Status: Open
* Priority: Normal
----------------------------------------
Currently, if I have a hash like this:
~~~ ruby
{
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
~~~
and I want to navigate confidently and raise a KeyError if something is missing, I can do:
~~~ ruby
hash.fetch(:name).fetch(:first)
~~~
Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this:
~~~ ruby
hash[:name][:first]
~~~
which leads to many unexpected errors.
The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this:
~~~ ruby
hash = {
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
hash.dig!(:name, :first) # => Ariel
hash.dig!(:name, :middle) # raises KeyError (key not found: :middle)
hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method)
~~~
--
https://bugs.ruby-lang.org/
Issue #14602 has been updated by Eregon (Benoit Daloze).
mame (Yusuke Endoh) wrote in #note-30:
> * `deep` sounds to be an operation on the entire data structure, due to the influence of deep_copy.
It actually is a deep operation, on the entire data structure/multiple objects, exactly like deep_copy would.
So it seems a perfect match, no?
----------------------------------------
Feature #14602: Version of dig that raises error if a key is not present
https://bugs.ruby-lang.org/issues/14602#change-105225
* Author: amcaplan (Ariel Caplan)
* Status: Open
* Priority: Normal
----------------------------------------
Currently, if I have a hash like this:
~~~ ruby
{
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
~~~
and I want to navigate confidently and raise a KeyError if something is missing, I can do:
~~~ ruby
hash.fetch(:name).fetch(:first)
~~~
Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this:
~~~ ruby
hash[:name][:first]
~~~
which leads to many unexpected errors.
The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this:
~~~ ruby
hash = {
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
hash.dig!(:name, :first) # => Ariel
hash.dig!(:name, :middle) # raises KeyError (key not found: :middle)
hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method)
~~~
--
https://bugs.ruby-lang.org/
Issue #14602 has been updated by mame (Yusuke Endoh).
We discussed at the dev meeting but did not reach a conclusion. But there has been some progress.
* @akr said we shouldn't add new vocabulary, and Matz agreed.
* There is `Array#fetch` which throws an exception when it is not found, so we want to use this vocabulary: `fetch_*` or `*_fetch`
* Matz didn't like any of the proposed `fetch_each` `fetch_all` `fetch_tail` `fetch_end`
* Matz prefers `dig` or `recursive` to `deep` to represent this behavior.
* `deep` sounds to be an operation on the entire data structure, due to the influence of deep_copy.
* Matz was interested in how `dig_fetch` or `fetch_dig` would sound to English native speakers.
* Matz also mentioned `recursive_fetch`, but said it seemed a bit long.
----------------------------------------
Feature #14602: Version of dig that raises error if a key is not present
https://bugs.ruby-lang.org/issues/14602#change-105218
* Author: amcaplan (Ariel Caplan)
* Status: Open
* Priority: Normal
----------------------------------------
Currently, if I have a hash like this:
~~~ ruby
{
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
~~~
and I want to navigate confidently and raise a KeyError if something is missing, I can do:
~~~ ruby
hash.fetch(:name).fetch(:first)
~~~
Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this:
~~~ ruby
hash[:name][:first]
~~~
which leads to many unexpected errors.
The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this:
~~~ ruby
hash = {
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
hash.dig!(:name, :first) # => Ariel
hash.dig!(:name, :middle) # raises KeyError (key not found: :middle)
hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method)
~~~
--
https://bugs.ruby-lang.org/
Issue #18915 has been updated by mame (Yusuke Endoh).
Discussed at the dev meeting. This is tentative, but @matz said:
* I don't want to change the documentation of `NotImplementedError`.
* `NotImplementedYetError` is too confusing with `NotImplementedError`.
* `ToBeDefinedError` or something would be better.
* I will reply to the ticket.
Please wait for matz's answer.
----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105215
* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract
Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception
# Background
`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)
However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:
* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd…
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-…
# Proposal
Create `NotImplementedYetError` exception
OR
Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities
# Evaluation
### Add `NotImplementedYetError`
I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.
### Change scope of `NotImplementedError`
This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.
---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)
--
https://bugs.ruby-lang.org/
Issue #18286 has been updated by ccaviness (Clay Caviness).
@nobu Yes, at least in initial tests. A universal ruby built on an x86 Mac with that patch seems to work on an Apple Silicon Mac.
----------------------------------------
Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
https://bugs.ruby-lang.org/issues/18286#change-105214
* Author: ccaviness (Clay Caviness)
* Status: Open
* Priority: Normal
* ruby -v: 3.0.2
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine.
To reproduce:
* On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)`
* Copy the built `./ruby` binary to an Apple Silicon machine
* Attempt to execute it
Expected:
The universal `ruby` binary works correctly on both devices
Actual:
The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`).
Details:
I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines.
It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]`
This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines.
Intel:
```
$ ./ruby -v
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21]
```
Apple Silicon:
```
$ ./ruby -v
Segmentation fault: 11
$ lldb ./ruby
(lldb) target create "./ruby"
Current executable set to '/Users/crc/ruby' (arm64).
(lldb) run
Process 77071 launched: '/Users/crc/ruby' (arm64)
Process 77071 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16
ruby`ruby_vm_special_exception_copy:
-> 0x1002176b8 <+16>: ldr x0, [x0, #0x8]
0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real
0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc
0x1002176c4 <+28>: mov x20, x0
Target 0: (ruby) stopped.
(lldb) ^D
```
I also attempted the same thing with ruby 2.7.4 source, with the same result.
--
https://bugs.ruby-lang.org/
Issue #19989 has been reported by bkuhlmann (Brooke Kuhlmann).
----------------------------------------
Bug #19989: Fix refinement refine performance
https://bugs.ruby-lang.org/issues/19989
* Author: bkuhlmann (Brooke Kuhlmann)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [arm64-darwin22.4.0]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
## Why
Hello. 👋 Would it be possible to improve the performance of refining an object as I'm seeing a significant performance cost? I know some of this is already known but, when searching through existing issues, I couldn't find any issue that specifically mentioned or called attention to `refine` performance.
My C skills are not that great but it seems that `rb_mod_refine` ([source](https://github.com/ruby/ruby/blob/master/eval.c#L1412-L1459)) might be the primary source of complexity and performance degradation?
By fixing this, we could improve refinement performance and encourage more adoption since refinements are a powerful way to make small adjustments to the language without resorting to more complicated solutions -- or worse -- using monkey patches.
## How
Here's the benchmark I'm using:
```
#! /usr/bin/env ruby
# frozen_string_literal: true
require "bundler/inline"
gemfile true do
source "https://rubygems.org"
gem "benchmark-ips"
end
Benchmark.ips do |benchmark|
benchmark.config time: 5, warmup: 2
benchmark.report "With" do
Module.new do
refine String do
def dud = true
end
end
end
benchmark.report "Without" do
Module.new do
def dud = true
end
end
benchmark.compare!
end
```
When running the above, I'm getting the following results (this is a random sample):
**Ruby 2.6.6** (ruby 2.6.6p146 (2020-03-31 revision 67876) [-darwin22])
*ℹ️ Temporarily refactored the benchmark to not use endless methods for this version.*
```
Warming up --------------------------------------
With 745.000 i/100ms
Without 67.593k i/100ms
Calculating -------------------------------------
With 10.849k (±168.6%) i/s - 18.625k in 5.359230s
Without 680.199k (± 5.8%) i/s - 3.447M in 5.085558s
Comparison:
Without: 680198.8 i/s
With: 10849.1 i/s - 62.70x slower
```
**Ruby 3.2.2** (ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [arm64-darwin22.4.0])
```
Warming up --------------------------------------
With 959.000 i/100ms
Without 297.091k i/100ms
Calculating -------------------------------------
With 21.856k (±198.5%) i/s - 30.688k in 5.509103s
Without 3.281M (± 5.8%) i/s - 16.637M in 5.082246s
Comparison:
Without: 3281310.6 i/s
With: 21856.1 i/s - 150.13x slower
```
**Ruby 3.3.3 Preview 2** (ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) +YJIT [arm64-darwin22.6.0])
```
Warming up --------------------------------------
With 1.044k i/100ms
Without 288.264k i/100ms
Calculating -------------------------------------
With 24.044k (±192.0%) i/s - 29.232k in 5.305651s
Without 3.096M (± 8.0%) i/s - 15.566M in 5.059470s
Comparison:
Without: 3095640.6 i/s
With: 24043.8 i/s - 128.75x slower
```
## Notes
Here's the environment I'm using:
- **macOS**: 13.6.1, Apple M1
--
https://bugs.ruby-lang.org/
Issue #14602 has been updated by Eregon (Benoit Daloze).
I like `deep_fetch` too.
----------------------------------------
Feature #14602: Version of dig that raises error if a key is not present
https://bugs.ruby-lang.org/issues/14602#change-105209
* Author: amcaplan (Ariel Caplan)
* Status: Open
* Priority: Normal
----------------------------------------
Currently, if I have a hash like this:
~~~ ruby
{
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
~~~
and I want to navigate confidently and raise a KeyError if something is missing, I can do:
~~~ ruby
hash.fetch(:name).fetch(:first)
~~~
Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this:
~~~ ruby
hash[:name][:first]
~~~
which leads to many unexpected errors.
The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this:
~~~ ruby
hash = {
:name => {
:first => "Ariel",
:last => "Caplan"
}
}
hash.dig!(:name, :first) # => Ariel
hash.dig!(:name, :middle) # raises KeyError (key not found: :middle)
hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method)
~~~
--
https://bugs.ruby-lang.org/