From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 06DA6BB83 for ; Sun, 21 May 2006 11:55:02 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4L9t1do000947 for ; Sun, 21 May 2006 11:55:01 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA21906 for ; Sun, 21 May 2006 11:55:00 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4L9svU5029051 for ; Sun, 21 May 2006 11:54:59 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.6/8.13.6) with ESMTP id k4L9srwc019628; Sun, 21 May 2006 18:54:53 +0900 (JST) Date: Sun, 21 May 2006 18:57:24 +0900 (JST) Message-Id: <20060521.185724.74757566.garrigue@math.nagoya-u.ac.jp> To: akalin@akalin.cx Cc: caml-list@inria.fr Subject: Re: [Caml-list] ocamldebug and abstract record types From: Jacques Garrigue In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 447038F5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 447038F1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocamldebug:01 flamewar:01 mli:01 debugger:01 abstr:01 debugger:01 gdb:01 cmi:01 cmo:01 cmo:01 non-trivial:01 debugging:01 fprintf:01 caml-list:01 abstract:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: Frederick Akalin > At the risk of starting another flamewar, I have another question. I > notice that if I have a record type that's defined in an .mli file, I > am able to print objects of that type and see its contents in the > debugger. However, if I make that type abstract (only defining it in > the .ml file), I am unable to do so, instead seeing "", unless > I am in the .ml file where the type is defined. > > Surely this information is available to the debugger from anywhere in > the program? Currently I make most of my types non-abstract simply > because it is impossible to debug my programs without being able to > check record contents, a practice which I would like to avoid having > to do. I am used to gdb, which prints out all a struct's contents > regardless of protected/private modifiers, or Perl, which provides a > similar facility with the Data::Dumper module. To be more precise, the debugger uses information from the .cmi file to print values. The information is not included in the .cmo file, even with the -g option. Printing automatically abstract type would require a new infrastructure, saving type definitions in the .cmo. Note that an intermediate step would be to declare your definitions as private: they become semi-abstract (you cannot create values from outside the module), but you can still print them. > I am aware that the debugger lets you load printing functions, a > facility which I am now exploring. Although my first impression is > that it requires a non-trivial amount of work, both on the coding and > debugging side. This requires some work, but not as difficult as it may seem. The pretty-printer is very easy to use, particularly Format.fprintf. Jacques