On Thu, Oct 27, 2022 at 4:14 PM Jarek Prokop <jprokop@redhat.com> wrote:

Hi,

On 10/27/22 15:14, Jun Aruga (he / him) wrote:
On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruch <vondruch@redhat.com> wrote:
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,

Here is yet another version from Friday:

https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738

Nothing really special from Ruby POV, but I have enabled
out-of-source build, as was previously discussed here:

https://src.fedoraproject.org/rpms/ruby/pull-request/120

https://src.fedoraproject.org/rpms/ruby/pull-request/122

So while this should not have any influence on resulting package, it
might come handy when somebody wants to clean the source tree and
play with e.g. different configuration options or what not.


Vít

Thank you.

By the way, do you have some plan to bring ruby 3.2 development rpm to
f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
Thanks for the work.
I am trying to build on the private-ruby-3.2 branch.
Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ?
Could you share?

I have been testing Ruby 3.2.0 preview2. The outcome is below.
https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/

## WebAssembly support

This is one of the new features in Ruby 3.2.0, and that is to build a
Ruby source for the WebAssembly target, and then run a Ruby code on
the Ruby on the Web Assembly runtime.
But this feature is exclusive from the current Ruby in the Ruby RPM.
When building Ruby for that, we can not run the Ruby without the
WebAssembly runtime.
So, I think it's not realistic to include the feature in the Ruby RPM.

I do not think any distribution will be able to reasonably support this.

From my understanding of WASM, it is required to crosscompile everything needed to run the application,
so that it is usable in browser or other WASM runtimes.

It is a feature that upstream supports, which is nice from language usability perspective, but not something we are able to or want to reasonably support.
Those who want to use it, need to crosscompile whole Ruby from source, as is the case with any other C application.

Or, such people can download the .src.rpm unpack it and adjust the specfile to match their needs.

I think it is comparable to mruby (the lightweight embeddable ruby): https://github.com/mruby/mruby
These kinds of applications are better fine tuned by app developers themselves than the Linux distribution packagers.


Hi Jarek,
Thanks for sharing the info. For the mruby, in the past I developed an iOS application on iPad and iPhone. In the application build process, I built an Objective-C app with C or C++ library sources. The libraries are managed as static libraries. So, I guess the mruby's case is something like this. For the WASM, the application developers can build the Ruby with the WASM target when building their applications.
 

See devel@ mailing list - Subject: "Packaging a cross-compilation
environment (wasi-libc)" for details.

## Regexp timeout

I found a small issue on a new feature. Then it was fixed.
https://bugs.ruby-lang.org/issues/19055

## YJIT support

YJIT is to improve the performance of Ruby code by using Rust. It's
like MJIT (previously called JIT) by using gcc or clang.

I think adding this feature in the Ruby RPM is realistic. So, I tested
this feature with the upstream Ruby source code in some cases.

Because in my understanding the YJIT is only available with the `ruby
--yijt` option. It seems that it doesn't affect the current Ruby
features. Possibly we need to add "BuildRequires rust cargo", and also
needs a dependency rust (and cargo?) to run the `ruby --yjit`.

```
$ ./configure --enable-yjit ...
$ make
$ make install

$ ruby --help
...
Features:
  gems            rubygems (only for debugging, default: enabled)
...
  mjit            C compiler-based JIT compiler (default: disabled)
  yjit            in-process JIT compiler (default: disabled) # <=
This line appears. And this feature is only enabled with the `ruby
--yjit`.
...

$ ruby --yjit my_script.rb
```

See the following links for details.
https://bugs.ruby-lang.org/issues/18481
https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#installation

I read that document, we should only need the `%{_bindir}/rustc`. Ruby upstream was successful in keeping the
production version without any external dependencies apart from base Rust libraries AFAICT.

At least that's what I understood from requirement: `... and Cargo (if you want to build in dev/debug mode)`
This to me implies that cargo is only needed for dev/debug mode, which is not needed for Ruby distributed in Fedora IMO.

Another downside of yjit is that it is currently only x86_64 and aarch64 AFAICT. https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#current-limitations

Thanks for working on this, Jun.


Thanks for your input. I will create a pull-request to the private-ruby-3.2 branch to add the YJIT feature.

Jun

--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for the timezone.