[#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:106618] [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-11 09:57:35 UTC
List:
ruby-core #106618
Issue #16663 has been updated by headius (Charles Nutter).
Sorry I missed all discussions, this has been a pretty busy autumn.
> find_caller is going to find a single entry from call frames. Is it sufficient for OP's demand?
find_caller is one use case, and probably the most common use case. I model my proposal on the JDK 9+ "StackWalker" which simply takes a closure and passes you stack trace elements one at a time. As long as the walk is active you can consume as many or as few frames as you want.
However Java does not have a concept of returning from a closure. The closure always returns to its receiving method, so you have to decide up front what the receiving method will return. In this case, returning a single "found" stack frame would seem to be the most natural option. Supporting the return of both an array of elements and a found search in the same interface feels too confusing (and as @eregon pointed out in the PR, returning the array is wasteful if you only want to find one element).
I would like to see this feature happen in some way, but most of the use cases I considered will want to process and keep the top X frames, where X is variable at runtime depending on what was called (example: tests and specs that trim our their own internals and shorten the call stack; they do not know how many frames to skip so they request all of them just to ultimately keep N < all).
As it stands today, the only way to trim stack frames down to some search-based depth is to get them all and crop it after the fact.
Actually, a thought occurs reading through other comments...
From @zverok:
> Can't the specialized Enumerator be used for that?
From @eregon:
> Also in general we can't use Enumerable/Enumerator here...
This isn't quite correct. We can return a stack trace generator that acts like an Enumerable.
Enumerable is by default internal iteration, which is exactly what we want in this case: we can only iterate downstream from where we have requested a stack trace. The stack frames would be materialized lazily and passed via `each` to whatever Enumerable methods you used to filter it. If you have a straightforward case, it should still only cost as many frames as you actually want to see.
```ruby
Thread.each_backtrace.drop_while {|frame| test_library_frame?(frame)}
.keep_until {|frame| test_library_frame?(frame)}
```
This would perform the hypothetical test suite scrubbing out its own internal frames but keeping those relevant to the test itself. Once the `keep_until` failed, no more frames would be materialized and the slice of them would be returned.
Anything that turns it into an Array would force it to materialize all unfiltered frames, but filtered frames that don't need to be traversed won't be materialized. In most implementations it would also have to materialize once `each_backtrace` returns, since we'll start popping important frames at that point.
Of course this code also works with the current Array return value, but we have to populate the whole Array. Better would be a class that keeps its contents opaque until forced to materialize them, such as when forced into an Array or
Something like
```
class BacktraceWalker
include Enumerable
def initialize(live_trace)
@live_trace = live_trace
end
def each(&block)
return @live_trace.capture_trace(&block) # but internal so doesn't have to filter itself
rescue StopIteration
return $!.result
end
end
```
----------------------------------------
Feature #16663: Add block or filtered forms of Kernel#caller to allow early bail-out
https://bugs.ruby-lang.org/issues/16663#change-95288
* 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>