Re: TTY debugger and the portray mechanism.

josh singer wrote:
> 
> The second bug is that it is unpredictable in the TTY debugger whether
> compound terms get displayed using their portray predicate definitions or
> not. This seems to be an interaction between the TTY debugger, the module
> system and the portray mechanism.
> Here's an example.
> 
...
> [eclipse 6]: test_create(1, 2, 3, T), test_length([T], X).
>   (1) 1 CALL  test_create(1, 2, 3, T)   %> creep
>   (1) 1 EXIT  test_create(1, 2, 3, test(1))   %> creep
>   (2) 1 CALL  test_length([test(1)], X)   %> creep
>   (3) 2 CALL  length([test_struct_impl(1, 2, 3)], X)   %> skip
>   (3) 2 EXIT  length([test_struct_impl(1, 2, 3)], 1)   %> creep
>   (2) 1 EXIT  test_length([test(1)], 1)   %> creep
...
> 
> Maybe this is because the portray exported by test_module_b is not visible
> in test_module.

That's right. You have stepped into a different module context,
where the portray is not visible. Operator declarations and the like
will have similar behaviour.


> But this is to be expected, since test_module is often a
> low-level utility, which wouldn't be expected to know about the
> peculiarities of some application-specific data module (test_module_b).

I anyone has an idea how to do better, let me know!
With plain data structures, we don't have any module information
attached, i.e. we don't know in which module the data structure
was originally created, so we don't know where we should look
for a portray declaration.

In the special case (not yours) of goal-portrays (where the portrayed
date structure is actually a predicate call), we could actually do
better since we can look up the predicate's definition module.


-- 
 Joachim Schimpf              /             phone: +44 20 7594 8187
 IC-Parc                     /      mailto:J.Schimpf@imperial.ac.uk
 Imperial College London    /    http://www.icparc.ic.ac.uk/eclipse