On Thu, Oct 27, 2022 at 4:14 PM Jarek Prokop <jpro...@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 <vondr...@redhat.com> > <vondr...@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/18481https://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.
_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
