[Hat] GUI for Hat

Thomas Davie tatd2 at kent.ac.uk
Fri Jul 28 17:58:05 EDT 2006


On 28 Jul 2006, at 17:59, Peter Nuttall wrote:

> Hello all,
>
> I'm doing my dissertation on writing a GUI for hat, and Neil Mitchell
> suggested I send a mail saying what i was planning to see if you guys
> had any good ideas or comments. This is the proposal:
>
> The problem
>
> Hat provides a easy way to generate a trace, and various tools have
> been developed to examine the traces produced by it. However, these
> tools have two main flaws: They are hard to learn and use and they are
> not linked together. Ideally we would like hat to be as easy to use as
> possible. This way it can both be used to debug real programs by  
> Haskell
> programmers, but can be used as a teaching tool for beginners, so they
> can see how lazy evaluation works and find simple bugs when they write
> their first programs.
>
> The solution
>
> Write a graphical user interface to Hat. A clickable GUI will be  
> easier to
> use than a ncurses GUI, and will seem easier to use. The
> GUI will provide the same functionality as the hat tools do already,
> but it will be easier to use. This will be done by separating out the
> current user interface from the functionality as much as possible,  
> then
> making the functionality into a library. As part of this, I will  
> try and
> upgrade the tools to use the new tracing library written by Tom  
> Shackell.
>
> The GUI's will be implemented in GTK2HS . It will consist of a Window
> with tabs for each tool. Neil Mitchell has already constructed a GUI,
> and I plan to use this as a starting point.
>
> The tools that will be usable though the GUI will be:
>
> Search
>
> This will let the user search though all the functions called, and see
> that function.s inputs and output. The UI will be based on that of  
> JuK,
> with searching using haskell.s pattern matching syntax.
As Neil said, this sounds a lot like hat-observe

> Monad
>
> A step over debugger for do blocks. This will be similar to normal
> debuggers
An excellent idea, but I think you might have a few problems, I've  
had a look at trying to deal with IO actions a bit better and found  
that (actually quite reasonably) the trace doesn't actually have any  
information on what IO happened.  The trace represents the purely  
functional part of the computation, so all you will see is that  
something evaluated to an IO action.

What I had considered doing is essentially emulating the IO actions  
in the tool, this is limited in the sense of it supports only those  
actions you code into the tool, but it is at least a solution.

I'd be interested to see what you come up with here.

> Stack.
>
> When loading a a trace that has terminated with an error, the GUI
> will show a listing of the last functions called and their inputs and
> outputs. It will collapse any loops.
Something similar to hat-stack?

> Cover
>
> It will use hs-colour to try and show which functions are being used
> for a set of inputs. If the new tracing library is used, and it  
> supports
> taking the union of traces, this will be used to show coverage from  
> lots
> of traces. This can be tied into quickcheck.
Excellent, that's a really useful tool for me.  You might find some  
useful code in hat-delta and in hat-cover.  Hat-cover contains code  
that will give you full coverage for a call, while hat-delta contains  
code that will generate the coverage in the top level function call.

> Ethereal bit.
>
> Ethereal is a tool for examining network traffic, and my plan is to
> . borrow from it's "follow TCP stream" feature, which shows you all  
> the
> traffic in a stream, and lets you see messages and replies. It will
> show text moving in and out of handles, and display the logical time
> between messages.
Interesting - I'd like to see this integrated with your IO monad tool.

> Display bit.
>
> This will allow the user to see how redexes happen and allow the  
> use to
> see laziness in action. This will be based on hat-amin. It is  
> dependent
> on writing a good graph drawing function.
So you want to do hat-anim but rather than showing the redex you want  
to show the current heap state?  That sounds fun, but probably complex.

Straight off the top of my head for graph drawing, you might want to  
use the NodeExp library to generate the full trace, and then apply  
various transforms to the graphs to get the various steps (there's a  
singleStepEval function in there that performs a single step of the  
evaluation).  You can then shove that output into pretty-hat (it has  
library calls) to generate dot files, stick that into dot, and  
display the pdf it renders for you.

> algorithmic
>
> This will be a normal algorithmic debugger,  though I haven.t thought
> of how it will work in a GUI.
I'd thought about doing it the way neil suggests, but there are other  
options.  Look at hat-explore... perhaps a version of that that shows  
you the EDT, and allows you to click on nodes and mark them as  
correct or incorrect?

I hope that lot's useful to you

A final suggestion, at least the tools I've written recently, I've  
tried to keep pretty modular with thoughts of adding a GUI later, so  
you can probably use a lot of the NodeExp, HatAnim, Slice, PrettyHat,  
and HatDelta code.  I've found that some of the older code is pretty  
modular, but some of it is fairly hard to navigate, so there may be  
more pickings in there to integrate.  In short, I'm saying try not to  
reinvent the wheel too much, there's a lot of good code in there.

Bob





More information about the Hat mailing list