|Anonymous | Login | Signup for a new account||2015-04-19 16:14 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005812||OCaml||OCaml general||public||2012-11-06 13:25||2014-09-16 08:31|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||4.03.0+dev||Fixed in Version|
|Summary||0005812: Adapt emacs mode to generate .annot from .cmt files|
|Description||It would be useful to adapt the OCaml emacs mode so that the .annot file is generated from the .cmt file on demand (when the .annot does not exist or is less recent than the .cmt file), using the read_cmt tool (to be installed). Currently, one has to compile with -annot, which takes a significant amount of the total compilation time.|
In the longer term, one can imagine having the emacs mode call a tool which directly queries the .cmt file without generating an .annot file at all, but this probably requires much more work.
|Tags||No tags attached.|
I started writing a tool that finds type of a value from its location. I intended to use it for something else, but if it can be used for that too, feel free to contribute, it's not yet finished.
 https://github.com/OCamlPro/typerex/tree/typerex2/tools/ocp-type-from-loc [^]
Çagdas, I don't think this design would work for the Emacs mode. The idea of the .annot file was to present location-indexed information in a simple format that dumb elisp code could process easily. In a way you can see the (cmt -> annot) translation as a generic "exposing simple information to text-based consumers" step designed for ease of post-processing (while the cmt format itself is designed for flexibility and exhaustivity of collected information).
Your code is in OCaml (meaning more work to call it from Emacs) and re-parses the whole typedtree structure each time you want to get information -- which I guess doesn't take that much less time than creating a location-indexed structure once and for all. In my experience, if you request location-based type information for some location in the code, you're quite likely to do other similar requests in the same source file (that you're trying to understand/debug/analyze/whatever), so one re-indexing rather than several re-traversal should be profitable.
Now, we could think of storing location-indexed information in the .cmt as well, but I think that Alain's idea of letting consumers request that computation on demand is important; if it was stored in the .cmt from OCaml-side, it should be computed and stored only on demand, and exposed with an easy interface (hopefully as simple as querying the current .annot file) for painful-to-program editors to use.
I think it makes a lot of sense to have a dedicated tool to query the .cmt file, to be called from emacs (hence with a simple textual input/output interface). This would allow to report much more things than the current .annot file, with all the logic being implemented in OCaml. Also, it would actually simplify the logic on the emacs lisp side, since it wouldn't have to parse the whole .annot file.
Generating the .annot file can take quite a bit of time (well, it's still probably ok for interactive use), because it generates a lot of redundant textual output. Just loading the .cmt file and looking for specific information should be rather quick (and the tool can always create some stored indexed cache of the .cmt file if needed).
Boris Yakobowski (reporter)
|From what I understood, OCamlspotter's emacs mode does essentially this (querying results from ocamlspot, which parses .cmt files, and displaying them in Emacs). It should be possible to find some inspiration there.|
After giving some more thought, it should be possible to look at a specific location in a Typedtree without doing a linear search, by assuming that locations are correctly nested intervals and pruning the search accordingly, getting an essentially logarithmic behavior (in the parts of the AST that are well-balanced, eg. not Texp_sequence). With such an implementation, caching would probably be unnecessary. But yes, I think having a simple interface is important.
PS: if Jun's implementation is already better than what we have, and now that it is easy to provide separately from the core compiler internals, could the standard distribution consider shipping it with the emacs mode? That could be more features for less work that re-implementing .annot file generation.
> After giving some more thought, it should be possible to look at a specific location in a Typedtree without doing a linear search
You'd still need to load the entire .cmt file in memory, which is also linear in the total size of the unit, and probably slower than traversing the whole data structure to find the relevant node. But all that should be really fast anyway.
|2012-11-06 13:25||frisch||New Issue|
|2012-11-06 13:26||frisch||Description Updated||View Revisions|
|2012-11-08 17:04||cago||Note Added: 0008450|
|2012-11-09 00:52||gasche||Note Added: 0008454|
|2012-11-09 10:04||frisch||Note Added: 0008458|
|2012-11-09 10:25||Boris Yakobowski||Note Added: 0008459|
|2012-11-09 10:47||gasche||Note Added: 0008461|
|2012-11-12 09:49||frisch||Note Added: 0008498|
|2012-11-12 11:26||gasche||Note Added: 0008499|
|2012-11-12 11:27||gasche||Note Edited: 0008499||View Revisions|
|2012-11-12 11:38||frisch||Note Added: 0008500|
|2012-11-12 11:45||gasche||Note Deleted: 0008500|
|2012-11-12 11:45||gasche||Note Deleted: 0008499|
|2013-01-03 17:12||doligez||Status||new => acknowledged|
|2013-07-11 18:03||doligez||Target Version||=> 4.01.0+dev|
|2013-07-22 12:46||frisch||Target Version||4.01.0+dev => 4.01.1+dev|
|2013-08-21 23:38||frisch||Relationship added||related to 0006134|
|2014-05-25 20:20||doligez||Target Version||4.01.1+dev => 4.02.0+dev|
|2014-07-30 23:01||doligez||Target Version||4.02.0+dev => 4.02.1+dev|
|2014-07-31 13:51||doligez||Relationship added||related to 0004369|
|2014-09-04 00:25||doligez||Target Version||4.02.1+dev => undecided|
|2014-09-16 08:31||doligez||Target Version||undecided => 4.03.0+dev|
|Copyright © 2000 - 2011 MantisBT Group|