ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

January 2025

  • 3 participants
  • 217 discussions
[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
0 0
[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
0 0
[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
0 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
0 0
[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
0 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
0 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
0 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
0 0
[ruby-core:120350] [Ruby master Bug#20974] Required and optional anonymous parameter show differently in Proc#parameters
by alanwu (Alan Wu) 09 Jan '25

09 Jan '25
Issue #20974 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20974: Required and optional anonymous parameter show differently in Proc#parameters https://bugs.ruby-lang.org/issues/20974 * Author: alanwu (Alan Wu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following has had the same output since Ruby 1.9, when Proc#parameters was [introduced]: ```ruby p(proc { |(_a)| }.parameters) # => [[:opt, nil]] p(lambda { |(_a)| }.parameters) # => [[:req]] ``` I think they should be `[[:opt]]` and `[[:req]]` or `[[:opt, nil]]` and `[[:req, nil]]`. I prefer the nil-free option since that feels more anonymous. [added]: https://docs.ruby-lang.org/en/master/NEWS/NEWS-1_9_2.html -- https://bugs.ruby-lang.org/
2 2
0 0
[ruby-core:120428] [Ruby master Feature#20987] Add dbg - minimal debugging helper
by pawurb (Pawel Urbanek) 09 Jan '25

09 Jan '25
Issue #20987 has been reported by pawurb (Pawel Urbanek). ---------------------------------------- Feature #20987: Add dbg - minimal debugging helper https://bugs.ruby-lang.org/issues/20987 * Author: pawurb (Pawel Urbanek) * Status: Open ---------------------------------------- Hi. It's my first time contributing here, so I'm sorry in advance if I've mixed something up. I’m author of https://github.com/pawurb/dbg-rb gem. `dbg` method is inspired by Rust where it's built-in into std-lib (https://doc.rust-lang.org/std/macro.dbg.html) AFAIK in Ruby there's no simple mechanism to puts debug values together with caller info without using external dependencies. What’s more frustrating is that while `p nil` outputs `nil` to the std, `puts nil` prints a blank line, sometimes making debugging sessions confusing. I would like to propose adding a minimal `dbg` helper method to stdlib: ``` dbg("Hello world", [1, 2, 3]) # => [dir/file.rb:12] "Hello world" # => [dir/file.rb:12] [1, 2, 3] ``` `dbg` will produce verbose output together with informative file name and LOC info. I think that such built-in feature would be useful for many Ruby devs. My gem uses external dependencies, but I've came up with this barebones implementation: ``` def dbg(*msgs) loc = caller_locations.first.to_s matching_loc = loc.match(/.+(rb)\:\d+\:(in)\s/) src = if matching_loc.nil? loc else matching_loc[0][0..-5] end file, line = src.split(":") file = file.split("/").last(2).join("/") src = "[#{file}:#{line}]" msgs.each do |msg| puts "#{src} #{msg.inspect}" end nil end ``` ---Files-------------------------------- Screenshot 2024-12-27 at 00.00.23.png (81.5 KB) -- https://bugs.ruby-lang.org/
2 4
0 0
  • ← Newer
  • 1
  • ...
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.