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

[ruby-core:120095] [Ruby master Feature#14609] Let `Kernel#p` without an argument print the receiver
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #14609 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected out of date ---------------------------------------- Feature #14609: Let `Kernel#p` without an argument print the receiver https://bugs.ruby-lang.org/issues/14609#change-110842 * Author: ko1 (Koichi Sasada) * Status: Rejected * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract `Kernel#p(obj)` prints `obj` as `inspect`ed. How about printing the receiver if an argument is not given? # Background We recently introduced `yield_self`, which encourages block chain. https://zverok.github.io/blog/2018-01-24-yield_self.html Quoting from this article, we can write method chain with blocks: ``` construct_url .yield_self { |url| Faraday.get(url) }.body .yield_self { |response| JSON.parse(response) } .dig('object', 'id') .yield_self { |id| id || '<undefined>' } .yield_self { |id| "server:#{id}" } ``` There is a small problem concerning debugging. If we want to see the intermediate values in the method/block chain, we need to insert `tap{|e| p e}`. With the above example, ``` construct_url .yield_self { |url| Faraday.get(url) }.body .yield_self { |response| JSON.parse(response) }.tap{|e| p e} # debug print .dig('object', 'id') .yield_self { |id| id || '<undefined>' }.tap{|e| p e} # debug print .yield_self { |id| "server:#{id}" } ``` # Proposal Let `obj.p` work the same as `p(obj)`. We can replace `block{...}.tap{|e| p e}` with `block{...}.p` For the above example, we can simply add `.p` at the end of a line: ``` construct_url .yield_self { |url| Faraday.get(url) }.body .yield_self { |response| JSON.parse(response) }.p # debug print .dig('object', 'id') .yield_self { |id| id || '<undefined>' }.p # debug print .yield_self { |id| "server:#{id}" } ``` # Compatibility issues (1) Shorthand for `nil` This spec change can introduce compatibility issues because `p` returns `nil` and does not output anything. That is to say, `p` is a shorthand for `nil`. Some code-golfers use it. Maybe we can ignore them :p (2) make it a public method `Kernel#p` a is private method, so if we mistype `obj.x` as `obj.p` (not sure how it is feasible), it will raise a `NoMethodError` because of visibility. We need to change this behavior. # Note ## Past proposal and discussion Endoh-san proposed the same idea 10+ years ago [ruby-dev:29736] in Japanese. I think we should revisit this idea because of `yield_self` introduction. In this thread, Matz said "simple `p` shows `p(self)`, it is not clear". [ruby-dev:30903] ``` p はどう動くのかとか(p selfと同じ、は変な気が) self.p(obj) はどうなのかとか。その辺が解決(納得)できたら、ということで。 ``` English translation: ``` What would the behavior of: p be? (I feel strange for it to be equivalent to `p(self)`.) What would happen to self.p(obj) ``` ## pp If this proposal is accepted, we also need to change the behavior of `pp`. ## gems `tapp` method is provided by a gem. https://github.com/esminc/tapp I thought about proposing this method in core. But I found that `p` is shorter than `tapp`. A disadvantage is that `p` is too short and difficult to grep. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120094] [Ruby master Misc#11783] Do you have any idea if you have a budgets?
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #11783 has been updated by ko1 (Koichi Sasada). Status changed from Open to Closed out of date ---------------------------------------- Misc #11783: Do you have any idea if you have a budgets? https://bugs.ruby-lang.org/issues/11783#change-110841 * Author: ko1 (Koichi Sasada) * Status: Closed ---------------------------------------- Do you have any idea about Ruby interpreter implementation to do with budgets? # Background Now, we are summarizing many contributions from many people, organizations and companies. https://docs.google.com/document/d/1y1sQc40qeuWjF84rVrTmH-ogZ_iNGqU-RUSE8GD… (please let me know if you know any other contributes) (sorry we wrote contributions especially for MRI, because we don't know) The great recent news is we get new mac mini machine to run CI on El Capitan. We already have a mac mini machine running CI, but on Yosemite. So we can run CI on both Yosemite and El Capitan. This new mac mini machine was sponsored by YassLab, Japanese small company. At first, we ask Nihon-Ruby-no-Kai to prepare this machine, and Takahashi-san (chair man of this organization) tweet about it ("anyone can support it?"). Yasukawa-san, the president of YassLab answers "ok, we'll support it". We learned that if we show requirements explicitly, anyone may help us. Listing is important. # Any idea? Today's developers meeting, we had discussed about that and itemize some dreams. > nurse: VPS severs for CI are welcome. Especially for Azure. > ko1: travel fee (1,000,000 JPY?) for hackathon to gather MRI developers in one place > ko1: physical machines for development and benchmarks (300,000 JPY) > nobu: development machine (400,000 JPY) because he has several trouble on current machine. > nurse: icc (and other softwares) to try. > martin: grant project for MRI development topics > ko1: education to grow other MRI developer (no estimation) Do you have any other idea? I'll show these list at RubyKaigi, and someone may consider to support us. (IMO, maybe sponsoring nobu's machine is great contribution for Ruby worlds. Nobu will put companies logo stickers on his laptop) Thanks, Koichi -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120093] [Ruby master Feature#11670] Show warning to make nested def obsolete
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #11670 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected out of date ---------------------------------------- Feature #11670: Show warning to make nested def obsolete https://bugs.ruby-lang.org/issues/11670#change-110840 * Author: ko1 (Koichi Sasada) * Status: Rejected * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- Warn without '-w' at compile time. See https://bugs.ruby-lang.org/issues/11665 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120092] [Ruby master Misc#11295] Request for comments about error messages
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #11295 has been updated by ko1 (Koichi Sasada). Status changed from Open to Closed out of date ---------------------------------------- Misc #11295: Request for comments about error messages https://bugs.ruby-lang.org/issues/11295#change-110839 * Author: ko1 (Koichi Sasada) * Status: Closed ---------------------------------------- (This is not a proposal, bug reports) Ruby shows error messages when something wrong. There are several proposals to extend error messages. * https://github.com/charliesome/better_errors * https://github.com/yuki24/did_you_mean * https://github.com/ko1/pretty_backtrace And some requests. * Reverse backtrace and show error messages at the bottom (to avoid scroll up terminal) * Translation error messages to other languages If you have any idea, please tell us. We can consider about Ruby's error message APIs to realize your ideas. (I can't guarantee we can implement your ideas :p) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120091] [Ruby master Feature#10038] Extend ObjectSpace.dump to expose buffer addresses for String and Array
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #10038 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected too old. ---------------------------------------- Feature #10038: Extend ObjectSpace.dump to expose buffer addresses for String and Array https://bugs.ruby-lang.org/issues/10038#change-110838 * Author: ko1 (Koichi Sasada) * Status: Rejected * Assignee: tmm1 (Aman Karmani) ---------------------------------------- ObjectSpace.dump() expose internal information in JSON. How about to expose buffer addresses for String and Array? ```diff Index: ext/objspace/objspace_dump.c =================================================================== --- ext/objspace/objspace_dump.c (revision 46821) +++ ext/objspace/objspace_dump.c (working copy) @@ -178,12 +178,16 @@ dump_object(VALUE obj, struct dump_confi dump_append(dc, ", \"broken\":true"); if (FL_TEST(obj, RSTRING_FSTR)) dump_append(dc, ", \"fstring\":true"); - if (STR_SHARED_P(obj)) + + if (STR_SHARED_P(obj)) { dump_append(dc, ", \"shared\":true"); + } else { dump_append(dc, ", \"bytesize\":%ld", RSTRING_LEN(obj)); - if (!STR_EMBED_P(obj) && !STR_SHARED_P(obj) && (long)rb_str_capacity(obj) != RSTRING_LEN(obj)) + if (!STR_EMBED_P(obj) && !STR_SHARED_P(obj) && (long)rb_str_capacity(obj) != RSTRING_LEN(obj)) { dump_append(dc, ", \"capacity\":%ld", rb_str_capacity(obj)); + dump_append(dc, ", \"ptr\":\"%p\"", RSTRING_PTR(obj)); + } if (is_ascii_string(obj)) { dump_append(dc, ", \"value\":"); @@ -205,8 +209,14 @@ dump_object(VALUE obj, struct dump_confi dump_append(dc, ", \"length\":%ld", RARRAY_LEN(obj)); if (RARRAY_LEN(obj) > 0 && FL_TEST(obj, ELTS_SHARED)) dump_append(dc, ", \"shared\":true"); - if (RARRAY_LEN(obj) > 0 && FL_TEST(obj, RARRAY_EMBED_FLAG)) + if (RARRAY_LEN(obj) > 0) { + if (FL_TEST(obj, RARRAY_EMBED_FLAG)) { dump_append(dc, ", \"embedded\":true"); + } + else { + dump_append(dc, ", \"ptr\":\"%p\"", RARRAY_PTR(obj)); + } + } break; case T_CLASS: ``` With this hack, we can know the real memory address of them and cooperate with other native tools. BTW, ObjectSpace.dump() should support T_SYMBOL. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119513] [Ruby master Bug#20795] Timeout method doesn't check for negative time values
by kanakchaudhari12 (kanak chaudhari) 03 Dec '24

03 Dec '24

Issue #20795 has been reported by kanakchaudhari12 (kanak chaudhari). ---------------------------------------- Bug #20795: Timeout method doesn't check for negative time values https://bugs.ruby-lang.org/issues/20795 * Author: kanakchaudhari12 (kanak chaudhari) * Status: Open * ruby -v: 3.1.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'timeout' # Case 1: Negative timeout with quick execution Timeout.timeout(-5) do puts "This should not execute" end # Case 2: Negative timeout with sleep Timeout.timeout(-5) do sleep(10) end ``` Potential issues with current behaviour: * Inconsistency: The behaviour differs based on the block's content, which may not be immediately apparent * Silent failure: The negative timeout is silently ignored, potentially masking logical errors in the calling code. * Unexpected source of error: one might expect the timeout method to validate its input, rather than relying on methods called within the block to catch invalid time values. I suggest this change for the consistent behaviour regardless of code-block as well as the clear indication of the source of the error ```ruby def timeout(sec, klass = nil, message = nil, &block) raise ArgumentError, "timeout must be positive" if sec.is_a?(Numeric) && sec < 0 # ... end ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120033] [Ruby master Bug#20916] Prism compiler should support ** in Ractor constant
by mame (Yusuke Endoh) 03 Dec '24

03 Dec '24

Issue #20916 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20916: Prism compiler should support ** in Ractor constant https://bugs.ruby-lang.org/issues/20916 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * ruby -v: ruby 3.4.0dev (2024-11-28T02:34:20Z avoid-uninitialize.. 79ae6e72c8) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The Prism compiler raises an exception against the following code. ``` $ ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' -e:2: Ractor constant writes do not support ** -e: node type not implemented (NotImplementedError) ``` But the traditional compiler support it, and @ko1 said it should be supported. Also, I feel that this error message `node type not implemented` is a sign of a worse problem. Actually, valgrind reports `Conditional jump or move depends on uninitialised value(s)`against the Prism compiler. An assertion failure is also reported. ``` $ valgrind ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' ==49978== Memcheck, a memory error detector ==49978== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==49978== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==49978== Command: ./miniruby -e #\ shareable_constant_value:\ experimental_everything_C\ =\ {\ **{\ }\ } ==49978== ==49978== Warning: set address range perms: large range [0x64e0000, 0x1e4e0000) (defined) -e:2: Ractor constant writes do not support ** ==49978== Conditional jump or move depends on uninitialised value(s) ==49978== at 0x4BB42A: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== by 0x1DA66A: pm_compile_node (prism_compile.c:9805) ==49978== by 0x1F61A7: pm_iseq_compile_node (prism_compile.c:10109) ==49978== by 0x2A5303: pm_iseq_new_with_opt_try (iseq.c:1027) ==49978== by 0x23DFF2: rb_protect (eval.c:1033) ==49978== by 0x2AB198: pm_iseq_new_with_opt (iseq.c:1080) ==49978== miniruby: prism/util/pm_newline_list.c:63: pm_newline_list_line: Assertion `cursor >= list->start' failed. ==49978== ==49978== Process terminating with default action of signal 6 (SIGABRT) ==49978== at 0x4AFAB1C: __pthread_kill_implementation (pthread_kill.c:44) ==49978== by 0x4AFAB1C: __pthread_kill_internal (pthread_kill.c:78) ==49978== by 0x4AFAB1C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89) ==49978== by 0x4AA126D: raise (raise.c:26) ==49978== by 0x4A848FE: abort (abort.c:79) ==49978== by 0x4A8481A: __assert_fail_base.cold (assert.c:94) ==49978== by 0x4A97506: __assert_fail (assert.c:103) ==49978== by 0x4BB49B: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== ==49978== HEAP SUMMARY: ==49978== in use at exit: 2,645,494 bytes in 10,084 blocks ==49978== total heap usage: 36,662 allocs, 26,578 frees, 6,066,537 bytes allocated ==49978== ==49978== LEAK SUMMARY: ==49978== definitely lost: 0 bytes in 0 blocks ==49978== indirectly lost: 0 bytes in 0 blocks ==49978== possibly lost: 1,050,576 bytes in 4 blocks ==49978== still reachable: 1,594,918 bytes in 10,080 blocks ==49978== suppressed: 0 bytes in 0 blocks ==49978== Rerun with --leak-check=full to see details of leaked memory ==49978== ==49978== Use --track-origins=yes to see where uninitialised values come from ==49978== For lists of detected and suppressed errors, rerun with: -s ==49978== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120034] [Ruby master Bug#20917] redo/next in nested begin block causes wrong order of execution
by hoshiumiarata (Arata Hoshiumi) 02 Dec '24

02 Dec '24

Issue #20917 has been reported by hoshiumiarata (Arata Hoshiumi). ---------------------------------------- Bug #20917: redo/next in nested begin block causes wrong order of execution https://bugs.ruby-lang.org/issues/20917 * Author: hoshiumiarata (Arata Hoshiumi) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that `redo`/`next` in a nested `begin` block can cause the wrong order of execution. For example: ```ruby for _ in [0] puts 0 begin puts 1 begin puts 2 redo ensure puts 3 end ensure puts 4 break end end ``` It prints: ``` 0 1 2 3 4 3 4 => nil ``` But I think it should print: ``` 0 1 2 3 4 => nil ``` Because execution order should be: 1. `puts 0` 2. `puts 1` 3. `puts 2` 4. `redo` 5. unwind to nested `ensure` block 6. `puts 3` 7. unwind to outer `ensure` block 8. `puts 4` 9. `break` 10. end of loop Interestingly enough, if we add an empty `rescue` block before any of the `ensure` blocks, then the execution order is correct. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120002] [Ruby master Bug#20908] Ruby extension builds fail with GCC 15 which defaults to -std=gnu23
by thesamesam (Sam James) 01 Dec '24

01 Dec '24

Issue #20908 has been reported by thesamesam (Sam James). ---------------------------------------- Bug #20908: Ruby extension builds fail with GCC 15 which defaults to -std=gnu23 https://bugs.ruby-lang.org/issues/20908 * Author: thesamesam (Sam James) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi! Upcoming GCC 15 defaults to C23 (`-std=gnu23`). One thing C23 changes is removing unprototyped functions, so `void foo()` now means `void foo(void)`, rather than "any arguments". Ruby extensions fail to build as a result with GCC 15. This was reported downstream in Gentoo at https://bugs.gentoo.org/943784 where brotli-0.6.0 is an example: ``` make: Entering directory '/var/tmp/portage/dev-ruby/brotli-0.6.0/work/ruby32/brotli-0.6.0/ext/brotli' x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby-3.2.0/x86_64-linux -I/usr/include/ruby-3.2.0/ruby/backward -I/usr/include/ruby-3.2.0 -I. -DHAVE_BROTLI_DECODE_H -DHAVE_BROTLI_ENCODE_H -fPIC -O2 -pipe -march=native -fno-diagnostics-color -o brotli.o -c brotli.c In file included from /usr/include/ruby-3.2.0/ruby/ruby.h:27, from /usr/include/ruby-3.2.0/ruby.h:38, from brotli.h:4, from brotli.c:1: brotli.c: In function ‘Init_brotli’: /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:45: error: passing argument 3 of ‘rb_define_singleton_method_m1’ from incompatible pointer type [-Wincompatible-pointer-types] 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^ | | | VALUE (*)(void) {aka long unsigned int (*)(void)} /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:308:144: note: in definition of macro ‘rb_define_singleton_method’ 308 | #define rb_define_singleton_method(obj, mid, func, arity) RBIMPL_ANYARGS_DISPATCH_rb_define_singleton_method((arity), (func))((obj), (mid), (func), (arity)) | ^~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:33: note: in expansion of macro ‘RBIMPL_CAST’ 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^~~~~~~~~~~ brotli.c:478:55: note: in expansion of macro ‘RUBY_METHOD_FUNC’ 478 | rb_define_singleton_method(rb_mBrotli, "deflate", RUBY_METHOD_FUNC(brotli_deflate), -1); | ^~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:271:21: note: expected ‘VALUE (*)(int, union <anonymous>, VALUE)’ {aka ‘long unsigned int (*)(int, union <anonymous>, long unsigned int)’} but argument is of type ‘VALUE (*)(void)’ {aka ‘long unsigned int (*)(void)’} 271 | RBIMPL_ANYARGS_DECL(rb_define_singleton_method, VALUE, const char *) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:254:41: note: in definition of macro ‘RBIMPL_ANYARGS_DECL’ 254 | RBIMPL_ANYARGS_ATTRSET(sym) static void sym ## _m1(__VA_ARGS__, VALUE(*)(int, union { VALUE *x; const VALUE *y; } __attribute__((__transparent_union__)), VALUE), int); \ | ^~~ ``` The `ANYARGS` macro can't work in its current form, as defined at e.g. https://github.com/ruby/ruby/blob/f127bcb8294fd417c253dd7acab3ff3b9f0bf555/…: ``` #ifndef ANYARGS # ifdef __cplusplus # define ANYARGS ... # else # define ANYARGS # endif #endif ``` ... because of the change in C23 I mentioned above, i.e. `(ANYARGS)` being `()` now means no arguments, not any. I note that Ruby was adapted in part already for this change, see e.g. https://github.com/ruby/ruby/commit/4e64edb6cd8d1b444c591bfd50ec3d357e794f6e, but it appears that the headers that extensions need to build against aren't yet ready. -- https://bugs.ruby-lang.org/

4 6