- ruby-core - ml.ruby-lang.org

[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

[ruby-core:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 09 Jan '25

09 Jan '25

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

7 15

[ruby-core:120577] [Ruby master Feature#8751] Add offsets to method#source_location
by Eregon (Benoit Daloze) 09 Jan '25

09 Jan '25

Issue #8751 has been updated by Eregon (Benoit Daloze). In light of end line and column information being added in #6012 do you think there is still a need for byte offsets? ---------------------------------------- Feature #8751: Add offsets to method#source_location https://bugs.ruby-lang.org/issues/8751#change-111404 * 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:120576] [Ruby master Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by Eregon (Benoit Daloze). Great to see this was accepted and even already implemented! (thanks @nobu!) Byte offsets would be mostly for performance ("character" columns in multibyte files can be expensive to compute) and convenience (e.g. read the code at the given source_location from the file). They are not strictly necessary. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111403 * 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

[ruby-core:120572] [Ruby master Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by mame (Yusuke Endoh). This was discussed at the October 2024 dev meeting and @matz approved `source_location` to return `[path, start_line, start_column, end_line, end_column]`. https://github.com/ruby/dev-meeting-log/blob/28e0f45f334b31e60c7e07d25b6b6c… Matz was negative neither on adding a new class like Ruby::CodeLocation for this purpose, or adding offset information. We briefly re-asked matz about this at today's dev meeting, and he had not changed his mind. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111396 * Author: rogerdpack (Roger Pack) * Status: Assigned * 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

[ruby-core:120397] [Ruby master Bug#20980] Range#size new TypeError vs semi-open ranges
by zverok (Victor Shepelev) 09 Jan '25

09 Jan '25

Issue #20980 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20980: Range#size new TypeError vs semi-open ranges https://bugs.ruby-lang.org/issues/20980 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-24T14:40:12Z master 07e89bde46) +PRISM [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- Since #18984, `Range#size` throws `TypeError` if the `begin` is not iterable (doesn't respond to `#succ`). It produces one small inconvenience compared to 3.3: ```ruby ('a'..).size #=> nil (..'a').size # 3.3: nil # 3.4: can't iterate from NilClass (TypeError) -- well, probably makes sense # BUT: (3..).size #=> Infinity -- cool! (..3).size # 3.3: Infinity -- reasonable? # 3.4: can't iterate from NilClass (TypeError) -- worse? ``` I believe that while 3.4's behavior is explainable, 3.3's one has better DX. (Obviously too late to change before the release, but maybe might be considered for some patch version or Ruby 3.5?..) -- https://bugs.ruby-lang.org/

2 1