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

[ruby-core:113419] You have [13] pending incoming emails
by mail.ml.ruby-lang.org 08 May '23

08 May '23

1 0

[ruby-core:113221] [Ruby master Misc#19597] Process.argv0 returns the same mutable String
by andrykonchin (Andrew Konchin) 08 May '23

08 May '23

Issue #19597 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #19597: Process.argv0 returns the same mutable String https://bugs.ruby-lang.org/issues/19597 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal ---------------------------------------- `Process.argv0` returns a name of the script being executed. But it seems it's always the same object, that can be modified and this change will be visible to the consequent `Process.argv0` calls. It makes sense to return a frozen String that cannot be modified. `$0` initial value equals a value returned by `Process.argv0` so `$0` by default also could be a frozen String. Example: ```ruby puts "Object id:" p Process.argv0.object_id p Process.argv0.object_id puts "Value before modification:" p Process.argv0 Process.argv0.upcase! puts "Value after modification:" p Process.argv0 ``` It will output: ``` Object id: 60 60 Value before modification: "argv0.rb" Value after modification: "ARGV0.RB" ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:113404] [Ruby master Bug#19629] Fix for CVE-2023-28755 breaks "puppet apply" run
by ManuelKiessling 06 May '23

06 May '23

Issue #19629 has been reported by ManuelKiessling (Manuel Kießling). ---------------------------------------- Bug #19629: Fix for CVE-2023-28755 breaks "puppet apply" run https://bugs.ruby-lang.org/issues/19629 * Author: ManuelKiessling (Manuel Kießling) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- (Not neccessarily a bug in Ruby - chances are I should have formatted my Puppet file URIs differently from the get-go.) However, since yesterday I'm getting these errors when running `puppet apply`: Could not evaluate: Could not retrieve file metadata for puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades: Failed to open TCP connection to :8140 (Connection refused - connect(2) for "" port 8140) I think the reason this happens now in an otherwise completely unchanged environment is that on my Ubuntu system, a new ruby2.7 package has been installed, due to CVE-2023-28755. See http://changelogs.ubuntu.com/changelogs/pool/main/r/ruby2.7/ruby2.7_2.7.0-5… for the backport info. The patch info (URI.parse should set empty string in host instead of nil in lib/uri/rfc3986_parser.rb, raise ArgumentError with empty host url again in lib/net/http/generic_request.rb.) sounds exactly like the reason I'm suddenly running into this error: `puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades` is an URI with an empty hostname - or is it? It's actually meant to refer to a local file, not a file on remote host ""; however, this is how it now seems to be interpreted: protocol `puppet`, hostname ``, path `/modules/unattended_upgrades...`. Because the patched code now returns `""` for the hostname instead of `nil`, it tries to do a hostname lookup for `""` which of course fails. Not sure if this is an intended consequence of the patch in this specific context, which is why I'm reporting it. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113308] [Ruby master Bug#19611] Ruby hangs up with `while true && true`
by tompng (tomoya ishida) 06 May '23

06 May '23

Issue #19611 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19611: Ruby hangs up with `while true && true` https://bugs.ruby-lang.org/issues/19611 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [x86_64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Fails to run this code. It hangs up. Ctrl+C does not work. ~~~ruby def hoge while true && true end end ~~~ Compiling `while true && true; end` will also hangs up ~~~ruby irb(main):001:0> RubyVM::InstructionSequence.compile 'while true && true; end'; puts :done (no response) ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:113403] [Ruby master Feature#19015] Language extension by a heredoc
by pyromaniac (Arkadiy Zabazhanov) 04 May '23

04 May '23

Issue #19015 has been updated by pyromaniac (Arkadiy Zabazhanov). @duerst It is funny you asked cause I just found this > [Kernel] Support for multi-letter uppercase sigils here https://hexdocs.pm/elixir/main/changelog.html We can definitely start doing this right from the beginning. Also, from my experience, even 1-letter sigils are not causing any issues but simplifying code reading/writing a lot. ---------------------------------------- Feature #19015: Language extension by a heredoc https://bugs.ruby-lang.org/issues/19015#change-102974 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- This propose new heredoc extension with `<<!LANG` like ```ruby doc = <<!LANG # description written in lang LANG foo bar LANG ``` and it is translated to: ```ruby doc = heredoc_extension_LANG(heredoc_text, binding) ``` ## Example ```ruby require 'erb' def heredoc_extension_erb str, b ERB.new(str).run(b) end name = 'ko1' html = <<!erb <div>Hello <%= name %></div> erb puts html #=> <div>Hello ko1</div> ``` ## Background / considerations * Sometimes we write Ruby syntax string with `<<RUBY` and this proposal inspired by it. * it is similar to shebang (`#!LANG` in shell) * [Elixir's custom sigil](https://elixir-lang.org/getting-started/sigils.html) translates `~u(...)` translates to `sigil_u(...)`. This is why it translated to `heredoc_extension_LANG(...)` private method call. * JavaScript has JSX but I don't think it is fit to the Ruby language. * Heredoc is Ruby's chaos part and already confusing a lot. Additional chaos doesn't matter. * `<<!foo` is valid syntax but now I don't think it is not used. gem codesearch doesn't find the usage. * Sorry I couldn't wait 1st/Apr. ## Implementation I attached the experimental implementation which only supports `erb` (because I couldn't find how to get delimiter to determine a method name :p). ---Files-------------------------------- heredoc_extension.patch (2.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113402] [Ruby master Feature#19015] Language extension by a heredoc
by duerst 04 May '23

04 May '23

Issue #19015 has been updated by duerst (Martin Dürst). @pyromaniac I think the main problem would be how to handle namespacing. With single letters, the chance of collision is very high. How does Elixir handle this? ---------------------------------------- Feature #19015: Language extension by a heredoc https://bugs.ruby-lang.org/issues/19015#change-102973 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- This propose new heredoc extension with `<<!LANG` like ```ruby doc = <<!LANG # description written in lang LANG foo bar LANG ``` and it is translated to: ```ruby doc = heredoc_extension_LANG(heredoc_text, binding) ``` ## Example ```ruby require 'erb' def heredoc_extension_erb str, b ERB.new(str).run(b) end name = 'ko1' html = <<!erb <div>Hello <%= name %></div> erb puts html #=> <div>Hello ko1</div> ``` ## Background / considerations * Sometimes we write Ruby syntax string with `<<RUBY` and this proposal inspired by it. * it is similar to shebang (`#!LANG` in shell) * [Elixir's custom sigil](https://elixir-lang.org/getting-started/sigils.html) translates `~u(...)` translates to `sigil_u(...)`. This is why it translated to `heredoc_extension_LANG(...)` private method call. * JavaScript has JSX but I don't think it is fit to the Ruby language. * Heredoc is Ruby's chaos part and already confusing a lot. Additional chaos doesn't matter. * `<<!foo` is valid syntax but now I don't think it is not used. gem codesearch doesn't find the usage. * Sorry I couldn't wait 1st/Apr. ## Implementation I attached the experimental implementation which only supports `erb` (because I couldn't find how to get delimiter to determine a method name :p). ---Files-------------------------------- heredoc_extension.patch (2.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113401] [Ruby master Feature#19015] Language extension by a heredoc
by pyromaniac (Arkadiy Zabazhanov) 04 May '23

04 May '23

Issue #19015 has been updated by pyromaniac (Arkadiy Zabazhanov). Hey folks. I'm actually wondering, why don't support Elixir-like sigils in Ruby? We have a ton of them already: `%w[]`, `%r//`, so why don't just add a support for custom ones? I'm, for once, time of writing `Date.new` or `Time.parse`, I'd like to have it `%D[2023-05-05]` or Money gem can introduce something like `%M[100 USD]` instead of the long `Money.from_amount(100, "USD")` version. ---------------------------------------- Feature #19015: Language extension by a heredoc https://bugs.ruby-lang.org/issues/19015#change-102972 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- This propose new heredoc extension with `<<!LANG` like ```ruby doc = <<!LANG # description written in lang LANG foo bar LANG ``` and it is translated to: ```ruby doc = heredoc_extension_LANG(heredoc_text, binding) ``` ## Example ```ruby require 'erb' def heredoc_extension_erb str, b ERB.new(str).run(b) end name = 'ko1' html = <<!erb <div>Hello <%= name %></div> erb puts html #=> <div>Hello ko1</div> ``` ## Background / considerations * Sometimes we write Ruby syntax string with `<<RUBY` and this proposal inspired by it. * it is similar to shebang (`#!LANG` in shell) * [Elixir's custom sigil](https://elixir-lang.org/getting-started/sigils.html) translates `~u(...)` translates to `sigil_u(...)`. This is why it translated to `heredoc_extension_LANG(...)` private method call. * JavaScript has JSX but I don't think it is fit to the Ruby language. * Heredoc is Ruby's chaos part and already confusing a lot. Additional chaos doesn't matter. * `<<!foo` is valid syntax but now I don't think it is not used. gem codesearch doesn't find the usage. * Sorry I couldn't wait 1st/Apr. ## Implementation I attached the experimental implementation which only supports `erb` (because I couldn't find how to get delimiter to determine a method name :p). ---Files-------------------------------- heredoc_extension.patch (2.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113386] [Ruby master Feature#19627] Add a way to detect if the Ruby VM is running in C API
by ianks (Ian Ker-Seymer) 03 May '23

03 May '23

Issue #19627 has been reported by ianks (Ian Ker-Seymer). ---------------------------------------- Feature #19627: Add a way to detect if the Ruby VM is running in C API https://bugs.ruby-lang.org/issues/19627 * Author: ianks (Ian Ker-Seymer) * Status: Open * Priority: Normal ---------------------------------------- Currently, there is no supported way to check if the Ruby VM has been shut down. There are a couple of workarounds that I know of: 1. Setup an exit handler which sets a global variable (like I did in https://github.com/tmm1/stackprof/pull/200) 2. In Ruby 2.4 thru 3.2, you could check the hidden `ruby_vm_global_ptr != NULL`. For my use, in rb-sys there is a feature to automatically report Rust memory allocations via `rb_gc_adjust_memory_usage`. However, there is a bug that can cause processes to deadlock and/or segfault if a Rust destructor gets called after the VM quits (which can happen in Rust background threads). Currently, I don’t think there’s a way to safely make this feature work. (https://github.com/oxidize-rb/rb-sys/pull/205) It would be nice to have an official way to know if the Ruby VM is available, basically just a `ruby_current_vm_ptr != null`. Thoughts? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113396] [Ruby master Feature#19628] Add ARGF.each_file for iterating file/io objects
by davishmcclurg (David Harsha) 03 May '23

03 May '23

Issue #19628 has been reported by davishmcclurg (David Harsha). ---------------------------------------- Feature #19628: Add ARGF.each_file for iterating file/io objects https://bugs.ruby-lang.org/issues/19628 * Author: davishmcclurg (David Harsha) * Status: Open * Priority: Normal ---------------------------------------- `ARGF` provides helpers for processing file/stdin command line arguments in various ways (bytes, chars, codepoints, etc), but it doesn't currently have a simple way to iterate through the arguments as `File`/`IO` objects. This can be useful when you want to perform an operation on the contents of an entire file (eg, JSON parsing) instead of combining them into a single string or going line-by-line. My proposal is to add an `ARGF.each_file` method that yields each file (or returns an enumerator if no block is provided). Possible implementation: https://github.com/davishmcclurg/ruby/commit/cc8054c2737243f839d72622977a44… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113383] [Ruby master Feature#19626] Alias Base64 methods to non-64 suffixed methods
by ryanbigg (Ryan Bigg) 02 May '23

02 May '23

Issue #19626 has been reported by ryanbigg (Ryan Bigg). ---------------------------------------- Feature #19626: Alias Base64 methods to non-64 suffixed methods https://bugs.ruby-lang.org/issues/19626 * Author: ryanbigg (Ryan Bigg) * Status: Open * Priority: Normal ---------------------------------------- Long time Ruby user, first time issue poster. Apologies if this isn't the correct process of proposing this sort of change. Redirect me somewhere else if I need to be. I'd like to propose aliasing the methods in the Base64 module to new methods: Base64.encode64 -> Base64.encode Base64.decode64 -> Base64.decode etc. I am guessing that this suffix was used to prevent issues where `Base64` was included into a class and would (potentially) clash with that class's own `decode` and `encode` methods. This is not how `Base64` has been used in my experience -- it's typically a call to the method such as `Base64.encode64`. But maybe my experience of Ruby is unique in that way. I would still like to open this issue at least to start a potential discussion about these potential aliases, or at least documenting solid reasons why the 64 suffix has to stick. -- https://bugs.ruby-lang.org/

3 2