[#106355] [Ruby master Bug#18373] RBS build failure: '/include/x86_64-linux/ruby/config.h', needed by 'constants.o'. — "vo.x (Vit Ondruch)" <noreply@...>
Issue #18373 has been reported by vo.x (Vit Ondruch).
28 messages
2021/12/01
[ruby-core:106691] [Ruby master Feature#16663] Add block or filtered forms of Kernel#caller to allow early bail-out
From:
"headius (Charles Nutter)" <noreply@...>
Date:
2021-12-15 14:56:09 UTC
List:
ruby-core #106691
Issue #16663 has been updated by headius (Charles Nutter).
@jeremeyevans0:
> It sounds like you want iteration, and you are recommending with Thread.each_backtrace yielding Thread::Backtrace::Location objects. Is that correct?
Yes to iteration. Capturing a single frame is only one use case (and maybe not the most common). We should make it possible to capture multiple.
Thread.each_backtrace yielding Location objects would cover the use cases I am interested in, yes.
> While your Enumerable example would not work in CRuby, you may be able to do:
Yes I botched that part of my example. The Enumerable would have to be yielded to a block and used within that block. My example done right would be more like:
```ruby
Kernel.caller_locations do |enum|
enum.drop_while {|frame| test_library_frame?(frame)}
.keep_until {|frame| test_library_frame?(frame)}
.to_a
end
```
If the enum is used outside of this context, it would immediately error or StopIteration as it can no longer materialize lost frames. Some combination of Lazy and eager Enumerator logic could be used here to materialize required frames at the point that `caller_locations` returns.
Your example, with a simple `each_backtrace` does cover all the use cases I'm interested in, however. The only thing we lose over my version is the ability to apply other lazy Enumerator filtering in a more fluent style of code. My version would apply more naturally to the existing API, also, and would work the same for `caller`, `backtrace` and `*_locations` APIs.
----------------------------------------
Feature #16663: Add block or filtered forms of Kernel#caller to allow early bail-out
https://bugs.ruby-lang.org/issues/16663#change-95373
* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
----------------------------------------
There are many libraries that use `caller` or `caller_locations` to gather stack information for logging or instrumentation. These methods generate an array of informational stack frames based on the current call stack.
Both methods accept parameters for `level` (skip some number of Ruby frames) and `length` (only return this many frames). However many use cases are unable to provide one or both of these.
Instrumentation uses, for example, may need to skip an unknown number of frames at the top of the trace, such as to dig out of rspec plumbing or active_record internals and report the first line of user code. In such cases, the typical pattern is to simply request *all* frames and then filter out the one that is desired.
This leads to a great deal of wasted work gathering those frames and constructing objects to carry them to the user. On optimizing runtimes like JRuby and TruffleRuby, it can have a tremendous impact on performance, since each frame has a much higher cost than on CRuby.
I propose that we need a new form of `caller` that takes a block for processing each element.
```ruby
def find_matching_frame(regex)
caller do |frame|
return frame if frame.file =~ regex
end
end
```
An alternative API would be to allow passing a query object as a keyword argument, avoiding the block dispatch by performing the match internally:
```ruby
def find_matching_frame(regex)
caller(file: regex)
end
```
This API would provide a middle ground between explicitly specifying a maximum number of stack frames and asking for all frames. Most common, hot-path uses of `caller` could be replaced by these forms, reducing overhead on all Ruby implementations and drastically reducing it where stack traces are expensive.
--
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>