Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt emacs mode to generate .annot from .cmt files #5812

Closed
vicuna opened this issue Nov 6, 2012 · 9 comments
Closed

Adapt emacs mode to generate .annot from .cmt files #5812

vicuna opened this issue Nov 6, 2012 · 9 comments
Assignees
Labels

Comments

@vicuna
Copy link

vicuna commented Nov 6, 2012

Original bug ID: 5812
Reporter: @alainfrisch
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-02-24T14:52:48Z)
Resolution: not a bug
Priority: normal
Severity: minor
Target version: undecided
Category: ~DO NOT USE (was: OCaml general)
Related to: #4369 #6134
Monitored by: @gasche @jmeber

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

@vicuna
Copy link
Author

vicuna commented Nov 8, 2012

Comment author: cago

I started writing a tool[1] 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.

[1] https://github.com/OCamlPro/typerex/tree/typerex2/tools/ocp-type-from-loc

@vicuna
Copy link
Author

vicuna commented Nov 8, 2012

Comment author: @gasche

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

@vicuna
Copy link
Author

vicuna commented Nov 9, 2012

Comment author: @alainfrisch

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

@vicuna
Copy link
Author

vicuna commented Nov 9, 2012

Comment author: @yakobowski

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.

@vicuna
Copy link
Author

vicuna commented Nov 9, 2012

Comment author: @gasche

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.

@vicuna
Copy link
Author

vicuna commented Nov 12, 2012

Comment author: @alainfrisch

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.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @alainfrisch

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

Now we have https://github.com/LexiFi/cmt_annot so let's close this ticket.

@vicuna vicuna closed this as completed Feb 24, 2017
@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @yakobowski

Sure, but actually I think "use Merlin" is an even better advice.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @alainfrisch

Sure, although there is variety of contexts in which Merlin cannot be used (e.g. when working on forks of OCaml, since porting Merlin to such port is currently quite challenging while a .cmt-based tool might work out of the box).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants