[#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:87752] [Ruby trunk Feature#14888] Add trace point for eval (and related functions)
Issue #14888 has been updated by marcandre (Marc-Andre Lafortune).
You can already use `TracePoint` to "catch" the calls to eval:
```
TracePoint.trace(:c_call) do |tp|
if tp.callee_id == :eval
p "Eval called!"
end
end
```
This won't give you access to the arguments though. I'm not sure there's a good reason why the arguments are not available within a TracePoint of type `call` or `c_call`, that might be a good thing to propose if it hasn't already.
Not answering your question, but given this issue and #14889, you seem to want to use `TracePoint` as a code coverage tool. You may want to check out `DeepCover` instead. We're interested in supporting some templating tools out of the box (ERB, Haml, slim) and didn't really take the time to check how difficult that would be. I remember checking ERB's API; it is very crude and would not allow it (without redoing the ERB parsing ourselves).
----------------------------------------
Feature #14888: Add trace point for eval (and related functions)
https://bugs.ruby-lang.org/issues/14888#change-72777
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I'm working on an improved coverage library for Ruby which can compute coverage of things like ERB templates where the source file is not Ruby code but is translated to Ruby code using `eval`.
When using the line trace point, the path is the original template file (e.g. page.erb), which is problematic because this file isn't Ruby code nor do we generally know how to handle that file.
Ideally, we capture calls to `eval`, including the source, line number, and path, so we can match up with the path given by the line trace point and parse the correct source/ast.
In order to do that, it would be great to have a specific trace point for `eval` (and related functions). Ideally, the trace point would capture all the arguments to eval so they could be processed correctly. This would allow such coverage library to correctly find the right code/AST for a given file path.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>