[#81492] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — normalperson@...
Issue #13618 has been reported by normalperson (Eric Wong).
12 messages
2017/06/01
[#88695] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/27
> https://bugs.ruby-lang.org/issues/13618
[#81569] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
3 messages
2017/06/04
[#81581] [Ruby trunk Bug#13632] Not processable interrupt queue for a thread after it's notified that FD is closed in some other thread. — sir.nickolas@...
Issue #13632 has been reported by nvashchenko (Nikolay Vashchenko).
4 messages
2017/06/05
[#81590] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures. — Eric Wong <normalperson@...>
ko1@ruby-lang.org wrote:
5 messages
2017/06/06
[#81591] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81596] Re: [ruby-cvs:66203] Re: Re: ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81825] [Ruby trunk Feature#13697] [PATCH]: futex based thread primitives — normalperson@...
Issue #13697 has been reported by normalperson (Eric Wong).
3 messages
2017/06/29
[ruby-core:81509] [Ruby trunk Feature#13620] Simplifying MRI's build system: always install
From:
eregontp@...
Date:
2017-06-01 15:26:44 UTC
List:
ruby-core #81509
Issue #13620 has been updated by Eregon (Benoit Daloze). naruse (Yui NARUSE) wrote: > I object this. > > You are counting only full build. Actually the numbers above are for building just after a pull. And if any file is touched, it takes longer than install-nodoc. > But on developing, you need to compare with null build. > > On such case almost all libraries are already build and the build time is much shorter. > > Therefore when I am developing ext/ libraries, adding install-nodoc doubles the build-install time. How much is it? 6s instead of 3s? Probably this depends a fair amount on disk speed. I have a small bcache SSD. Times are better on a true SSD. Maybe we should install to /tmp :D Here are my numbers for a null build: $ time make -j 8 all make -j 8 all 3.24s user 0.53s system 364% cpu 1.034 total $ time make -j 8 all install-nodoc make -j 8 all install-nodoc 3.56s user 0.58s system 262% cpu 1.580 total While it is more, I cannot really feel the difference. Changing anything in my editor takes much longer than that. Running the tests for the relevant extension also takes a while. ---------------------------------------- Feature #13620: Simplifying MRI's build system: always install https://bugs.ruby-lang.org/issues/13620#change-65216 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Hello all, I've been bitten recently when modifying ruby/spec or in #13570 by the sheer number of different configurations to build and test in MRI. Currently, I know 4 of them, and I can tell you it is a big headache to make it work on all of them: * in-source-dir build, running tool/runruby.rb * in-source-dir build, running the installed ruby * out-of-source build, running tool/runruby.rb * out-of-source build, running the installed ruby I just compiled latest MRI this morning, and here are the times: * time make -j 8: make -j 8 373.22s user 30.88s system 404% cpu 1:39.99 total * time make -j 8 install-nodoc make -j 8 install-nodoc 3.29s user 0.55s system 259% cpu 1.477 total So I am wondering, should we just test with the installed ruby since installing it takes only marginally more time than building? The current complexity of runruby.rb, the generated ./rbconfig.rb, etc, all to support testing from the built ruby seems not worth it. It also means all the tests need to accommodate this different layout and are essentially testing a ruby layout that nobody uses in production. On the other hand, testing the installed ruby would test something which is much closer to what is released and used in production, and massively simplify the setup to test by making installed layout assumptions hold (e.g.: RbConfig.ruby points to the current ruby and ruby needs no flags to execute correctly). Did I miss something? I also wish we could choose one of in-source/out-of-source and not having to support both, but let's talk about make/make install first. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>