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

[ruby-core:112368] [Ruby master Bug#19434] Fix YJIT compilation for Alpine Linux 3.17.2
by bkuhlmann (Brooke Kuhlmann) 14 Feb '23

14 Feb '23

Issue #19434 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19434: Fix YJIT compilation for Alpine Linux 3.17.2 https://bugs.ruby-lang.org/issues/19434 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Overview Hello. 👋 With the recent [Alpine Linux 3.17.2](https://www.alpinelinux.org/posts/Alpine-3.17.2-released.html) patch release -- which includes OpenSSL security patches -- I'm no longer able to build an Alpine Linux Docker image with YJIT enabled for Ruby. Prior to the 3.17.2 patch release, I could build Ruby + YJIT without issue. Here's the error I'm seeing when building locally: ``` #0 409.6 gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924 #0 409.6 Copyright (C) 2022 Free Software Foundation, Inc. #0 409.6 This is free software; see the source for copying conditions. There is NO #0 409.6 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #0 409.6 #0 409.7 compiling ./main.c #0 409.7 compiling dmydln.c #0 409.7 compiling miniinit.c #0 409.7 compiling dmyext.c #0 410.1 making dummy probes.h #0 410.2 compiling ast.c #0 410.7 compiling bignum.c #0 410.8 compiling class.c #0 411.8 compiling compar.c #0 414.1 compiling compile.c #0 414.9 compiling complex.c #0 421.0 compiling cont.c #0 421.7 In file included from cont.c:38: #0 421.7 yjit.h:24:3: error: #error YJIT unsupported platform #0 421.7 24 | # error YJIT unsupported platform #0 421.7 | ^~~~~ ``` ...but what I see in the `yjit.h` source code is: ``` // We generate x86 assembly #if defined(_WIN32) ? defined(_M_AMD64) : defined(__x86_64__) // x86_64 platforms without mingw/msys or x64-mswin #else # error YJIT unsupported platform #endif ``` ...so AMD 64 should still be supported. ## Steps to Recreate Probably the simplest way to recreate this, locally, is to use my Docker project: 1. Run: `git clone https://github.com/bkuhlmann/docker-alpine-ruby` 1. Run: `cd docker-alpine-ruby` 1. Edit the top of the `Dockerfile` so it says: `FROM bkuhlmann/alpine-base:2.0.3` (this ensures Alpine Linux 3.17.2 is being used). 1. Run `docker build --platform linux/amd64 .` 1. Wait for the build to fail. ## Environment **macOS** `macOS 13.2` **Docker** ``` Client: Cloud integration: v1.0.29 Version: 20.10.22 API version: 1.41 Go version: go1.18.9 Git commit: 3a2c30b Built: Thu Dec 15 22:28:41 2022 OS/Arch: darwin/arm64 Context: default Experimental: true Server: Docker Desktop 4.16.2 (95914) Engine: Version: 20.10.22 API version: 1.41 (minimum version 1.12) Go version: go1.18.9 Git commit: 42c8b31 Built: Thu Dec 15 22:25:43 2022 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.6.14 GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323 runc: Version: 1.1.4 GitCommit: v1.1.4-0-g5fd4c4d docker-init: Version: 0.19.0 GitCommit: de40ad0 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111899] [Ruby master Misc#19353] Drop gcc <= 6 and clang <= 9
by shyouhei (Shyouhei Urabe) 13 Feb '23

13 Feb '23

Issue #19353 has been reported by shyouhei (Shyouhei Urabe). ---------------------------------------- Misc #19353: Drop gcc <= 6 and clang <= 9 https://bugs.ruby-lang.org/issues/19353 * Author: shyouhei (Shyouhei Urabe) * Status: Open * Priority: Normal ---------------------------------------- We test those old compilers using Ubuntu bionic. This OS is reaching its EOL. Making them available would become harder. I would like to drop supporting them. Any opinions? -- https://bugs.ruby-lang.org/

4 4

[ruby-core:112245] [Ruby master Bug#19421] Distribution documentation
by ioquatix (Samuel Williams) 13 Feb '23

13 Feb '23

Issue #19421 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19421: Distribution documentation https://bugs.ruby-lang.org/issues/19421 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I use Ruby a lot, on a lot of different systems, and help people and companies use it, including developers who install it on their systems. Over time, I found that installing Ruby isn't always easy. Part of this is due to package management. There are many systems, and Ruby has had some tricky migrations (e.g. OpenSSL is probably one of the most painful ones that lots of developers have trouble with). Arch Linux has been stuck on Ruby 3.0 for a long time, which could be considered surprising given that Arch Linux is often on the bleeding edge of releases. I personally use Arch too. So I decided to ask, what is holding them up from making a release? I found out they had many questions about how to distribute Ruby correctly. When I listened to those questions I felt that there are many ambiguities in how we build and package Ruby for operating system packages. This isn't to say that there isn't a good way to do it, just that we as a core team might be able to improve our communication about how Ruby is evolving and the implications for package managers (if any). I've introduced `doc/distribution.md` as an effort to start having better documentation for people distributing Ruby. There are many ways which people distribute Ruby, and many "partial" documentation or assumptions being made about how to distribute Ruby and I'd like to provide a convenient standard location that can help people build package for Ruby distribution. Ultimately this makes my job easier because the latest versions of Ruby will be easier to install, so that's what I care about, but I don't care about what specifically is in the document, except that I think we should listen to the kinds of questions being asked and, in the best interest of Ruby, provide guidance. There was a lot of good discussion on the PR, but my goal is not to make a finished document, but instead plant the seed so it can grow. https://github.com/ruby/ruby/pull/6856 Some follow up discussion is required: - What is the best practice for building source packages. The documentation I wrote from this was removed as "out of scope" but I disagree with that (https://github.com/ruby/ruby/commit/c35ebed895e1a3f7bced3db50ea0db8f284744e8) I don't have a strong opinion about what it should look like, but I think we should give a clear example of how to build source packages like what I wrote. - Related to the above, what is the official location for source tarballs? - What optional dependencies are required for building vs distributing Ruby. Arch Linux currently lists: `doxygen gdbm graphviz libffi libyaml openssl ttf-dejavu tk` as dependencies but it's not clear if this list is up to date, or what the expectations are. When someone installs Ruby (e.g. `apt-get install ruby`) what dependencies should be installed? I think it would be helpful to list expected dependencies (from a system package POV), etc. - Is Ruby needed for building Ruby? Should source packages install Ruby before building from source? If so, what versions are supported? - Clear guidance on gems that are distributed an alongside Ruby, and how security changes to gems are managed. Even if we have more detailed documentation elsewhere, let's summarise it and then cross-reference it. People who build packages to distribute and install Ruby should feel supported, they are very important to our community. To this end, I established `#distribution` channel on Slack for discussion. We should listen to the questions being asked and use those questions to drive improvements to documentation. -- https://bugs.ruby-lang.org/

10 20

[ruby-core:112394] [Ruby master Feature#19107] Allow trailing comma in method signature
by k0kubun (Takashi Kokubun) 13 Feb '23

13 Feb '23

Issue #19107 has been updated by k0kubun (Takashi Kokubun). I second this proposal. `def foo(bar:,)` doesn't seem like a real use-case, but when a method has so many arguments and I declare arguments in multiple lines, I would love to put a trailing comma to minimize future git diff and make reviewing the Ruby code easier. For example, this is today's `ERB#initialize`: ```rb def initialize(str, safe_level=NOT_GIVEN, legacy_trim_mode=NOT_GIVEN, legacy_eoutvar=NOT_GIVEN, trim_mode: nil, eoutvar: '_erbout') # ... end ``` This line is still short enough to fit on my screen, however, if we were to add another option, e.g. `filename`, I would write: ```rb def initialize( str, safe_level=NOT_GIVEN, legacy_trim_mode=NOT_GIVEN, legacy_eoutvar=NOT_GIVEN, trim_mode: nil, eoutvar: '_erbout', filename: nil, ) # ... end ``` which doesn't seem awkward to me. But this is a SyntaxError today. If you don't put a `,` there, you'll see a diff on `filename` when you add another option after that even if the patch is not related to `filename`, which would make me frustrated when reviewing that code. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-101836 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112393] [Ruby master Feature#19107] Allow trailing comma in method signature
by rubyFeedback (robert heiler) 13 Feb '23

13 Feb '23

Issue #19107 has been updated by rubyFeedback (robert heiler). To me the ',' there looks rather awkward. Then again the first time I saw def(foo:) I was also confused. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-101835 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111712] [Ruby master Feature#19322] Support spawning "private" child processes
by kjtsanaktsidis (KJ Tsanaktsidis) 13 Feb '23

13 Feb '23

Issue #19322 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #19322: Support spawning "private" child processes https://bugs.ruby-lang.org/issues/19322 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- ## Background The traditional Unix process APIs (`fork` etc) are poorly isolated. If a library spawns a child process, this is not transparent to the program using the library. Any signal handler for `SIGCHLD` in the program will be called when the spawned process exits, and even worse, if the parent calls `Process.waitpid2(-1)`, it will consume the returned status code, stealing it from the library! Unfortunately, the practice of responding to `SIGCHLD` by calling `waitpid2(-1)` in a loop is a pretty common unixism. For example, Unicorn does it [here](https://yhbt.net/unicorn.git/tree/lib/unicorn/http_server.rb#n401). In short, there is no reliable way for a gem to spawn a child process in a way that can’t (unintentionally) be interfered with by other parts of the program. ## Existing solutions in OS’s Several operating systems provide an improved API for spawning child processes which are fully isolated; that is, they do not generate `SIGCHLD` signals in the program, and are invisible to calls to `waitpid(2)` * On Linux, such invisible processes can be made by calling `clone(2)` with a zero value in the low byte of `flags`. If the CLONE_PIDFD flag is also provided, then a file descriptor representing the process is also returned; this can be used to wait for and signal the process in a race-free way. * On FreeBSD, the `pdfork(2)` syscall makes a process that does not signal SIGCHLD and is ignored by `waitpid(2)` calls that do not explicitly specify the pid (i.e. it is ignored when -1 is passed). It also returns a file descriptor representing the process. Both of these APIs center around the idea of a process file descriptor. Rather than managing a child process using the old process-global wait/signal mechanisms, they return a file descriptor representing the process. Such a file descriptor can uniquely identify the spawned process, be used to wait on the process and get the status, send signals, and even participate in `poll(2)`. They also protect against pid-reuse race conditions; after a process has terminated and been reaped, the pidfd becomes invalid, and can’t randomly begin to refer to a different process. ## Proposed Ruby APIs I think we should make a new API `Process.spawn_handle`, which accepts all the same parameters as `Process.spawn`. However, it does _not_ return a pid like `Process.spawn`, but rather a new type `Process::Handle`. `Process::Handle` would identify a single spawned process, using a durable OS-supplied handle not subject to re-use risks (e.g. a pidfd). It would provide the following methods: * `#pid` - get the pid that the handle is for. * `#send_signal(signal)` - send a signal to the wrapped process (where "signal" is a symbol, string, or number with the same meaning as in `Process.kill`. * `#wait` - blocks waiting for the program to exit, and then returns a `Process::Status` object representing e.g. the exit code. Like calling `waitpid`. * `#wait_nonblock` - Returns a `Process::Status` object for the child process. If the child has not exited, it will be a status object for which `#exited?` is false. Does not block. Like calling `waitpid(WNOHANG)`. Finally, the `Open3` family of methods would be extended to accept `handle:` as an additional keyword argument. When set to true, `Process.spawn_handle` will be used to start the child, and `Process::Handle` objects will be returned in place of pids. Modifying backticks, `Kernel#system` and other process-creating methods which don't return pids to use `spawn_handle` internally would also be possible, but out of scope for an initial implementation of this ticket. ## OS compatibility For this API to be useful to gem authors, it has to be widely available on the systems that they and their users care about. As discussed, the `clone(2)` syscall and `CLONE_PIDFD` flag can be used on Linux 5.2+ to implement `Process::Handle`. FreeBSD has `pdfork(2)` since v9. I haven’t investigated Windows _deeply_, but I think Windows doesn’t really have the notion of process-global `waitpid` or `SIGCHLD` anyway. The `CreateProcess` function returns a `PROCESS_INFORMATION` struct, which returns a `HANDLE` for the child process, which seems analogous to a process FD. However this does leave a large chunk of operating systems which don’t have this functionality built-in. Off the top of my head: * MacOS, NetBSD, and OpenBSD have nothing. I stared pretty hard at the Darwin XNU source and couldn’t find a race-free way to convince it not to dispatch `SIGCHLD` for a particular process or stop it from being reaped by process-wide `wait4` calls. * Linux < 5.2 is in some probably-pretty-widely-deployed-still distros - it’s the release kernel in Ubuntu 18.04 for example. I have two ideas for how the semantics of `Process::Handle` could be emulated on such systems. However I recognise that they aren’t amazing so if anybody has some better ideas I would dearly love to hear them. ### Long-lived proxy The first time `Process.spawn_handle` is used, we would fork/exec a long-lived “fork-helper” program. This could be a separate helper binary we compile with the build system, or perhaps just a re-invocation of the ruby interpreter with something like `ruby -e “Process._fork_helper”`. There would be a unix socketpair shared between the parent process & the helper. Instead of actually forking when we’re calling `Process.spawn_handle`, we would instead send a message on this socket asking the helper to, _itself_, fork & exec the specified program. Any file descriptors etc needed in the child could also be sent over this socket. All of the `Process::Handle` methods would be proxies which called through to the helper binary. This way, the ruby process is never actually the parent of the spawned child, so we would never get any SIGCHLD etc from it. The fork-helper program might generate a SIGCHLD, but it should persist until the ruby process exits; we would only generate a SIGCHLD signal if it crashed abnormally. ### Forward misdirected waits With this approach, `Process.spawn_handle` would just `fork(2)`/`exec(2)` or `posix_spawn(2)` processes like normal. We would however keep a table of pids -> `Process::Handle` instances. When Ruby’s C-level SIGCHLD handler is invoked, we would inspect that table and see if the pid has an associated `Process::Handle`. If so, we would skip calling any registered Ruby SIGCHLD handler; instead, we would call `waitpid` ourselves, update the status info on the handle object, and unblock anybody waiting on `Process::Handle#wait`. Likewise, in the C-side implementation of `Process.waitpid2` etc, we would check the returned pid from the syscall against the handle table. If it matched, we would perform the same work as in the SIGCHLD case, and then re-start the original call to `Process.waitpid2`. This approach keeps the process tree correct and involves less silly proxying, but it won’t hide the process from any callers to the raw `waitpid` library functions in C extensions. Doing that seems like a silly idea anyway though, so maybe that’s OK? ## Motivation My use-case for this is that I’m working on a perf-based profiling tool for Ruby. To get around some Linux capability issues, I want my profiler gem (or CRuby patch, whatever it winds up being!) to fork a privileged helper binary to do some eBPF twiddling. But, if you’re profiling e.g. a Unicorn master process, the result of that binary exiting might be caught by Unicorn itself, rather than my (gem | interpreter feature). In my case, I'm so deep in linux specific stuff that just calling `clone(2)` from my extension is probably fine, but I had enough of a look at this process management stuff I thought it would be worth asking the question if this might be useful to other, more normal, gems. -- https://bugs.ruby-lang.org/

4 13

[ruby-core:111194] [Ruby master Feature#19179] Support parsing SCM_CRED(ENTIALS) messages from ancillary messages
by kjtsanaktsidis (KJ Tsanaktsidis) 13 Feb '23

13 Feb '23

Issue #19179 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #19179: Support parsing SCM_CRED(ENTIALS) messages from ancillary messages https://bugs.ruby-lang.org/issues/19179 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- ## Background Linux and FreeBSD support processes at either end of a unix socket identifying themselves to the other party by passing an ancillary message of type `SCM_CREDENTIALS` (Linux) or `SCM_CREDS` (FreeBSD). The socket library contains code to parse these ancillary messages, but the only way this is exposed into Ruby code is by the `Socket::AncillaryData#inspect` method - e.g. ``` # On Linux irb(main):002:0> s1, s2 = UNIXSocket.pair => [#<UNIXSocket:fd 5>, #<UNIXSocket:fd 6>] irb(main):004:0> s2.setsockopt Socket::SOL_SOCKET, Socket::SO_PASSCRED, 1 => 0 # struct ucred on Linux is (32-bit signed) pid_t, followed by (32-bit unsigned) uid_t, followed by # (32-bit unsigned) gid_t irb(main):008:0> ancdata = [Process.pid, Process.uid, Process.gid].pack("lLL") => "\x1ET\x05\x00\xE8\x03\x00\x00\xE8\x03\x00\x00" # Socket::AncillaryData knows how to unmarshal the data into struct ucred irb(main):010:0> ancmsg = Socket::AncillaryData.new(Socket::AF_UNIX, Socket::SOL_SOCKET, Socket::SCM_CRE DENTIALS, ancdata) => #<Socket::AncillaryData: UNIX SOCKET CREDENTIALS pid=349214 uid=1000 gid=1000 (ucred)> irb(main):011:0> s1.sendmsg "hi", 0, nil, ancmsg => 2 # ancillary message can be passed through irb(main):012:0> _, _, _, recvanc = s2.recvmsg; recvanc => #<Socket::AncillaryData: UNIX SOCKET CREDENTIALS pid=349214 uid=1000 gid=1000 (ucred)> ``` On Linux, at least, a suitably privileged process can send any value through for the pid, uid, or gid, but the kernel will reject attempts by unprivileged processes to forge credentials in this way. So SCM_CREDENTIALS messages can be useful for certain systems programming tasks. A somewhat wider array of operating systems support querying the identity of the other side of a socket using a socket option, variously `SO_PEERCRED` (Linux, OpenBSD) or `LOCAL_PEERCRED` (FreeBSD, MacOS). Again, the socket library is able to unmarshal the socket data into the correct structure on these various systems, but it's only exposed to Ruby code via `#inspect` - e.g. ``` irb(main):002:0> s1, s2 = UNIXSocket.pair => [#<UNIXSocket:fd 5>, #<UNIXSocket:fd 6>] irb(main):014:0> s1.getsockopt Socket::SOL_SOCKET, Socket::SO_PEERCRED => #<Socket::Option: UNIX SOCKET PEERCRED pid=349214 euid=1000 egid=1000 (ucred)> ``` Ruby _does_ however support e.g. `BasicSocket#getpeereid`, which could use `SO_PEERCRED` etc under the hood - so getting the uid/gid data is not totally impossible. I believe getting the pid is though. ``` irb(main):016:0> s1.getpeereid => [1000, 1000] ``` ## My proposal I believe we should implement the following: * `Socket::Credentials` - this would be a struct which can contain all the various platform-specific pieces of credential info that can be transferred over a socket, such as uid, gid, pid, euid, egid, and group list. * `Socket::AncillaryData#credentials` - this would parse an `SCM_CREDS` or `SCM_CREDENTIALS` ancillary data message into the appropriate platform-specific struct, and return a `Socket::Credentials` instance containing that data. This would be analogous to `Socket::AncillaryData#int`; a method for interpreting the ancillary data in a certain form. * `Socket::Option#credentials` - This would parse a `SO_PEERCRED` or `LOCAL_PEERCRED` socket option response into the appropriate platform-specific struct, and return a `Socket::Credentials` instance containing that data. Again, this would be analogous to `Socket::Option#int`. The existing `struct ucred`/`struct xucred`/`struct sockpeercred`/`struct cmsgcred` parsing code (used only for `#inspect` output) would be moved into `Socket::Credentials`, and `Socket::AncillaryData#inspect`/`Socket::Option#inspect` would be implemented in terms of `Socket::Credentials`. This would nicely wrap a lot of parsing work that Ruby is already doing, into an API which allows Ruby code to take advantage of it. ## Use-cases My motivation for designing this feature came about whilst I was experimenting with some ideas for Ruby profilers. I wanted to allow a CLI tool to ask a Ruby process to start profiling itself by sending a message on a unix socket. Alongside the message, it would send a file descriptor which was the result of calling `perf_event_open(2)` in the CLI tool. In order to call `perf_event_open(2)`, the CLI tool would need to be privileged. I also wanted the Ruby process to authenticate the request and make sure it came from the same UID that it was running as. Calling `BasicSocket#getpeereuid` would reveal the remote process to be running as UID 0, (or perhaps even some other UID, with sufficient ambient capabilities to call `perf_event_open`). Instead, I decided to make the CLI tool send a `SCM_CREDENTIALS` message containing the uid of the process to be profiled; that way, the kernel does all the policy checking on whether or not this is actually allowed, and the Ruby process receiving the message just needs to check if `uid == Process.getuid`. I think, on Linux at least, that this feature will be useful for any kind of communication/authentication scheme between privileged & unprivileged processes over unix sockets. ## My implementation I have an implementation of roughly this in this pull request: https://github.com/ruby/ruby/pull/6822 Thanks! -- https://bugs.ruby-lang.org/

3 4

[ruby-core:111614] [Ruby master Feature#19306] Expand zlib interface
by ioquatix (Samuel Williams) 13 Feb '23

13 Feb '23

Issue #19306 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19306: Expand zlib interface https://bugs.ruby-lang.org/issues/19306 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- Introduce some extra methods like `window_size`, `level` (compression/decompression), enhance `inspect` and various other quality of life improvements. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112381] [Ruby master Misc#16895] Request for cooperation: Try your applications/libraries with master branch and debug options
by rubyFeedback (robert heiler) 12 Feb '23

12 Feb '23

Issue #16895 has been updated by rubyFeedback (robert heiler). As I got older (it has been almost 20 years now since I have been using ruby, and I feel physically older too compared to the more young-version of me back in the days), my focus has shifted a bit. I was super-experimental when I was younger. Nowadays I try to stay with stable ruby releases whenever possible. So the xmas-release is usually when I switch; I do tend to switch as quickly as possible, to avoid any legacy-drag that we had from e. g. ruby 1.8.x to 1.9.x to 2.x and beyond. I am kind of like "an early adopter of stable ruby", if that makes sense. :D I can still find some issues here and there and report it. Testing unstable is a bit of an issue and hassle, though. I wrote a lot of ruby scripts over the years, and ruby is used to maintain my whole linux system (I compile from source whenever possible); so getting the new git release of ruby is as simple as doing "ry ruby --gitty" for me. That will download the latest git sources, re-package them into .tar.xz and put it into $SRC_DIR/ruby/. I can even automatically compile it too. So this is actually the simple part. The bigger issue is time investment, and forgetting it. I kind of adjusted mentally to be lazy, so I download the latest ruby on xmas and then keep on using it, until the next xmas. So I rarely get to test new features, unless they are interesting. I don't have a good alternative model. Would be interesting if we could have ruby so modular that there be tons of ruby dialects, and we could test each dialect in the "middle of the year", just recompiling parts of ruby that would be affected (e. g. like when pattern matching was added. Imagine if we could have a toggle for all of ruby behaviour, a bit like we can specify the linux kernel). ---------------------------------------- Misc #16895: Request for cooperation: Try your applications/libraries with master branch and debug options https://bugs.ruby-lang.org/issues/16895#change-101823 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- ## 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:112380] [Ruby master Misc#16507] =~ vs include? or match?
by rubyFeedback (robert heiler) 12 Feb '23

12 Feb '23

Issue #16507 has been updated by rubyFeedback (robert heiler). I can't speak for the ruby core team, but here is my rule-of-thumb in my own ruby code "bases" out there. I usually try to stick with the simplest choice possible, which in many ways is .include?() for me. Sometimes this is not possible, though, such as when the input is not so simple (e. g. where a regex is more appropriate such as /\d{0,6}\.\d{3,6}/ like when the input can vary). Regexes are great in ruby; I think matz liked them from the perl days. :) I almost never use .match() or .match?() - and I think these are also rare in other people's code bases out there. I tend to use methods ending via "?" a lot. It is a bit like DSL-design for me: if object.can_do_this? or object.can_do_that? end I think it reads very nice. That is actually my recommendation too - if you feel the readability is improved then use the methods. The method .ci?() seems a bit short-ish. I would recommend against such short method names; they rarely seem to improve a lot. I tend to use them mostly when I need to do things where being succinct is important. .mswin?() makes more sense. Even then I would perhaps consider using two words, if that makes sense for the code you are working with. In my opinion, when it really helps you maintain the code, and when it leads to some clarity, using helper-methods is a good idea. Perhaps if you want some more feedback from ruby core devs, it may help if you could give a few more specific examples so they can look at the instances where you thought that removing =~ would be a good idea. Sometimes different ruby developers have a different focus and priority for using certain constructs in their code. For me my own code is very simple and readable, but I am sure for others it can be very messy and unreadable (I try to stick to simplicity at all times and avoid too complicated constructs; for instance I never use "->" and other things, but I use blocks a LOT, so my code will have tons of "if block_given?; yield = yielded" just to keep on working with the variable. Blocks are great). ---------------------------------------- Misc #16507: =~ vs include? or match? https://bugs.ruby-lang.org/issues/16507#change-101822 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal ---------------------------------------- While working on getting the mswin build working on Actions, I thought adding mswin? and ci? methods to Minitest::Unit::Guard in tool/lib/minitest/unit.rb would be helpful. Currently some tests are failing that are guarded/skipped based on ENV['APPVEYOR']. For ci?, I'd combine Travis, AppVeyor, & Actions. There are quite a few instances where =~ is used for a boolean return. Would it be considered appropriate to replace those calls with include? or match? -- https://bugs.ruby-lang.org/

1 0