[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:91298] [Ruby trunk Misc#15568] TracePoint(:raise)#parameters raises RuntimeError
From:
shevegen@...
Date:
2019-01-27 00:02:56 UTC
List:
ruby-core #91298
Issue #15568 has been updated by shevegen (Robert A. Heiler).
> Having the ability to get the parameters in a raise context would be very useful for debugging.
I agree. I can't say whether this means that trace.parameters exist but I agree that it may be
useful in debugging/introspection.
> I'm tempted to also suggest TracePoint#local_variables as it would provide additional context in a
> more exposed way than TracePoint#binding.eval('local_variables')
I can't say whether TracePoint#local_variables makes sense; but since the .eval() variant works,
I can see that it may just be a prettier and shorter name. I think it would be helpful to ask the
ruby core team about the API part here specifically, especially koichi and matz. I am not a big
user of TracePoint myself so I can not really speak about how useful it would be, but being able
to shorten the API and omitting eval, would seem ok to me. But perhaps others prefer eval(),
I don't know; eval() has a tiny bit of a hackish feeling to me personally though (I only mean
eval(), not the instance_eval() variants and the like). It seems an API consideration to me though
and a language designer's consideration (e. g. how matz would encourage ruby users to make
use of TracePoint; it's also a design decision what to enable or not to enable).
----------------------------------------
Misc #15568: TracePoint(:raise)#parameters raises RuntimeError
https://bugs.ruby-lang.org/issues/15568#change-76543
* Author: baweaver (Brandon Weaver)
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
Currently trying to get the `trace.parameters` of a method in a `raise` event will lead to a RuntimeError. I would contend that it should not, and that it would be perfectly valid to ask for the parameters in the case of an exception.
The reason I do this is to see the arguments at the time of exception:
```
def extract_args(trace)
trace.parameters.map(&:last).to_h do |name|
[name, trace.binding.eval(name.to_s)]
end
end
```
I've noticed that I can technically "cheat" and get these same values like this:
```
def extract_args(trace)
trace.binding.eval('local_variables').to_h do |name|
[name, trace.binding.eval(name.to_s)]
end
end
```
Having the ability to get the parameters in a `raise` context would be very useful for debugging.
I'm tempted to also suggest `TracePoint#local_variables` as it would provide additional context in a more exposed way than `TracePoint#binding.eval('local_variables')`
--
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>