From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 91C93BB84 for ; Fri, 26 Dec 2008 20:34:27 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAP+/VEnRVdoUimdsb2JhbACTLj4BAQEKCQwHDwWpGliDU4EEKQiKDAEDAQOFBwiBMg X-IronPort-AV: E=Sophos;i="4.36,285,1228086000"; d="scan'208";a="21753864" Received: from mail-bw0-f20.google.com ([209.85.218.20]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Dec 2008 20:34:27 +0100 Received: by bwz13 with SMTP id 13so11427728bwz.3 for ; Fri, 26 Dec 2008 11:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HVxICzkT3SkEx8iJ5D/0pYWqf6+ED8bdCEfqLGqdFK8=; b=AeuAfaF+xbNigR7Rtek65Rsff0FH1g9u/PbYYob+TkzY2dTE1IJi8hSSCjEgqR7wFM cLV3PE/yO0z3HtPgphxdCnBCzC5ME/nLZMF5s1ULpx2Otq/SpMD1z6iZcGdOhI8q/k66 l1o8kaJXSB0AdtSP7/emeLIId/ets3LnxloIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EvBvto8VPuPDSXtxbmGAFoxcDEIpdWw5ftv7axh8/JSvGh2T3BJyjYTr0FEeBUuGgH S48A90N9nYOZOcab+x8yaebbIDBs4hNs/HHCBXIAnFVGUkF0W4uGbNJmOy5aAgQBHN4k S8x9l+QkNkwgu5xRSdKLdw/pLoMpPm8wIKUls= Received: by 10.180.231.17 with SMTP id d17mr4083770bkh.37.1230320066653; Fri, 26 Dec 2008 11:34:26 -0800 (PST) Received: by 10.181.25.5 with HTTP; Fri, 26 Dec 2008 11:34:26 -0800 (PST) Message-ID: <5160b4200812261134i72b81bb0vdee6ff0e6869c5cf@mail.gmail.com> Date: Sat, 27 Dec 2008 04:34:26 +0900 From: "Jun Furuse" To: "David Allsopp" Subject: Re: [Caml-list] [ANN] OCamlSpotter: OCaml compiler extension for source browsing, version 1.0 Cc: caml-list@yquem.inria.fr In-Reply-To: <00a201c9674b$362aea00$a280be00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5160b4200812250547l35a1536fuf687d9e277999bd0@mail.gmail.com> <00a201c9674b$362aea00$a280be00$@com> X-Spam: no; 0.00; furuse:01 furuse:01 ocaml:01 compiler:01 ocaml:01 ocamlc:01 ocamlc:01 compiler:01 integers:01 marshaled:01 marshaled:01 cmi:01 compilable:01 ocamlfind:01 gerd:01 Hi, On Fri, Dec 26, 2008 at 8:15 PM, David Allsopp wrote: > This sounds really cool - but is it really necessary to patch OCaml 3.11.0 > to achieve it? The .annot files produced by OCaml 3.11 give external > reference information already... > e.g. > > [Test.ml] > open List;; > > rev [];; > > # ocamlc -c -annot Test.ml > > [Test.annot] > "Test.ml" 3 15 15 "Test.ml" 3 15 18 > type( > 'a list -> 'a list > ) > ident( > ext_ref List.rev > ) > > The second entry in the .annot file shows the full module path required for > the call to rev - taking into account all open, include statements and > giving the full path in terms of packed modules and so on. Sorry, but I do not think so: include List let g = length ocamlc 3.11.0 with -annot never informs about length, included from List. This is why a compiler patch is required at least for version 3.11.0. Besides this version specific reason, annot is a text and therefore it must be pretty-printed at creation and parsed back at the use. It is costly and sometimes files become very huge (few MBs sometimes). In addition, some very important properties for browsing such as the identifier stamp integers are simply lost at pretty printing and never be recovered at parsing. From these difficulties, rather than pretty printed, I think those information should be simply marshaled. Marshaled spot files are always smaller than annots, and loading is straightforward and pretty fast. > Surely all you need once armed with the .annot file is the command line > which was used to compile the module so that you can translate the module > paths into actual files .cm* files (and then look for corresponding .ml > files) - the code for tools such as cmigrep (not to mention the compiler > itself) should contain everything necessary for analysing .cm[ox], .cmi and > .cm{x,}a files to turn a given module path into the actual file reference. It is a very interesting approach but I did not take it, firstly because this only works with compiled/compilable modules: it is often very handy to browse sources with errors, even they are just partially browsable. Secondly because I was (and am still) not very confident whether cm* files contain all the information I need for spotter. > Capturing the command line used to make the .annot file would seem to me to > be a better job for ocamlfind - I would have thought that you're more likely > to get Gerd to accept a patch for a simple hook interface in findlib than to > get a patch which emits additional output files accepted by the OCaml team > (however, it might be worth raising a feature request for the OCaml team to > add an entry to .annot files which records the command line used in the > .annot file itself as I can't imagine that's particularly hard or a > maintenance problem)... OCamlFind is a great tool, but there are many people who are happy without it. I would rather like to take an effort to move the caml-dev team to accept some part of my patch. :-) It is almost trivial: dump things available at typing, removing references to functions, which prevents output_value. = j