What is the code point for runtime.(i)? about bisect_ppx HOT 6 CLOSED

It looks like identifier is simply the value of the point's index i. It's just a way to get the index of a code point, given only the point_definition record, without doing a search in the points list. So, the answer to

what is the corresponding code point? Is it the one with identifier i or the one at index i in the list of code points?

is "both."

The naming of the field is confusing though, and the comment is not very helpful. We should fix that.

As for the type definitions, I agree it would make it clearer to understand what is really going on. Both the runtime data and the code point lists (i.e. .cmp files) could use clear type definitions. I'll submit a PR – unless you would like to :)

from bisect_ppx.

Thanks for the clarification. I haven't looked at this but I would try to get rid of this redundancy by removing the identifier field as there is the danger of inconsistencies. I'm currently working towards a more abstract interface to the runtime system but it has some parts that you are probably not going to be interested in: I want line numbers for each point. It looks like this and does not rely on array indices as they entire structure is tree shaped.

module SM: Map.S with type key = string

exception Error of string

type point = (** a code point in a source file *)
  { line:         int           (** line number *)
  ; offset:       int           (** byte offset from start *)
  ; kind:         Bisect.Common.point_kind  (** kind of point *)
  ; count:        int           (** number of hits *)
  }

type file = (** a file with coverage analysis *)
  { digest:       string        (** cryptographic hash of content *)
  ; linecount:    int           (** number of lines *)
  ; points:       point array   (** points that were covered *)
  }

type t = file SM.t              (** a collection of files *)

val read: string -> string list -> t

The read function takes the prefix directory and a list of *.out files and builds a map that for each file has all the points and the number of hits.

from bisect_ppx.

The interface looks good in principle – not sure if you are still working on it. Line numbers may be fine if they simplify some useful processing, which is, I'm sure, why you're adding them. The existing offsets are weird, but I guess they are useful to how the HTML reporter works right now.

How would your desire to add line numbers be affected by storing the source code and point info together in the .out files?

from bisect_ppx.

The reason why I want to support line numbers is that this is what editors and users understand best for navigating to a point. I've implemented them by scanning the source code and remembering all offsets of the newlines in the file. Given an offset, I can then find the corresponding line. Column numbers are difficult to support because they depend on the interpretation of tab characters.

If the source code is part of an out file, I could a compute line number from an offset later - so they would not have to be part of a point (although they are convenient and compact).

from bisect_ppx.

by scanning the source code and remembering all offsets of the newlines in the file.

I think you could also take line numbers from locations while instrumenting. This function and its caller would have to be modified to take a location.

from bisect_ppx.

Closing this for now, see #111 (comment). Please comment if this is still needed. The type is now here:

It should be easy to add line numbers.

from bisect_ppx.