Issue #15289 has been updated by shevegen (Robert A. Heiler).


Sounds nice. Please do not forget documentation when/if approved/added. :)

I have no particular opinion on the API/name(s) as such, but I would recommend
to try to keep it simple and "logical" if possible. A Hash would probably make
the most sense, and the names for the parameters should ideally be the same, e. g.
if "lines:" is used, to also keep the same names whenever possible (both for
TracePoint, but also perhaps elsewhere in ruby if that is necessary; a bit
like how recently :exception was added to Kernel#system and other methods
there, like in the news entry for the upcoming 2.6.x xmas-release.

That is not necessarily an endorsement of the name "lines:" as such, mind
you; just more a general comment.

(I think the name "lines:" may not always be ideal, e. g. in the cases where
a ruby user may only want to add one breakpoint to a single line - but this
is mostly a detail, IMO. I am sure any fitting name can be derived when we
have some examples of how this is used. Ideally a short name if possible.)

----------------------------------------
Feature #15289: Accept "target" keyword on `TracePoint#enable`
https://bugs.ruby-lang.org/issues/15289#change-74813

* Author: ko1 (Koichi Sasada)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: 2.6
----------------------------------------
# Abstract

To enable TracePoint for specific location, I propose new keyword argument `target:` to `TracePoint#enable` for specific events (`line`, `call`, `return`, `class`, `end`).

Usage:

```
line_trace = TracePoint.new(:line){|tp|
  p tp
}

def foo
  p 1
end

line_trace.enable(target: method(:foo)) do
  foo
end
```

In this case, a line trace is enable only on the method `foo`.

`target:` keyword accepts `Method`, `UnboundMethod`, `Proc` and `RubyVM::InstructionSequence` (ISeq for short) . All of objects can pull ISeq objects.

Further more, I propose `target_lines:` keyword too, which specify effective line(s).

These features can improve "break point" feature and so on.

# Background

If we want to insert break point in Ruby's source code, we can use `TracePoint` (line event, for example). However, it enables all locations. It hurt performance.

This proposal overcomes this performance penalty.

# Implementation

Now basic design are completed in my mind :p

# Discussion

## line or lines

For breakpoint purpose, we only need to specify a line. Specifying lines is needed?

## no events on lines

It is not clear that if line is specified (for example: 10) and there are no line event (for example, empty line).

Possible options:

* (1) raise an exception
* (2) adjust before/after effective event
* (3) ignore

I prefer (1).

## no events in Proc

Similar to last topic, if we specify `call` event on `Proc` object, there are no `call` event. What happens?

## recursive or not

If method `foo` refers other blocks, I think we need to enable recursively. 

## how to get File target?

Sometimes we want to specify breakponit to the location specified by "file:line". How to get the lines?

https://github.com/ko1/iseq_collector provides the feature to collect all of ISeqs. debugger can collects all of them and debugger can filter with path name.

Also [Feature #15287] will help to hook not loaded locations.

## `enable` w/ keywords or other method name?

I have no strong opinion, but `TracePoint#enable_on(target, lines: ...)` is another idea?

# reference

Related: https://github.com/ruby/ruby/pull/2000

This implementation is based on `trace_` insn.




-- 
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>