May 2023 - ruby-core - ml.ruby-lang.org

[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