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

[ruby-core:120126] [Ruby master Feature#18930] Officially deprecate class variables
by Dan0042 (Daniel DeLorme) 07 Dec '24

07 Dec '24

Issue #18930 has been updated by Dan0042 (Daniel DeLorme). I'm still against deprecating, either soft or hard, but I believe the errors could be improved. ```ruby class A def self.foo p @@foo ||= rand end end class B < A p @@foo = 2 end B.foo ``` In this code, the @@foo variable is overtaken but the "overtaken" error isn't triggered because even though the `foo` method is invoked on B, it was defined in A. If this could be improved to raise an error, I believe it might relieve some of the confusion over class variables. ---------------------------------------- Feature #18930: Officially deprecate class variables https://bugs.ruby-lang.org/issues/18930#change-110877 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- Ruby's class variables are very confusing, and it seem many people agree they should be avoided (#18927). How about we deprecate them officially? Concretely: * Mention in the documentation that class variables are deprecated and should be avoided/should not be used. * Add a parse-time deprecation warning, now that we only see those with `Warning[:deprecation] = true` it seems reasonable to add. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120124] [Ruby master Feature#18930] Officially deprecate class variables
by shan (Shannon Skipper) 07 Dec '24

07 Dec '24

Issue #18930 has been updated by shan (Shannon Skipper). Can we formally document they are soft deprecated or at least not recommended for use. In the Ruby community we often see new folk struggle greatly with them and have to recommend against their use over and over. ---------------------------------------- Feature #18930: Officially deprecate class variables https://bugs.ruby-lang.org/issues/18930#change-110875 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- Ruby's class variables are very confusing, and it seem many people agree they should be avoided (#18927). How about we deprecate them officially? Concretely: * Mention in the documentation that class variables are deprecated and should be avoided/should not be used. * Add a parse-time deprecation warning, now that we only see those with `Warning[:deprecation] = true` it seems reasonable to add. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118923] [Ruby master Bug#20690] URI.encode_www_form_component method escapes tilde when it's not supposed to
by y4m4p (Masahiro Yamashita) 06 Dec '24

06 Dec '24

Issue #20690 has been reported by y4m4p (Masahiro Yamashita). ---------------------------------------- Bug #20690: URI.encode_www_form_component method escapes tilde when it's not supposed to https://bugs.ruby-lang.org/issues/20690 * Author: y4m4p (Masahiro Yamashita) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin21] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ## Problem As the title says, `Uri.encode_www_form_component` is escaping tilde (`~`) where it should not according to the RFC3986. Ref: https://datatracker.ietf.org/doc/html/rfc3986#section-2.3 There was a previous issue with the same problem, https://bugs.ruby-lang.org/issues/6696 which has been resolved and merged. --- Since `URI.escape` is now obsolete and gone, the preferred way to escape URI characters are to choose from the following methods. - `URI.encode_www_form_component` (or, `URI.encode_www_form` which uses this) - `CGI.escape` - `ERB::Util.#url_encode` - `WEBrick::HTTPUtils.#escape_form` - `WEBrick::HTTPUtils.#escape` This issue does not occur when using any of the methods except `URI.encode_www_form_component`. These preferred options are not compatible with each other, making it a poor experience for Ruby users. ### Minimum replication ``` ruby # URI irb(main):002:0> require 'uri' => true irb(main):004:0> URI.encode_www_form_component("ruby~test") => "ruby%7Etest" # CGI irb(main):001:0> require 'cgi' => true irb(main):003:0> CGI.escape("ruby~test") => "ruby~test" # ERB irb(main):009:0> require 'erb' => true irb(main):012:0> ERB::Util.url_encode("ruby~test") => "ruby~test" # Webrick # needs webrick gem installed [3] pry(main)> require 'webrick' => true [4] pry(main)> WEBrick::HTTPUtils.escape_form("ruby~test") => "ruby~test" [5] pry(main)> WEBrick::HTTPUtils.escape("ruby~test") => "ruby~test" ``` ## Real world use-case problem I have a use-case problem with using URI when implementing a OIDC with PKCE client / server setup. When trying to generate a GET URI for Open ID Connect with PKCE, you need to provide a `code_verifier` value to the Authorization server, which actually requires you to use the tilde without escaping. Ref: https://www.oauth.com/oauth2-servers/pkce/authorization-request/ > When the native app begins the authorization request, instead of immediately launching a browser, the client first creates what is known as a “code verifier“. This is a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long. The inconsistent encoding is problematic for the Server and Client both, since both ends needs to have an agreement on using tilde as an escaped character or an unescaped character. Logically speaking, `~` should be sent AS-IS and not to be escaped, since the `code_challenge` value and `code_verifier` values are strictly checked using a Hash generation function `Digest::SHA256.digest`, which generates a different Hash value depending on `~`(non escaped) or `%7E`(escaped). These parameters from user inputs are usually not meant to be tampered with for security sake, so it's best to have tilde `~` to be unescaped from the beginning. ## Related issues - https://bugs.ruby-lang.org/issues/6696 - This seems to have been resolved and merged. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120087] [Ruby master Bug#20928] Current 3.4-dev cannot be built with jemalloc activated in macOS
by hachi8833 (Shozo Hatta) 06 Dec '24

06 Dec '24

Issue #20928 has been reported by hachi8833 (Shozo Hatta). ---------------------------------------- Bug #20928: Current 3.4-dev cannot be built with jemalloc activated in macOS https://bugs.ruby-lang.org/issues/20928 * Author: hachi8833 (Shozo Hatta) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Today I found that the current 3.4-dev is unable to build with jemalloc activated, while 3.3.4 or any lower versions can be build as usual with or w/o jemalloc activated. * macOS Sequoia: 15.1.1 (M3 Chip) * env (FYI: `--with-opt-dir=$(brew --prefix jemalloc)"` does not affect the result): ``` shell export RUBY_CONFIGURE_OPTS="--disable-install-doc --disable-shared --with-jemalloc --with-opt-dir=$(brew --prefix jemalloc)" export LD_PRELOAD=`jemalloc-config --libdir`/libjemalloc.dylib ``` * setup: ``` shell $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 16.1.0.0.1.1729049160 volume: / location: / $ brew --config HOMEBREW_VERSION: 4.4.9 ORIGIN: https://github.com/Homebrew/brew HEAD: 2e780004c92f16a96036d3d43569c2924c4e54f5 Last commit: 12 hours ago Branch: stable Core tap HEAD: 77f65298ec57b87241038503aabc6dfd1ead0497 Core tap last commit: 9 weeks ago Core tap JSON: 03 Dec 08:13 UTC Core cask tap JSON: 03 Dec 08:05 UTC HOMEBREW_PREFIX: /opt/homebrew HOMEBREW_CASK_OPTS: [] HOMEBREW_MAKE_JOBS: 8 HOMEBREW_NO_ENV_HINTS: set HOMEBREW_SORBET_RUNTIME: set Homebrew Ruby: 3.3.6 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.6/bin/ruby CPU: octa-core 64-bit arm_ibiza Clang: 16.0.0 build 1600 Git: 2.47.1 => /opt/homebrew/bin/git Curl: 8.7.1 => /usr/bin/curl macOS: 15.1.1-arm64 CLT: 16.1.0.0.1.1729049160 Xcode: N/A Rosetta 2: false ``` * build with 3.4-dev: ``` shell $ rbenv install 3.4-dev rbenv: /Users/hachi8833/.anyenv/envs/rbenv/versions/3.4-dev already exists continue with installation? (y/N) y ruby-build: using openssl@3 from homebrew ==> Cloning https://github.com/ruby/ruby.git... -> git clone --depth 1 --branch master https://github.com/ruby/ruby.git ruby-master Cloning into 'ruby-master'... remote: Enumerating objects: 12679, done. remote: Counting objects: 100% (12679/12679), done. remote: Compressing objects: 100% (10177/10177), done. remote: Total 12679 (delta 1499), reused 6014 (delta 1223), pack-reused 0 (from 0) Receiving objects: 100% (12679/12679), 16.82 MiB | 7.65 MiB/s, done. Resolving deltas: 100% (1499/1499), done. Updating files: 100% (11561/11561), done. ==> Installing ruby-master... -> autoreconf -i ruby-build: using readline from homebrew ruby-build: using libyaml from homebrew ruby-build: using gmp from homebrew -> ./configure "--prefix=$HOME/.anyenv/envs/rbenv/versions/3.4-dev" --with-openssl-dir=/opt/homebrew/opt/openssl@3 --with-readline-dir=/opt/homebrew/opt/readline --with-libyaml-dir=/opt/homebrew/opt/libyaml --with-gmp-dir=/opt/homebrew/opt/gmp --disable-install-doc --disable-shared --with-jemalloc --with-opt-dir=/opt/homebrew/opt/jemalloc -> make -j 8 BUILD FAILED (macOS 15.1.1 on arm64 using ruby-build 20241105-4-g87c272cd) ``` * detailed-log: ``` shell ... compiling gc.c gc.c:51:11: fatal error: 'malloc.h' file not found 51 | # include <malloc.h> | ^~~~~~~~~~ compiling hash.c compiling inits.c compiling io.c compiling marshal.c 1 error generated. make: *** [gc.o] Error 1 make: *** Waiting for unfinished jobs.... touch yjit/target/release/libyjit.a external command failed with status 2 ... ``` As far as I checked gc.c, at least `HAVE_MALLOC_USABLE_SIZE` and `HAVE_MALLOC_TRIM` directives are missing in 3.4-dev (see the attached). I hope these information would help resolve the issue 🙏 Thank you in advance, ---Files-------------------------------- 20241203_180021_r2uuD9.png (1.87 MB) -- https://bugs.ruby-lang.org/

3 2

[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) 04 Dec '24

04 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