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

[ruby-core:112304] [Ruby master Bug#19427] Marshal.load(source, freeze: true) doesn't freeze in some cases
by andrykonchin (Andrew Konchin) 16 May '24

16 May '24

Issue #19427 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19427: Marshal.load(source, freeze: true) doesn't freeze in some cases https://bugs.ruby-lang.org/issues/19427 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I've noticed that the `freeze` option doesn't work in the following cases: - when dumped object extends a module - when dumped object responds to `#marshal_dump` and `#marshal_load` methods - when dumped object responds to `#_dump` method Is it expected behaviour or a known issue? Examples: ```ruby module M end object = Object.new object.extend(M) object = Marshal.load(Marshal.dump(object), freeze: true) object.frozen? # => false ``` ```ruby class UserMarshal attr_accessor :data def initialize @data = 'stuff' end def marshal_dump() :data end def marshal_load(data) @data = data end end object = Marshal.load(Marshal.dump(UserMarshal.new), freeze: true) object.frozen? # => false ``` ```ruby class UserDefined attr_reader :a, :b def initialize @a = 'stuff' @b = @a end def _dump(depth) Marshal.dump [:stuff, :stuff] end def self._load(data) a, b = Marshal.load data obj = allocate obj.instance_variable_set :@a, a obj.instance_variable_set :@b, b obj end end ``` -- https://bugs.ruby-lang.org/

5 13

[ruby-core:117885] [Ruby master Misc#20491] Proposal for new branch maintainers
by hsbt (Hiroshi SHIBATA) 16 May '24

16 May '24

Issue #20491 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #20491: Proposal for new branch maintainers https://bugs.ruby-lang.org/issues/20491 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- In RubyKaigi 2024, I, naruse and nagachika discussed about maintaining stable branches. We propose the following members for the new branch maintainer of current stable branches. * `ruby_3_3`: @k0kubun * `ruby_3_2`: @nagachika * `ruby_3_1`: @hsbt (me) We consider to how resolve #20432 's request at the next time. And `ruby_3_1` still have some critical build issues like #20151 , #20451 and others. I consider to release to fix that soon without security fixes. @matz Can you approve an above plan? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:112873] [Ruby master Bug#19530] `Array#sum` and `Enumerable#sum` sometimes show different behaviours
by dstosik (David Stosik) 16 May '24

16 May '24

Issue #19530 has been reported by dstosik (David Stosik). ---------------------------------------- Bug #19530: `Array#sum` and `Enumerable#sum` sometimes show different behaviours https://bugs.ruby-lang.org/issues/19530 * Author: dstosik (David Stosik) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi everyone. 👋🏻 We recently discovered that `Array#sum` and `Enumerable#sum` will output different results in some edge cases. Here's the smallest script I managed to write to reproduce the issue: ``` ruby class Money def initialize(amount) @amount = amount.to_f end def +(other) self.class.new(@amount + other.to_f) end def to_f @amount end end p [7.0].each.sum(Money.new(0)).class #=> Money p [7.0] .sum(Money.new(0)).class #=> Float 💥 ``` I understand that it is expected that `#sum` may not honor custom definitions of the `#+` method (particularly when the summed values are `Float`). However, I would like to bring your attention to the fact that, in the example above, calling `#sum` on an `Array` of `Float` values and calling `#sum` on an `Enumerable` that yields the same `Float` values will return results of different types. I've reproduced the same behaviour with multiple versions of Ruby going from 2.6.5 to 3.2.1. Ideally, I would expect `[7.0].sum(Money.new(0))` to return a `Money` object identical to the one returned by `[7.0].each.sum(Money.new(0))`. I think it would make sense if at least they returned an identical value (even if it is a `Float`). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:117888] [Ruby master Feature#16461] Proc#using
by shugo (Shugo Maeda) 16 May '24

16 May '24

Issue #16461 has been updated by shugo (Shugo Maeda). Sorry for the delay. Eregon (Benoit Daloze) wrote in #note-10: > Reading #12086 again, I feel #12281 is a much simpler alternative (`using(refinement) { literal block }`). > Wouldn't #12281 be enough? > > `block.using(IntegerDivExt)` is mutating state and this feels too magic and dangerous to me. > I think DSL users can accept to wrap their DSL code with `using(refinement) { ... }` (or `using refinement` in a module/file). > That's actually not more verbose than `using Proc::Refinements` and I think so much clearer. It looks too redundant to me because `using` is needed for each block. > We could have additional requirements to ensure it's truly lexical and the `refinement` given to a given `using(refinement) { ... }` call site is always the same. > I think that would be good, because then we know code inside always use the given refinements, much like how `using refinement` works today. > > For the `User.where { :age > 3 }` case, if we want to avoid an extra `using(refinement) { ... }`, I think it could be fine to automatically enable refinements in that block *if* we can ensure it's still fully lexical. > Concretely that would mean for that block `{ :age > 3 }` it's always called with the same refinements, no matter where it's called from. > Attempting to use any other refinement would raise an error. > > Maybe a way to design this restriction could be to annotate the method `where` with "enables MyRefinement on the lexical block given to it". > ```ruby > class ModelClassMethods > def where(&block) > ... > block.call / yield > end > instance_method(:where).use_refinements_for_block(ActiveRecord::WhereDSL) > end > > User.where { :age > 3 } > ``` I like the idea, but if `where` is polymorphic, the block can be called with different refinements, can't it? ```ruby def age_over_three(model_class) model_class.where { :age > 3 } end ``` Do you mean to save the refinements when the block is called at the first time, and to raise an exception when the block is called with different refinements? If so, it's similar to what I meant to realize by Proc.using. ---------------------------------------- Feature #16461: Proc#using https://bugs.ruby-lang.org/issues/16461#change-108304 * Author: shugo (Shugo Maeda) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- ## Overview I propose Proc#using to support block-level refinements. ```ruby module IntegerDivExt refine Integer do def /(other) quo(other) end end end def instance_eval_with_integer_div_ext(obj, &block) block.using(IntegerDivExt) # using IntegerDivExt in the block represented by the Proc object obj.instance_eval(&block) end # necessary where blocks are defined (not where Proc#using is called) using Proc::Refinements p 1 / 2 #=> 0 instance_eval_with_integer_div_ext(1) do p self / 2 #=> (1/2) end p 1 / 2 #=> 0 ``` ## PoC implementation For CRuby: https://github.com/shugo/ruby/pull/2 For JRuby: https://github.com/shugo/jruby/pull/1 ## Background I proposed [Feature #12086: using: option for instance_eval etc.](https://bugs.ruby-lang.org/issues/12086) before, but it has problems: * Thread safety: The same block can be invoked with different refinements in multiple threads, so it's hard to implement method caching. * _exec family support: {instance,class,module}_exec cannot be supported. * Implicit use of refinements: every blocks can be used with refinements, so there was implementation difficulty in JRuby and it has usability issue in headius's opinion. ## Solutions in this proposal ### Thread safety Proc#using affects the block represented by the Proc object, neither the specific Proc object nor the specific block invocation. Method calls in a block are resolved with refinements which are used by Proc#using in the block at the time. Once all possible refinements are used in the block, there is no need to invalidate method cache anymore. See [these tests](https://github.com/shugo/ruby/pull/2/commits/1c922614ad7d1fb43b73e19… to understand how it works. Which refinements are used is depending on the order of Proc#using invocations until all Proc#using calls are finished, but eventually method calls in a block are resolved with the same refinements. ### * _exec family support [Feature #12086](https://bugs.ruby-lang.org/issues/12086) was an extension of _eval family, so it cannot be used with _exec family, but Proc#using is independent from _eval family, and can be used with _exec family: ```ruby def instance_exec_with_integer_div_ext(obj, *args, &block) block.using(IntegerDivExt) obj.instance_exec(*args, &block) end using Proc::Refinements p 1 / 2 #=> 0 instance_exec_with_integer_div_ext(1, 2) do |other| p self / other #=> (1/2) end p 1 / 2 #=> 0 ``` ### Implicit use of refinements Proc#using can be used only if `using Proc::Refinements` is called in the scope of the block represented by the Proc object. Otherwise, a RuntimeError is raised. There are two reasons: * JRuby creates a special CallSite for refinements at compile-time only when `using` is called at the scope. * When reading programs, it may help understanding behavior. IMHO, it may be unnecessary if libraries which uses Proc#using are well documented. `Proc::Refinements` is a dummy module, and has no actual refinements. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114403] [Ruby master Feature#19840] [Proposal] Expand Find pattern to Multiple Find
by FlickGradley (Nick Bradley) 16 May '24

16 May '24

Issue #19840 has been reported by FlickGradley (Nick Bradley). ---------------------------------------- Feature #19840: [Proposal] Expand Find pattern to Multiple Find https://bugs.ruby-lang.org/issues/19840 * Author: FlickGradley (Nick Bradley) * Status: Open * Priority: Normal ---------------------------------------- Hello! I love Ruby's pattern matching features. I would like to propose an expansion of the Find pattern which allows the selection of multiple matching elements of an array. I often find myself dealing with data like this: ``` ruby { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }, ... ] } ``` My problem is that I need to retrieve all the `id` values from the nested array of hashes, and I don't know how many there will be in advance. It seems that the Find pattern could be expanded from allowing `pattern` (matching a single element) to `*pattern`. Examples: ``` ruby # Base case case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }] "matched: #{ids}" else "not matched" end #=> matched: [1, 2] # With * at the end (rest of args) - same result case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }, *] "matched: #{ids}" else "not matched" end #=> matched: [1, 2] # When one element doesn't match and there is no *rest case { results: [{ name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }] "matched: #{ids}" else "not matched" end #=> not matched ``` Similarly, `*Constant` could work to pull out types with an As pattern: ``` ruby case [1, 2, 3, "string"] in *Integer => nums, * "matched: #{nums}" else "not matched" end #=> matched: [1, 2, 3] ``` Other patterns would work in the same way. Essentially, this expands the concept of `*` in pattern matching to mean "a variable number of `things matching subpattern`". Today, the only pattern supported by `*` is a variable binding - but it could be any of the other subpatterns as well. This proposal does imply that this would work: ``` ruby a = 2 [1, 2, 2, 3] in [*, *^a, *] #=> true ``` To me, the `*` represents the variable number of matches, so the syntax makes intuitive sense. But others may have different opinions about `*^` being adjacent. It may also imply this would work, though we could restrict the number of non-variable patterns (in other words, patterns that have the possibility of not matching) to 1 per Array so that this isn't possible.. I'm not sure something like this would be useful or clear. ``` ruby a = 2 [1, 2, "hello", "ruby"] in [*Integer, *String] #=> true ``` This feature feels like the missing piece of the Find pattern to me - I often want to "Find Multiple". If others agree, I would be happy to contribute by working on this feature and creating a pull request. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117497] [Ruby master Bug#20424] ZLib::GZipReader always double allocates strings when passed outbuf, significantly increasing memory usage
by martinemde (Martin Emde) 14 May '24

14 May '24

Issue #20424 has been reported by martinemde (Martin Emde). ---------------------------------------- Bug #20424: ZLib::GZipReader always double allocates strings when passed outbuf, significantly increasing memory usage https://bugs.ruby-lang.org/issues/20424 * Author: martinemde (Martin Emde) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In trying to improve the memory performance during the install of rubygems, we previously found a bug in `eof?`. Further investigation into the memory usage during the fix for this bug found wasteful allocating of strings in readpartial and read. In ZLib, when reading with readpartial or read, a new string is always created for the bytes read from the buffer. The current approach allocates a string no matter if there is an outbuf passed. ``` # vastly simplified psuedo implementation def readpartial(len, dst=nil) if (buffer.empty?) buffer = gzipfile.readpartial(len, dst) # adds inflated bytes into dst if passed end dst = allocate_new_string(len) # make a new string for the destination dst << buffer.read(len) # read from the buffer into the destination end ``` The result is that readpartial always allocated at least double the bytes necessary. Samuel Giddins submitted, and I have tested and reviewed, [a pull request, zlib#61](https://github.com/ruby/zlib/pull/61) that resolves the issue and vastly improves the memory usage and increases the speed of GZipReader by avoiding excess memcpy and rb_str_new calls that were wasted. This PR also adds an outbuf to GZipReader#read for improvement memory management, very similar to [IO#read](https://ruby-doc.org/core-2.5.1/IO.html#method-i-read) We appreciate your attention to this performance improvement. We believe it will further improve the performance of rubygems gem installs. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117880] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Dan0042 (Daniel DeLorme) 14 May '24

14 May '24

Issue #6648 has been updated by Dan0042 (Daniel DeLorme). nobu (Nobuyoshi Nakada) wrote in #note-15: > `RbConfig` is for build time informations, and does not look a right place for runtime informations. Isn't it ok to relax the semantics a little bit? RbConfig seems to me the most logical place for "ruby configuration", both run time and build time. But this does bring the excellent point that `RbConfig.ruby` is not necessarily the location of the ruby interpreter as I previously thought: ``` $ ruby -e 'p RbConfig.ruby' "/opt/ruby/3.2/bin/ruby" $ cp /opt/ruby/3.2/bin/ruby rubyyyy $ ./rubyyyy -e 'p RbConfig.ruby' "/opt/ruby/3.2/bin/ruby" ``` So it's not quite suitable for re-executing. So we could either * change `RbConfig.ruby` to be the current ruby interpreter (because TBH I'm not sure what's the use of this current `RbConfig.ruby`) * add a new method like `RbConfig.ruby_executable` * use a different namespace like `Process.ruby` and `Process.ruby_args` --- headius (Charles Nutter) wrote in #note-16: > if there are quoted arguments on the command line they might have to be re-quoted by the user if they are passed through another shell to launch. Wouldn't you normally use Shellwords for this? The original quoting is not available to ruby anyway. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108292 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117879] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by Edwing123 (Edwin Garcia) 14 May '24

14 May '24

Issue #15554 has been updated by Edwing123 (Edwin Garcia). `--warn-unused-block`/`:warn_unused_block`? ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-108291 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117494] [Ruby master Bug#20421] String#index and String#byteindex don't clear `$~` when offset > size (or bytesize)
by andrykonchin (Andrew Konchin) 14 May '24

14 May '24

Issue #20421 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20421: String#index and String#byteindex don't clear `$~` when offset > size (or bytesize) https://bugs.ruby-lang.org/issues/20421 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When String#index and String#byteindex are called with Regexp and offset they clear `$~` (that contains result of the last Regexp matching) when offset < -size. But they don't clear `$~` when offset > size what seems not consistent: ```ruby "a".index(/a/) p $~ # => #<MatchData "a"> string = "blablabla" string.index(/bla/, string.length + 1) p $~ # => #<MatchData "a"> ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:117875] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by headius (Charles Nutter) 14 May '24

14 May '24

Issue #6648 has been updated by headius (Charles Nutter). Note that for this to be most effective it would be the arguments unprocessed as they appear on the command line, but that may not be possible to do if the shell removes quoting. I don't think that should be a reason not to implement this issue, but if there are quoted arguments on the command line they might have to be re-quoted by the user if they are passed through another shell to launch. They should work fine if passed as direct arguments to `spawn`. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108287 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0