caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Tom Ridge <tom.j.ridge+list@googlemail.com>
To: Ivan Gotovchits <ivg@ieee.org>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] OCamldebug
Date: Fri, 24 Feb 2017 09:20:47 +0000	[thread overview]
Message-ID: <CABooLwP30TtN6RZDeXKahFbWQV6vioUg9n5-gfN-qXutz-Vr_A@mail.gmail.com> (raw)
In-Reply-To: <CABooLwPenwF-F22XE95zQ0AhX6_0vDPqqepV05pfwG_aa-7J_A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

I take it back! Some of my code goes via external functors which indeed
hide various type equalities.

Thanks for your help.

On 24 February 2017 at 09:16, Tom Ridge <tom.j.ridge+list@googlemail.com>
wrote:

> My functors never hide anything, and always include the input module as a
> submodule of the output module. So I hope that type equalities are as
> maximally visible as they could be. But ocamldebug doesn't seem to get it :(
>
>
>
> On 23 February 2017 at 17:02, Ivan Gotovchits <ivg@ieee.org> wrote:
>
>> It matters whether in the signature of a module that is produced by the
>> functor, the type of the key is still the same as the type of the key
>> parameter. If it is not, then debugger cannot know, whether the output type
>> is a key or not. Probably, if you add a sharing constraint between the
>> functor parameter signature and the resulting module signature the debugger
>> with capture it. Especially, if this would be an erasing signature
>> (although it is not always possible), e.g.,
>>
>> module M = sig type key type t end
>> module Make(Key : T) : M with type key = Key.t
>>
>>
>> or
>>
>> module Make(Key : T) : M with type key := Key.t
>>
>>
>>
>> If these approaches do not work for you, then you can define a printer
>> yourself in a separate module (that is loaded with `load_printer` command).
>> In this printer you may apply a functor,
>> and since functors are applicative in OCaml the debugger might be clever
>> enough to pick this printer. It is not guaranteed, though, as the debugger
>> is using lots of heuristics, and sometimes, they do fail.
>>
>>
>> Best wishes,
>> Ivan
>>
>>
>>
>> On Thu, Feb 23, 2017 at 11:49 AM, Tom Ridge <
>> tom.j.ridge+list@googlemail.com> wrote:
>>
>>> Regarding `#install_printer`, can you explain more? The type
>>> "Key_value_types.key" is equal to string (in this particular case).
>>> However, this type is produced via module application, and so I cannot
>>> construct a printer that can print values of type "Key_value_types.key"
>>> before program execution (which seems to be required for #install_printer).
>>>
>>> Somehow I seem to want to tell ocamldebug that Key_value_types.key is in
>>> fact equal to string. Or alternatively coerce kra (using Obj.magic) to
>>> string type so that it can easily be printed by ocamldebug?
>>>
>>>
>>>
>>> On 23 February 2017 at 16:31, Ivan Gotovchits <ivg@ieee.org> wrote:
>>>
>>>> Probably it is an abstract type, that is represented as string. In any
>>>> case you can use the `#install_printer` directive to enable printing any
>>>> type. The argument
>>>> is a function of type `t -> Format.formatter -> unit`, where `t` is a
>>>> name of your type.
>>>>
>>>> On Thu, Feb 23, 2017 at 11:24 AM, Tom Ridge <
>>>> tom.j.ridge+list@googlemail.com> wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> I am debugging some code. For various reasons I have started to use
>>>>> ocamldebug rather than printf.
>>>>>
>>>>> I should say that ocamldebug is excellent. Really excellent.
>>>>> Especially the "backwards" stepping.
>>>>>
>>>>> However, sometimes I want to see the value of a particular variable. I
>>>>> can use the "p" (print) command as:
>>>>>
>>>>> (ocd) p kra
>>>>> kra: Key_value_types.key = <abstr>
>>>>>
>>>>> The problem is that I know that kra is a string. But ocamldebug only
>>>>> shows <abstr>.
>>>>>
>>>>> Admittedly the code is functorized. But I have a feeling I should be
>>>>> able to tweak something to get ocamldebug to print the value of kra.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> T
>>>>>
>>>>
>>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6065 bytes --]

  reply	other threads:[~2017-02-24  9:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23 16:24 Tom Ridge
2017-02-23 16:31 ` Ivan Gotovchits
2017-02-23 16:49   ` Tom Ridge
2017-02-23 17:02     ` Ivan Gotovchits
2017-02-24  9:16       ` Tom Ridge
2017-02-24  9:20         ` Tom Ridge [this message]
2017-02-24  9:28         ` Sébastien Hinderer
2017-02-24  8:41     ` Sébastien Hinderer
2017-02-24  9:14       ` Tom Ridge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABooLwP30TtN6RZDeXKahFbWQV6vioUg9n5-gfN-qXutz-Vr_A@mail.gmail.com \
    --to=tom.j.ridge+list@googlemail.com \
    --cc=caml-list@inria.fr \
    --cc=ivg@ieee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).