[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
[email protected] wrote:
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
QXMgSSB0b2xkIHlvdSwgYG1ha2UgaW5zdGFsbGAgaXMgbmVlZGVkIHRvIG1ha2UgUnVieSB3b3Jr
T25lIG1vcmUgcmVhc29uIGZvciBodHRwczovL2J1Z3MucnVieS1sYW5nLm9yZy9pc3N1ZXMvMTM2
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
[email protected] wrote:
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
[email protected] wrote:
> yet, sky3 had a failure at
> http://ci.rvm.jp/results/trunk@P895/1173951
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:87876] [Ruby trunk Feature#13620] Simplifying MRI's build system: always make install
Issue #13620 has been updated by Eregon (Benoit Daloze). @normalperson wrote in ruby-core:87864: > mkmf works fine with everything in ext/ without install, so I > expect mjit to work, too. I will let Nobu figure it out. FWIW, mkmf.rb is a famous example for terrible hacks to accommodate the build layout :p There is this $extmk global variable and ~20 conditions based on it in lib/mkmf.rb which makes the code unreadable and fragile. Due to that, running mkmf.rb needs more hacks for testing in tree (and shows confusing behavior without it): https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/spec/ruby/optional/capi/spec_helper.rb#L3-L4 There is even a hook on the global variable, which executes all sort of things on the first assignment, regardless of the value set: https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/tool/fake.rb#L37-L70 I think one solution here is to make building in-tree C extensions more similar to external C-extensions. It's basically what TruffleRuby does, for openssl/zlib/syslog/psych and $extmk is just always `false`. ---------------------------------------- Feature #13620: Simplifying MRI's build system: always make install https://bugs.ruby-lang.org/issues/13620#change-72889 * 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:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>