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

[ruby-core:120080] [Ruby master Bug#20926] shareable_constant_value: experimental_everything crashes with parse.y
by tenderlovemaking (Aaron Patterson) 06 Dec '24

06 Dec '24

Issue #20926 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20926: shareable_constant_value: experimental_everything crashes with parse.y https://bugs.ruby-lang.org/issues/20926 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This program crashes with parse.y as the parser: ``` ./miniruby --dump=insns --parser=parse.y -v -e'# shareable_constant_value: experimental_everything C = { **{ } }' ``` Backtrace from LLDB looks like this: ``` (lldb) run Process 66489 launched: '/Users/aaron/git/ruby/miniruby' (arm64) Process 66489 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3523922faa9c0058) frame #0: 0x0000000100220f84 miniruby`RB_BUILTIN_TYPE(obj=3829064841618522200) at value_type.h:191:30 188 * RB_SPECIAL_CONST_P check. */ 189 __asm volatile("": : :"memory"); 190 #endif -> 191 VALUE ret = RBASIC(obj)->flags & RUBY_T_MASK; 192 return RBIMPL_CAST((enum ruby_value_type)ret); 193 } 194 Target 0: (miniruby) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3523922faa9c0058) * frame #0: 0x0000000100220f84 miniruby`RB_BUILTIN_TYPE(obj=3829064841618522200) at value_type.h:191:30 frame #1: 0x0000000100220e84 miniruby`RCLASS_SINGLETON_P [inlined] rbimpl_RB_TYPE_P_fastpath(obj=3829064841618522200, t=RUBY_T_CLASS) at value_type.h:352:19 frame #2: 0x0000000100220d0c miniruby`RCLASS_SINGLETON_P(klass=3829064841618522200) at class.h:202:12 frame #3: 0x0000000100220c80 miniruby`rb_class_real(cl=3829064841618522200) at object.c:290:10 frame #4: 0x0000000100220fd8 miniruby`rb_obj_class(obj=6171908688) at object.c:299:12 frame #5: 0x0000000100172218 miniruby`rb_hash_aset(hash=4367092992, key=6171908688, val=4367092800) at hash.c:2931:10 frame #6: 0x0000000100090a1c miniruby`compile_shareable_literal_constant(iseq=0x00000001043e10d0, ret=0x000000016fdfdad8, shareable=rb_parser_shareable_everything, dest=0x000000014c7c5468, node=0x000000014c7c5548, level=0, value_p=0x000000016fdfdac8, shareable_literal_p=0x000000016fdfdad4) at compile.c:10507:21 frame #7: 0x000000010007db5c miniruby`compile_shareable_constant_value(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, shareable=rb_parser_shareable_everything, lhs=0x000000014c7c5468, value=0x000000014c7c5548) at compile.c:10591:9 frame #8: 0x0000000100073e10 miniruby`iseq_compile_each0(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, node=0x000000014c7c5468, popped=0) at compile.c:10786:13 frame #9: 0x0000000100057354 miniruby`iseq_compile_each(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, node=0x000000014c7c5468, popped=0) at compile.c:10624:12 frame #10: 0x0000000100056f0c miniruby`rb_iseq_compile_node(iseq=0x00000001043e10d0, node=0x000000014c7c5578) at compile.c:919:13 frame #11: 0x00000001001b8cbc miniruby`rb_iseq_new_with_opt(ast_value=4366143936, name=4343347824, path=4343499984, realpath=4366954464, first_lineno=0, parent=0x0000000102e23a40, isolated_depth=0, type=ISEQ_TYPE_MAIN, option=0x000000016fdfe648, script_lines=4) at iseq.c:1011:5 frame #12: 0x00000001001b9230 miniruby`rb_iseq_new_main(ast_value=4366143936, path=4343499984, realpath=4366954464, parent=0x0000000102e23a40, opt=1) at iseq.c:915:12 frame #13: 0x000000010031715c miniruby`process_options(argc=0, argv=0x000000016fdff5d8, opt=0x000000016fdff0e0) at ruby.c:2627:20 frame #14: 0x0000000100316000 miniruby`ruby_process_options(argc=3, argv=0x000000016fdff5c0) at ruby.c:3169:12 frame #15: 0x00000001001260a8 miniruby`ruby_options(argc=3, argv=0x000000016fdff5c0) at eval.c:117:16 frame #16: 0x0000000100001940 miniruby`rb_main(argc=3, argv=0x000000016fdff5c0) at main.c:43:26 frame #17: 0x00000001000018cc miniruby`main(argc=3, argv=0x000000016fdff5c0) at main.c:68:12 frame #18: 0x0000000199240274 dyld`start + 2840 ``` I think the program is supposed to emit instructions that look like this: ``` $ ruby -v --dump=insns test.rb ruby 3.3.4 (2024-07-16 revision 425e468d25) [arm64-darwin23] == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(3,13)> 0000 putobject {nil=>{}} ( 3)[Li] 0002 dup 0003 putspecialobject 3 0005 setconstant :C 0007 leave ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120106] [Ruby master Bug#20931] Using `in` as an expression requires extra parentheses
by stephenprater (Stephen Prater) 05 Dec '24

05 Dec '24

Issue #20931 has been reported by stephenprater (Stephen Prater). ---------------------------------------- Bug #20931: Using `in` as an expression requires extra parentheses https://bugs.ruby-lang.org/issues/20931 * Author: stephenprater (Stephen Prater) * Status: Open * ruby -v: 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- TBH - I'm not sure if this is a bug or not - but it certainly surprising behavior and I'd at least like to understand it. Given a hash t - that can be pattern matched: `t = {a: 1, b:1 }` ``` ruby r = t in {a: 1, c:1 } # returns `false` r # {a: 1, c: 1} wat ``` Presumably this is because `=` binds higher than `in` - so that expression is equivalent to `(r = t) in {a: 1, c: 1}` But in that case - why does using the results of `in` require an additional set of parentheses to avoid a syntax error when the result of the expression is used as an argument to a method? ``` ruby puts(t in {a: 1, c: 1}) # syntax error puts((t in {a: 1, c: 1}) # false ``` Especially since this works fine: ``` ruby puts(case t; in { a: 1, c:1 }; true; else false; end) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120099] [Ruby master Feature#13512] System Threads
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #13512 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected maybe out of date ---------------------------------------- Feature #13512: System Threads https://bugs.ruby-lang.org/issues/13512#change-110846 * Author: magaudet (Matthew Gaudet) * Status: Rejected * Assignee: ko1 (Koichi Sasada) ---------------------------------------- In this feature I propose creating a VM implementation feature called (for lack of a better name) *System Threads*. Background ========== I am working on adding asynchronous compilation to [Ruby+OMR][1] allow compilation of methods to occur off the application thread, to avoid latency jumps when a method is selected for compilation. In the process of compiling Ruby, I really need to be able to call into the interpreter, to query for information about methods, and eventually I may even want to run small pieces of Ruby code (to fold constantes for example). I cannot call into the interpeter in any way without using a ruby level thread (required to acquire the GVL), and so, today, my implementation uses the existing Ruby thread API (`rb_thread_create`, `rb_thread_call_without_gvl2`, `rb_thread_call_with_gvl`). This approach largely works, and I am able to boot Discourse with the JIT + Async compilation enabled, thanks to [ko1][2]. [1]: https://github.com/rubyomr-preview/ruby/ [2]: https://bugs.ruby-lang.org/issues/13486 Unfortunately, I'm unable to pass `make test`, a curious situation. The issue is that because the compilation is a persistent `Thread`, there is some functionality that stops working (though, not enough to cause Discourse to fail). For example, the deadlock detection code tested by the following case no longer fires, and so a hang occurs: ``` assert_equal 'ok', %q{ begin Thread.new { Thread.stop } Thread.stop :ng rescue Exception :ok end } ``` This seems undesirable: The deadlock detection API is very useful, and I really don't want to neuter it by introducing a compilation thread. Hence the proposal for a System Thread. System Threads ============== I am proposing resolving the problem above by adding a new thread API: `VALUE rb_system_thread_create(VALUE (*)(ANYARGS), void*);`. Later extensions could provide a subclass of `Thread` called `SystemThread` however for now I consider that mildly out of scope. Here are the distinguishing features as I see them: * A Thread created through the System Thread API would not show up in `Thread::list` (though, if SystemThread is created, would show up in its list). * For the purposes of error reporting, System Threads would be resumed not to be partaking in user code. ie: * System threads aren't eligible to wake condition variables * System threads aren't enough to have the system able to make forward progresss. Potential Users: ---------------- In addition to JIT compilation threads, I see potential for other future consumers: * Concurrent garbage collection would likely need to take place on a System Thread to allow finalizers to run. * (Potential for misuse) one could imagine some libraries would want system threads. Other notes: ============ I took a little bit of time to try to implement System Threads, enough to realize that this wouldn't be a trivial implementation. There are a couple of different approaches I think that could be successful, but I didn't get deep enough into the thread code to have a strong intuition, and so I wanted to get feedback before going too far down this road. As a side note, I also attempted an alternative to System Threads for the purposes of the compilation thread: I used a native thread, then intended to spawn a Ruby thread only at the point where the JIT had a query: ``` # This was implemented using the C-API. def call_into_vm(query, arg) Thread.new { query(arg) }.value end ``` This was unsuccessful because creating a thread requires holding the GVL, but a native thread cannot acquire the GVL as near as I can tell. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120098] [Ruby master Feature#13388] gc.c: Add GC.get_parameters and .set_parameters
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #13388 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected Try with `GC.config` ---------------------------------------- Feature #13388: gc.c: Add GC.get_parameters and .set_parameters https://bugs.ruby-lang.org/issues/13388#change-110845 * Author: makimoto (Shimpei Makimoto) * Status: Rejected * Assignee: ko1 (Koichi Sasada) ---------------------------------------- These methods are for inspecting and modifying MRI's GC parameters. It may be useful for realtime parameter tuning with GC.stat, user requests and so on. This work is done by Tomohiro Moro (@slightair) and me (@makimoto). GH issue: https://github.com/ruby/ruby/pull/1572 We're trying this patch with our environments and report here. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111434] [Ruby master Feature#19261] `Data#members` is not important
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #19261 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19261: `Data#members` is not important https://bugs.ruby-lang.org/issues/19261 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- `Data#members` is defined but it is calculated by `self.class.members` (in other words, `#members` is a shorthand for `self.class.members`). So it is better to remove this method. ```ruby P = Data.define(:x, :y) p P.new(1, 2).members #=> [:x, :y] Group = Data.define(:name, :members) gs = Group.new('SasadaFamily', %w(ko1 yuki)) p gs.members #=> ["ko1", "yuki"] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:120096] [Ruby master Misc#16895] Request for cooperation: Try your applications/libraries with master branch and debug options
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #16895 has been updated by ko1 (Koichi Sasada). Status changed from Open to Closed https://github.com/ruby/setup-ruby has `debug` target. ---------------------------------------- Misc #16895: Request for cooperation: Try your applications/libraries with master branch and debug options https://bugs.ruby-lang.org/issues/16895#change-110843 * Author: ko1 (Koichi Sasada) * Status: Closed ---------------------------------------- ## Summary If you maintain a Ruby application or library, please consider testing with the Ruby `master` branch, including the *debug* build. This should be in addition to testing with all supported stable releases of Ruby. To make this easier, we are providing Docker images and GitHub actions, as outlined below. ## Details The rapid pace of Ruby development sometimes introduces bugs, such as incorrect behaviour or unexpected incompatibilities. Despite our best efforts and testing, without your feedback, we cannot catch every issue. Understanding how our changes impact downstream code is important feedback for the Ruby core developers. We want to know how your applications work on master. If you encounter an error when testing with the `master` branch (e.g. `[BUG] ...` in output log), [please report it](https://bugs.ruby-lang.org). It will be very helpful. ### Testing With `master` Testing using the `master` branch (sometimes referred to as `ruby-head`) will make your Ruby scripts ready for the next Ruby version. It also helps us catch incompatibilities as we change and evolve Ruby's public interface. ### Testing With Debug Build Testing with the master branch debug build enables many assertions within the Ruby interpreter. These assertions can detect incorrect usage of the C extensions, and also bugs in the interpreter when running your program. These assertions have an impact on the performance of the interpreter. To compile a debug build, refer the later section titled "Building With Debug Mode". ## Continuous Integration With `master` Building Ruby for your own testing environment can be difficult, so we are providing two convenient ways to use the master branch in your existing testing pipeline: - Docker Images - Github Action ### Docker Images The [rubylang docker repository](https://hub.docker.com/r/rubylang/ruby) provides images for various Ruby versions, including nightly builds of master with and without debug assertions" - Nightly built master: `rubylang/ruby:master-nightly-bionic` - Nightly debug built master: `rubylang/ruby:master-debug-nightly-bionic` Here is an example `Dockerfile`: ```dockerfile FROM rubylang/ruby:master-nightly-bionic ``` Then to build: ```shell $ docker build . Sending build context to Docker daemon 2.048kB Step 1/1 : FROM rubylang/ruby:master-nightly-bionic master-nightly-bionic: Pulling from rubylang/ruby ... Status: Downloaded newer image for rubylang/ruby:master-nightly-bionic ---> 059d367a8fbd Successfully built 059d367a8fbd ``` ### GitHub Action The [GitHub Action to setup Ruby](https://github.com/ruby/setup-ruby) provides both `ruby-head` and `ruby-debug` builds. Here is an example workflow to test on all Ruby stable releases, including `ruby-head` and `ruby-debug`: ```yaml name: Development on: [push] jobs: test: strategy: fail-fast: false matrix: os: [ubuntu] ruby: [2.5, 2.6, 2.7, head, debug] runs-on: ${{ matrix.os }}-latest continue-on-error: ${{ matrix.ruby == 'head' || matrix.ruby == 'debug' }} steps: - uses: actions/checkout@v2 - uses: ruby/setup-ruby@v1 with: ruby-version: ${{ matrix.ruby }} - run: bundle install - run: bundle exec rake ``` See the [documentation](https://github.com/marketplace/actions/setup-ruby-jruby-and-… for more details on how to use this action. ## Building With Debug Mode To create a debug build of Ruby, execute the following commands: ``` $ git clone https://github.com/ruby/ruby.git $ cd ruby $ autoconf $ cppflags=-DRUBY_DEBUG=1 ./configure --prefix=$HOME/.rubies/ruby-debug $ make install ``` If you are using `chruby`, you can switch to the above build: ``` $ chruby ruby-debug ``` You can find more details to build Ruby master in the [README](https://github.com/ruby/ruby/blob/master/README.md#how-to-compile-a…. ## Acknowledgement We thank @mrkn for the Docker image, @eregon for the GitHub Action, and @ioquatix for reviewing this announcement. -- https://bugs.ruby-lang.org/

1 0

[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