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

[ruby-core:113410] [Ruby master Bug#19631] module_eval does not propulate absolute_path for Kernel.caller_locations

by daveola (David Stellar)

Issue #19631 has been reported by daveola (David Stellar). ---------------------------------------- Bug #19631: module_eval does not propulate absolute_path for Kernel.caller_locations https://bugs.ruby-lang.org/issues/19631 * Author: daveola (David Stellar) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I am using module_eval and noticing that since ruby 3.2 the Kernel locations do not have absolute_path for any of the eval code, though the path is available. This is a regression since at least ruby 3.0 which still works. I am on 3.2.2, and here is some sample code: ---- class Script < Module script = %q{ def self.locations Kernel.caller_locations.each { |loc| puts "LOCATION: #{loc}" puts "ABSPATH: #{loc.absolute_path}" puts "PATH: #{loc.path}" } end self.locations } module_eval(script, "/this/is/my/path", 0) end ------ The output for the code at the top of the caller locations (inside the module_eval) is: LOCATION: /this/is/my/path:9:in `<class:Script>' ABSPATH: PATH: /this/is/my/path But the absolute_path should have the correct path data as well -- https://bugs.ruby-lang.org/

1 year

1
0
0 0

[ruby-core:113403] [Ruby master Feature#19015] Language extension by a heredoc

by pyromaniac (Arkadiy Zabazhanov)

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 year

1
0
0 0

[ruby-core:113402] [Ruby master Feature#19015] Language extension by a heredoc

by duerst

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 year

1
0
0 0

[ruby-core:113401] [Ruby master Feature#19015] Language extension by a heredoc

by pyromaniac (Arkadiy Zabazhanov)

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 year

1
0
0 0

[ruby-core:113352] [Ruby master Bug#19619] Endless method definition with parameters for an instance given as numbered parameters doesn't work

by okuramasafumi (Masafumi OKURA)

Issue #19619 has been reported by okuramasafumi (Masafumi OKURA). ---------------------------------------- Bug #19619: Endless method definition with parameters for an instance given as numbered parameters doesn't work https://bugs.ruby-lang.org/issues/19619 * Author: okuramasafumi (Masafumi OKURA) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This works: ```ruby class Foo def bar(baz) = 'foo' end p Foo.new.bar('baz') ``` This also works: ```ruby o = Object.new o.tap { |obj| def obj.bar(baz) = 'foo' } p o.bar('baz') ``` Even this works: ```ruby o = Object.new o.tap { def _1.bar = 'foo' } p o.bar ``` But this DOESN'T work: ```ruby o = Object.new o.tap { def _1.bar(baz) = 'foo' } p o.bar('baz') ``` So, when we define a method with parameters on an instance given as numbered parameters, it doesn't work. If we change one condition (definition way, parameter existence, and so on), it works. -- https://bugs.ruby-lang.org/

1 year

3
3
0 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)

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/

1 year

2
3
0 0

[ruby-core:113396] [Ruby master Feature#19628] Add ARGF.each_file for iterating file/io objects

by davishmcclurg (David Harsha)

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 year

1
0
0 0

[ruby-core:113383] [Ruby master Feature#19626] Alias Base64 methods to non-64 suffixed methods

by ryanbigg (Ryan Bigg)

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/

1 year

3
2
0 0

2024

2023

2022

ruby-core May 2023