Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005812OCaml~DO NOT USE (was: OCaml general)public2012-11-06 13:252017-08-27 17:52
Assigned Tofrisch 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionundecidedFixed in Version 
Summary0005812: Adapt emacs mode to generate .annot from .cmt files
DescriptionIt 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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006134acknowledged emacs mode doesn't support cmt[i] files 
related to 0004369closedfrisch The emacs function "Show types at point" does not show the type of methods 

-  Notes
cago (reporter)
2012-11-08 17:04

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] [^]
gasche (developer)
2012-11-09 00:52

Ç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.
frisch (developer)
2012-11-09 10:04

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)
2012-11-09 10:25

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.
gasche (developer)
2012-11-09 10:47

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.
frisch (developer)
2012-11-12 09:49

> 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.
frisch (developer)
2017-02-24 15:52

> 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 [^] so let's close this ticket.
Boris Yakobowski (reporter)
2017-02-24 17:31

Sure, but actually I think "use Merlin" is an even better advice.
frisch (developer)
2017-02-24 18:33

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

- Issue History
Date Modified Username Field Change
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 / +beta1
2016-04-18 16:47 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2017-02-16 14:01 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-02-24 15:52 frisch Note Added: 0017447
2017-02-24 15:52 frisch Status acknowledged => resolved
2017-02-24 15:52 frisch Resolution open => no change required
2017-02-24 15:52 frisch Assigned To => frisch
2017-02-24 17:31 Boris Yakobowski Note Added: 0017472
2017-02-24 18:33 frisch Note Added: 0017473
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker