January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:119944] [Ruby master Feature#20899] Reconsider adding `Array#find_map`
by toy (Ivan Kuchin) 12 Jan '25

12 Jan '25

Issue #20899 has been reported by toy (Ivan Kuchin). ---------------------------------------- Feature #20899: Reconsider adding `Array#find_map` https://bugs.ruby-lang.org/issues/20899 * Author: toy (Ivan Kuchin) * Status: Open ---------------------------------------- I would like to retry proposing method `Array#find_map` that was rejected in [8421](https://bugs.ruby-lang.org/issues/8421) which happened before introduction of `filter_map` in [15323](https://bugs.ruby-lang.org/issues/15323). It would make code nicer whenever there is a need to get the first truthy result of applying some code. Adapting examples from `filter_map` documentation, but if I need only the first value: ```rb (1..9).find_map {|i| i * 2 if i.even? } # => 4 {foo: 0, bar: 1, baz: 2}.find_map {|key, value| key if value.even? } # => :foo ``` Or an example of getting match group for first successful match: ```rb list = ['some 123', 'list 234', 'of 345', 'strings 456'] list.find_map{ |s| s[/\Aof (\d+)\z/, 1] } # => "345" ``` Currently I imagine either more code and/or inefficiency (extra calls and/or objects): ```rb # code called twice list.find{ |s| s[/\Aof (\d+)\z/, 1] }&.then{ |s| s[/\Aof (\d+)\z/, 1] } # => "345" # more logic result = nil list.each do |s| break if (result = s[/\Aof (\d+)\z/, 1]) end result # => "345" # or result = nil list.find do |s| result = s[/\Aof (\d+)\z/, 1] end result # => "345" # extra calls for items which come after item that we were looking for list.map{ |s| s[/\Aof (\d+)\z/, 1] }.find{ _1 } # => "345" # using lazy list.lazy.map{ |s| s[/\Aof (\d+)\z/, 1] }.find{ _1 } # => "345" # or as suggested by @alexbarret in https://bugs.ruby-lang.org/issues/8421?tab=history#note-7 list.lazy.filter_map{ |s| s[/\Aof (\d+)\z/, 1] }.first # => "345" # using tricks, as suggested by @zverok in https://bugs.ruby-lang.org/issues/8421?tab=history#note-4 list.find{ |s| result = s[/\Aof (\d+)\z/, 1] and break result } # => "345" ``` Implementation in ruby can be: ```rb Enumerable.class_eval do def find_map(&block) each do |element| block_result = block.call(element) return block_result if block_result end nil end end ``` An example from another language - scala method [`collect`](https://www.scala-lang.org/api/3.5.2/scala/collection/ArrayOps.html#collect-68e) works alike `filter_map` and [`collectFirst`](https://www.scala-lang.org/api/3.5.2/scala/collection/ArrayOps.html#collectFirst-25d) would be like `find_map`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:119272] [Ruby master Feature#20757] Make rb_tracearg_(parameters|eval_script|instruction_sequence) public C-API
by richardboehme 11 Jan '25

11 Jan '25

Issue #20757 has been reported by richardboehme (Richard Böhme). ---------------------------------------- Feature #20757: Make rb_tracearg_(parameters|eval_script|instruction_sequence) public C-API https://bugs.ruby-lang.org/issues/20757 * Author: richardboehme (Richard Böhme) * Status: Open ---------------------------------------- **Abstract** As a C-extension developer when using tracepoints I include "ruby/debug.h". This includes most of TracePoint's API but it seems like the C-equivalents for TracePoint#parameters, TracePoint#eval_script and TracePoint#instruction_sequence are missing/not being exported in the header. **Background** Most APIs like rb_tracearg_return_value are exported in "ruby/debug.h". If I understand correctly, the implementations for those methods are located in "ruby/vm_trace.c". The following methods implemented in "ruby/vm_trace.c" are missing in "ruby/debug.h": * rb_tracearg_parameters * rb_tracearg_eval_script * rb_tracearg_instruction_sequence **Proposal** I propose to add those methods to "ruby/debug.h". From my limiting understanding the change should be simple and not break backward compatibility, because we'd only need to add those function declarations to "ruby/debug.h". I'd be open to contribute this change if it was approved. **Use cases** I'm implementing a method call tracer for Ruby using the C-extension API. I wanted to get information about the parameters that the called method receives. When writing in Ruby this can be done using the TracePoint#parameters method, but I could not find the equivalent C-API. A workaround is to retrieve the method object (using the method_id) and check the method parameters. **See also** * Implementation of TracePoint#parameters in #14694 * Implementation of TracePoint#eval_script and TracePoint#instruction_sequence in #15287 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120545] [Ruby master Feature#21015] Add in a `-g` flag, like `-s` but with a few more quality of life features
by sampersand2 (Sam Westerman) 11 Jan '25

11 Jan '25

Issue #21015 has been reported by sampersand2 (Sam Westerman). ---------------------------------------- Feature #21015: Add in a `-g` flag, like `-s` but with a few more quality of life features https://bugs.ruby-lang.org/issues/21015 * Author: sampersand2 (Sam Westerman) * Status: Open ---------------------------------------- Add in a `-g` flag, like `-s` but with a few more QOL features ## TL;DR ([PR](https://github.com/ruby/ruby/pull/12526).) Ruby's `-s` flag has quite a few shortfalls that make it difficult to use when writing scripts . A new `-g` flag will fix it: ```shell # Support `-abc` as a shorthand for `-a -b -c` ruby -ge'p [$a, $b, $c]' -- -abc #=> [1, 1, 1] # Support `-vvv` as a shorthand for `-v=3` ruby -ge'p $v' -- -vvv #=> 3 # Support things other than strings: ruby -ge'p [$n, $f]' -- -n90 -f=false #=> [90, false] # long-forms don't have a leading `_` ruby -ge'p $foo_bar' -- --foo-bar #=> true ``` I propose a `-g` flag to fix it. # Background: What is `-s` Ruby's `-s` flag is an extremely helpful feature when writing short little scripts to set config options; it automatically processes `ARGV` and removes leading "flags" for you, assigning them to global variables. ```ruby #!/bin/ruby -s # echo, ruby-style! If `-n` is given, no newline is printed print ARGV.join(' '), ($n ? "" : "\n") ``` While `-s` is significantly less powerful than `OptionParse`, or even via just parsing options yourselves, it's **incredibly** useful when writing simple little scripts where the option parsing code would be longer than the script itself. ## Problem 1 (The big one): No support for chained short-form flags The biggest problem with `-s` is that it doesn't let you concatenate short-form flags together: conventionally, `./myprogram -x -y -z` should be the same as `./myprogram -xyz`. However, if `./myprogram` were a ruby program using `-s`, you'd end up with the global variable `$xyz`. Short scripts that use `-s` to parse options thus need to add the following code to handle all different permutations of `-x`, `-y`, and `-z`: ```ruby # Handle all permutations of `-xyz` $xyz || $xzy || $yxz || $yzx || $zxy || $zyx and $x=$y=$z=true # Handle only two options given $xy || $yx and $x=$y=true $xz || $zx and $x=$z=true $yz || $zy and $y=$z=true ``` Four flags becomes even worse: ```ruby $wxyz || $wxzy || $wyxz || $wyzx || \ $wzxy || $wzyx || $xwyz || $xwzy || \ $xywz || $xyzw || $xzwy || $xzyw || \ $ywxz || $ywzx || $yxwz || $yxzw || \ $yzwx || $yzxw || $zwxy || $zwyx || \ $zxwy || $zxyw || $zywx || $zyxw and $w=$x=$y=$z=true $wxy || $wyx || $xwy || $xyw || $ywx || $yxw and $w=$x=$y=true $wxz || $wzx || $xwz || $xzw || $zwx || $zxw and $w=$x=$z=true $wyz || $wzy || $ywz || $yzw || $zwy || $zyw and $w=$y=$z=true $xyz || $xzy || $yxz || $yzx || $zxy || $zyx and $x=$y=$z=true $wx || $xw and $w=$x=true $wy || $yw and $w=$y=true $wz || $zw and $w=$z=true $xy || $yx and $x=$y=true $xz || $zx and $x=$z=true $yz || $zy and $y=$z=true ``` This is a huge problem for simple little scripts, as they're forced into an uncomfortable choice: 1. Use `OptionParser`, which is very much overkill for tiny scripts 2. Break from unix standards and require passing short-forms individually (i.e. `./program.rb -x -y -z`) 3. Do the cumbersome permutation checks as shown above 4. Give up on flags all together and use environment variables. None of these options are great, *especially* because Ruby's all about programmer happiness and none of these options spark joy. ## Problem 2: All values are `Strings` Less important than the short-form issue is that all values provided to flags become Strings (e.g. `ruby -se'p $foo' -- -foo=30` yields `"30"`). While this can be solved by `$foo = $foo&.to_i` somewhere early on, it's verbose: ```ruby #!ruby -s # Very simple benchmarking program $log_level = $log_level&.to_i $amount = $amount&.to_i $timeout = $timeout&.to_i $precision = $precision&.to_i $amount.times do |iter| start = Time.now $log_level > 1 and puts "[iteration: #{iter}] running: #{ARGV}" pipe = IO.popen ARGV unless select [pipe], nil, nil, $timeout warn "took too long!" next end printf "%0.#{$precision}f", Time.now - start end ``` Moreover, there's no way to create a falsey flag other than just omitting it, which can make interacting with `-s` scripts somewhat irritating: ```ruby # Have to use `*[... ? ... : nil].compact`, otherwise # we'd end up passing an empty string/nil as an arg system("./myprogram.rb", *[enable_foo ? "--foo" : nil].compact) ``` A better solution would be to allow for `--foo=false` or `--foo=true`, and then parse the `false`/`true`. ## Problem 3 (Minor): Long-form options have a leading `_` Long-form options, such as `--help`, have a leading `_` appended to them (to disambiguate them from `-help`). While it can be worked around (either `alias $help $_help` or just using `$_help` directly), it's irritating enough that I've been known to just force end-users to use `-help`. This diverges from the common "long-form options should have two dashes in front of them," further making ruby scripts with `-s` a bit awkward to use ## Problem 4 (Minor): Repeated flags aren't supported Sometimes it's useful to know how many times a flag was repeated, such as `-vvv` to enable "very very verbose mode": Using `-s` you must do ```ruby is_verbose = $v ? 1 : ($vv ? 2 : ($vvv ? 3 : ($vvvv ? 4 : ...))) ``` While I've yet to see a use-case for repeating a flag beyond three or four times, having to manually enumerate everything out is, again, a bit of a pain. # Solution: Add a new `-g` flag, which supports all this I propose the addition of a new command-line flag, `-g`, which adds in a new form of argument parsing that solves all these issues. [PR](https://github.com/ruby/ruby/pull/12526) ## Overview: ```shell ruby -ge'p [$a, $b, $c]' -- -abc #=> [1, 1, 1] ruby -ge'p $d' -- -d90 #=> 90 ruby -ge'p [$d, $e]' -- -d90e=foo #=> [90, "foo"] ruby -ge'p [$hi, $foo_bar]' -- --hi --foo-bar=false #=> [true, false] ruby -ge'p $x' -- -xxx #=> 3 # Putting it together now, lol. ruby -g -e'p [$a, $b, $c, $d, $e, $world]' -- -abbcd90e=hello --world=false # => [true, 2, true, 90, "hello", false]``` ``` # Open Questions ## How should supplying both `-g` and `-s` work? This is the first flag that'd directly conflict with another command-line flag, so what should be done when both `-g` and `-s` are given (such as `ruby -gs -e'p $x' -- -x=9`). Here's the options as I see them: 1. Use to last supplied flag (in the example `-s`). This'd act like how incompatible flags work in other utilities 2. Always use `-g`, as it can be considered a sort-of a "super set" of `-s`. 3. Emit a warning, and then do either `1.` or `2.` 4. Emit an error, and then do either `1.` or `2.` I'm personally partial to emitting a warning on `-W2`, and then using the last supplied flag, however I could be convinced to any of the options ## Should `-x` do `$x = true` or `$x = 1` I personally'd like `-x` to be `true`, just like `-s`. However, this conflicts with `-xx` yielding `2`, as `log if $x > 1` wouldn't work. Since `1` is truthy, I've defaulted `-x` to `1`, but I could be convinced to remove it (and even remove the entire `-xx` thing if there was a good argument.) ## Why introduce a new flag? Why name it `-g`? I think adding in a new flag makes sense: `-g` is a modification of `-s`, so it naturally should be a new flag. (Attempting to shoehorn these options into `-s` would be a nightmare.) I briefly considered using `-ss` as the flag name, to make it clear that it was a modification of `-s`, however that'd be the first two-character short flag and I didn't want to introduce that. (And, it'd be pretty ironic as a large portion of the impetus behind `-g` is to parse short flags, which `-ss` isn't :-P.) As for `-g` specifically, I considered `-o` for "options" (nixed because most utilities use it for "output," and I didn't want the cognitive overload), and `-f` for "flags" (nixed because some utilities use it to mean "file," and ruby might use it in the future.) I picked `-g` because it's short for "globals" or "getflags". # Alternatives (TODO) ## Continue using `-s` (TODO) not great, as shown above # Prior art (TODO) Perl has `-s`, and it works like Ruby's `-s`. IDK of any other languages which even attempt this. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120602] [Ruby master Misc#21025] What's the default encoding of `String.new`?
by deivid 10 Jan '25

10 Jan '25

Issue #21025 has been reported by deivid (David Rodríguez). ---------------------------------------- Misc #21025: What's the default encoding of `String.new`? https://bugs.ruby-lang.org/issues/21025 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In the documentation (https://docs.ruby-lang.org/en/3.4/encodings_rdoc.html#label-String+Encoding) I see a good explanation of default string encodings: ![](Captura%20de%20pantalla%202025-01-10%20a%20las%2017.53.06.png) However, it does not mention `String.new` without an argument, which is the one case where I see inconsistent behavior. ``` irb(main):001> "".encoding => #<Encoding:UTF-8> irb(main):002> String.new("").encoding => #<Encoding:UTF-8> irb(main):003> String.new(a="").encoding => #<Encoding:UTF-8> irb(main):004> String.new.encoding => #<Encoding:BINARY (ASCII-8BIT)> ``` Should this be documented or changed? ---Files-------------------------------- Captura de pantalla 2025-01-10 a las 17.53.06.png (139 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120584] [Ruby master Bug#21022] The --with-modular-gc= option is a
by vo.x (Vit Ondruch) 10 Jan '25

10 Jan '25

Issue #21022 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #21022: The --with-modular-gc= option is a https://bugs.ruby-lang.org/issues/21022 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM +GC [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Just experimenting a bit with the `--with-modular-gc=` if it is worth of enabling in Fedora, but I somehow cannot wrap my head around that. What is the intended configuration? From Fedora POV, we have Ruby installed somewhere in `/usr`, which can only be managed by RPM. I don't think that we would like to package any additional GC. But if we wanted, we would likely installed it outside of the default Ruby directory structure. We would also like our users to experiment. So they would ideally have their GC built somewhere in their HOME. In that case, I'd expect that something like `RUBY_GC_LIBRARY=/home/johndoe/path/to/gc/gc.so ruby -e 'puts "Hello custom GC"'` would be command to run. But it does not seems that the current configuration option / env variables have anything like this in their mind. Actually I wonder why the GC is not packaged as gem? Maybe RubyGems are late to the party to load the GC early enough. But they still would be nice method of distribution. From #20860 I understand that the MMTk is experimental. But from the Ruby 3.4, the Modular GC seems to be as something users might want. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120594] [Ruby master Bug#21023] Unintentional ruby/spec capi extension build twice
by hsbt (Hiroshi SHIBATA) 10 Jan '25

10 Jan '25

Issue #21023 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21023: Unintentional ruby/spec capi extension build twice https://bugs.ruby-lang.org/issues/21023 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced `building spec/ruby/optional/capi/ext/` build twice sometimes like: ``` ❯ make -j revision.h updated generating arm64-darwin24-fake.rb arm64-darwin24-fake.rb updated rbconfig.rb unchanged generating encdb.h generating enc.mk creating verconf.h verconf.h updated compiling loadpath.c encdb.h unchanged making srcs under enc generating transdb.h linking static-library libruby.3.5-static.a transdb.h unchanged linking shared-library libruby.3.5.dylib generating makefiles ext/configure-ext.mk building spec/ruby/optional/capi/ext/array_spec.bundle building spec/ruby/optional/capi/ext/bignum_spec.bundle building spec/ruby/optional/capi/ext/basic_object_spec.bundle building spec/ruby/optional/capi/ext/binding_spec.bundle building spec/ruby/optional/capi/ext/boolean_spec.bundle building spec/ruby/optional/capi/ext/class_id_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/class_spec.bundle building spec/ruby/optional/capi/ext/class_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/data_spec.bundle building spec/ruby/optional/capi/ext/complex_spec.bundle building spec/ruby/optional/capi/ext/constants_spec.bundle building spec/ruby/optional/capi/ext/debug_spec.bundle building spec/ruby/optional/capi/ext/encoding_spec.bundle building spec/ruby/optional/capi/ext/enumerator_spec.bundle building spec/ruby/optional/capi/ext/fiber_spec.bundle building spec/ruby/optional/capi/ext/file_spec.bundle building spec/ruby/optional/capi/ext/exception_spec.bundle building spec/ruby/optional/capi/ext/fixnum_spec.bundle building spec/ruby/optional/capi/ext/float_spec.bundle building spec/ruby/optional/capi/ext/gc_spec.bundle building spec/ruby/optional/capi/ext/globals_spec.bundle building spec/ruby/optional/capi/ext/hash_spec.bundle building spec/ruby/optional/capi/ext/io_spec.bundle building spec/ruby/optional/capi/ext/numeric_spec.bundle building spec/ruby/optional/capi/ext/integer_spec.bundle building spec/ruby/optional/capi/ext/kernel_spec.bundle building spec/ruby/optional/capi/ext/module_spec.bundle building spec/ruby/optional/capi/ext/marshal_spec.bundle building spec/ruby/optional/capi/ext/module_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/language_spec.bundle building spec/ruby/optional/capi/ext/mutex_spec.bundle building spec/ruby/optional/capi/ext/symbol_spec.bundle building spec/ruby/optional/capi/ext/time_spec.bundle building spec/ruby/optional/capi/ext/string_spec.bundle building spec/ruby/optional/capi/ext/proc_spec.bundle building spec/ruby/optional/capi/ext/thread_spec.bundle building spec/ruby/optional/capi/ext/object_spec.bundle building spec/ruby/optional/capi/ext/rbasic_spec.bundle building spec/ruby/optional/capi/ext/range_spec.bundle building spec/ruby/optional/capi/ext/rational_spec.bundle building spec/ruby/optional/capi/ext/util_spec.bundle building spec/ruby/optional/capi/ext/st_spec.bundle building spec/ruby/optional/capi/ext/tracepoint_spec.bundle building spec/ruby/optional/capi/ext/regexp_spec.bundle building spec/ruby/optional/capi/ext/struct_spec.bundle building spec/ruby/optional/capi/ext/typed_data_spec.bundle making enc making trans ext/configure-ext.mk updated making encs generating makefile exts.mk exts.mk unchanged compiling version.c linking miniruby ln -sf ../../rbconfig.rb .ext/arm64-darwin24/rbconfig.rb builtin_binary.inc updated ae4db3fa410991261f4203ac62ff7aa8eb3959967203d43e69af30c1ea1423fe builtin_binary.inc compiling builtin.c linking static-library libruby.3.5-static.a linking shared-library libruby.3.5.dylib building spec/ruby/optional/capi/ext/array_spec.bundle building spec/ruby/optional/capi/ext/basic_object_spec.bundle building spec/ruby/optional/capi/ext/bignum_spec.bundle building spec/ruby/optional/capi/ext/binding_spec.bundle building spec/ruby/optional/capi/ext/boolean_spec.bundle building spec/ruby/optional/capi/ext/class_spec.bundle building spec/ruby/optional/capi/ext/class_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/class_id_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/complex_spec.bundle building spec/ruby/optional/capi/ext/constants_spec.bundle building spec/ruby/optional/capi/ext/debug_spec.bundle building spec/ruby/optional/capi/ext/data_spec.bundle building spec/ruby/optional/capi/ext/encoding_spec.bundle building spec/ruby/optional/capi/ext/enumerator_spec.bundle building spec/ruby/optional/capi/ext/exception_spec.bundle building spec/ruby/optional/capi/ext/fiber_spec.bundle building spec/ruby/optional/capi/ext/fixnum_spec.bundle building spec/ruby/optional/capi/ext/file_spec.bundle building spec/ruby/optional/capi/ext/gc_spec.bundle building spec/ruby/optional/capi/ext/float_spec.bundle building spec/ruby/optional/capi/ext/hash_spec.bundle building spec/ruby/optional/capi/ext/integer_spec.bundle building spec/ruby/optional/capi/ext/globals_spec.bundle building spec/ruby/optional/capi/ext/language_spec.bundle building spec/ruby/optional/capi/ext/io_spec.bundle building spec/ruby/optional/capi/ext/kernel_spec.bundle building spec/ruby/optional/capi/ext/marshal_spec.bundle building spec/ruby/optional/capi/ext/module_spec.bundle building spec/ruby/optional/capi/ext/module_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/mutex_spec.bundle building spec/ruby/optional/capi/ext/numeric_spec.bundle building spec/ruby/optional/capi/ext/object_spec.bundle building spec/ruby/optional/capi/ext/proc_spec.bundle building spec/ruby/optional/capi/ext/range_spec.bundle building spec/ruby/optional/capi/ext/regexp_spec.bundle building spec/ruby/optional/capi/ext/rational_spec.bundle building spec/ruby/optional/capi/ext/string_spec.bundle building spec/ruby/optional/capi/ext/rbasic_spec.bundle building spec/ruby/optional/capi/ext/struct_spec.bundle building spec/ruby/optional/capi/ext/tracepoint_spec.bundle building spec/ruby/optional/capi/ext/st_spec.bundle building spec/ruby/optional/capi/ext/symbol_spec.bundle building spec/ruby/optional/capi/ext/thread_spec.bundle building spec/ruby/optional/capi/ext/time_spec.bundle building spec/ruby/optional/capi/ext/util_spec.bundle building spec/ruby/optional/capi/ext/typed_data_spec.bundle linking ruby ``` @nobu said "It's triggered with `linking shared-library libruby.3.5.dylib`". It seems unintentional behavior. we should avoid that. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117826] [Ruby master Bug#20480] Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc
by nekoyama32767 (Jinsong Yu) 10 Jan '25

10 Jan '25

Issue #20480 has been reported by nekoyama32767 (Jinsong Yu). ---------------------------------------- Bug #20480: Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc https://bugs.ruby-lang.org/issues/20480 * Author: nekoyama32767 (Jinsong Yu) * Status: Open * ruby -v: ruby 3.4.0dev (2024-05-10T04:54:31Z master 2f915e729a) [x64-mingw32] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Master commit:`2f915e729ac8c66f4009f4b28a57773923d7e7d1` NET_LUID is not successfully checked in win32 configure. When try to compile in msys2 mingw64-gcc there will be a error message like follow. ``` win32/win32.c:4365:7: error: conflicting types for 'NET_LUID'; have 'struct <anonymous>' 4365 | } NET_LUID; | ^~~~~~~~ In file included from D:/msys64/mingw64/include/iptypes.h:17, from D:/msys64/mingw64/include/iphlpapi.h:17, from ./include/ruby/win32.h:40, from ./include/ruby/internal/dosish.h:38, from ./include/ruby/defines.h:78, from ./include/ruby/ruby.h:25, from win32/win32.c:24: D:/msys64/mingw64/include/ifdef.h:106:3: note: previous declaration of 'NET_LUID' with type 'NET_LUID' 106 | } NET_LUID, *PNET_LUID; | ^~~~~~~~ ``` Mingw64-gcc has NET_LUID, when comment out line 4357-line 4367 in `win32/win32.c` in follow, compile will be successed. ``` #ifndef HAVE_TYPE_NET_LUID typedef struct { uint64_t Value; struct { uint64_t Reserved :24; uint64_t NetLuidIndex :24; uint64_t IfType :16; } Info; } NET_LUID; #endif ``` mingw64-gcc version ``` gcc --version gcc.exe (Rev4, Built by MSYS2 project) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120514] [Ruby master Misc#21009] Removed old archives from top-level of cache.ruby-lang.org.
by hsbt (Hiroshi SHIBATA) 10 Jan '25

10 Jan '25

Issue #21009 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #21009: Removed old archives from top-level of cache.ruby-lang.org. https://bugs.ruby-lang.org/issues/21009 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- https://cache.ruby-lang.org/pub/ruby/ has `ruby-1.8` to `ruby-2.6` and old versions of snapshot built by 2020. That archives also stored under like `1.8` directory. We can remove them because Ruby 2.6 was already EOL about 3 years ago. Motivation: https://cache.ruby-lang.org/pub/ruby/ shows `ruby-1.8`... list. I thought `ruby-3.4` also stored like `https://cache.ruby-lang.org/pub/ruby/ruby-3.4.1.tar.gz`. But it's nothing. We should avoid that situation. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120589] [Ruby master Feature#8751] Add offsets to method#source_location
by rocky (Rocky Bernstein) 09 Jan '25

09 Jan '25

Issue #8751 has been updated by rocky (Rocky Bernstein). Eregon (Benoit Daloze) wrote in #note-7: > In light of end line and column information being added in #6012 do you think there is still a need for byte offsets? Sure, this is fine. Feel free to close issue. ---------------------------------------- Feature #8751: Add offsets to method#source_location https://bugs.ruby-lang.org/issues/8751#change-111414 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hello, I would like to have byte offsets returned on the source_location for methods. For example: def foo(&b) b.source_location # => [file_name, line_number, start_byte, end_byte] end If we had the start and end byte for a method or proc, then we could find the source for methods and procs in each file. There are some cases (like with heredocuments) where the "end of the method" could be after the `end` keyword. But I think if we just have offsets for the start of `def` and the end of `end`, I think it would cover 99% of usecases. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120581] [Ruby master Feature#6012] Proc#source_location also return the column
by Dan0042 (Daniel DeLorme) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-25: > Matz was negative neither on adding a new class like Ruby::CodeLocation for this purpose Any idea why? Because it seems like the "obviously correct" design so I'm curious why it was decided against. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111406 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0