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(a)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.
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-limitat...
Thanks for working on this, Jun.
Regards,
Jarek
https://github.com/Shopify/yjit-bench
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(a)lists.fedoraproject.org
To unsubscribe send an email toruby-sig-leave(a)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.fed...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue