himura467 (Akito Shitara) wrote: > This relies on undocumented GC behavior, incurs ivar table allocation overhead, and leaves lifetime management entirely to the caller. What do you mean by "undocumented GC behavior"? Isn't it only ...Eregon (Benoit Daloze)
The only way to iterate an Array is to use an index from 0 to size, so it's always going to be based on index. chucke (Tiago Cardoso) wrote in #note-4: > I don't see why the element ref can't be kept for post-comparison What if yo...Eregon (Benoit Daloze)
My motivation here is I would like to implement `Thread::Bactrace::Location#source_range`. For this to work in `--parser=parse.y` mode it needs to return the same start/end line/column as Prism in all cases of `RubyVM::AbstractSyntaxTre...Eregon (Benoit Daloze)
The current locations are like this: ``` foo(1, 2, kw: :arg) { 123 } |---------ITER------------| |------FCALL------| |SCOPE| ``` When `foo` does not exist, it's a `NoMethodError`, and `RubyVM::AbstractSyntaxTree.of e.backtrace_locations...Eregon (Benoit Daloze)
I think this is safe to reject, I think it's not feasible to change this. One should avoid mutating the Array while iterating, otherwise this kind of behavior is expected.Eregon (Benoit Daloze)
IMO it's not reasonable for `Array#delete_if` to do anything else than what it already does. How can `Array#delete_if` know which element you deleted and whether it should delete or not? The block returns true for the second 2nd block ca...Eregon (Benoit Daloze)
@tikkss I think there is an issue with your accounting of memory because it doesn't match the RSS of the worker process. This is running your example as-is. ``` $ ruby -v ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux]...Eregon (Benoit Daloze)