From ndmitchell at gmail.com  Wed Jul  5 10:49:15 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Jul  5 10:40:32 2006
Subject: [Hat] Pattern match errors in do?
Message-ID: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>

Hi

With the following program:

---------------------------------
import System

main = do (x:_) <- getArgs
          print $ fact (read x)


fact :: Int -> Int
fact 0 = 1
fact n | n > 0 = n * fact (n - 1)
--------------------------------

Running Main without any arguments via Hat gives me a trace, and the
error message:

> Error: pattern-match failure in do expression

Running hat-stack Main.hat gives me:

> Tracefile "Main.hat" contains no reference to a program error.

How come? I get the same results on both Windows and Linux.

Thanks

Neil
From Malcolm.Wallace at cs.york.ac.uk  Wed Jul  5 11:27:34 2006
From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Wed Jul  5 11:19:09 2006
Subject: [Hat] Pattern match errors in do?
In-Reply-To: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>
References: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>
Message-ID: <20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>

"Neil Mitchell" <ndmitchell@gmail.com> wrote:

> Running Main without any arguments via Hat gives me a trace, and the
> error message:
> > Error: pattern-match failure in do expression
> 
> Running hat-stack Main.hat gives me:
> > Tracefile "Main.hat" contains no reference to a program error.

Very strange.  The tracefile contains the error message (at the end),
and an explicit reference to it (in bytes 8-11).  But it contains no
reference (in bytes 4-7) to the expression that triggered the error, and
so hat-stack quite reasonably complains.

It looks like the library code to trap the error and tidy up the
tracefile might have a bug.

Regards,
    Malcolm
From ndmitchell at gmail.com  Wed Jul  5 11:44:17 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Jul  5 11:35:32 2006
Subject: [Hat] Hat for Windows
Message-ID: <404396ef0607050844xfadee6bl1a18695cb4d8e45a@mail.gmail.com>

Hi,

A preview of Hat for Windows is available at:
http://www.cs.york.ac.uk/fp/temp/hat-win32-05_jul_2006.zip

All hat utilities are available and seem to work apart from:

hat-explore - advanced escape codes, looks pretty hard to get round
hat-anim - escape codes, might be able to work round
hat-detect - tries to spawn an xterm

In addition, there is also hat-make, which is windows only hmake -hat
alternative.

Instructions for installing
=================

Extract the contents of the .zip file into a folder preserving
directory structure.

Add the folder containing hat-make to your %PATH% variable, this is
100% required, even if you give the explicit path to hat-make when you
use it.

Make sure ghc is available on your system and has been added to the %PATH%.

Instructions for use
==============

cd to the directory containing your Haskell source

hat-make Main.hs
main <arguments>
hat-stack Main.hat
hat-observe Main.hat
etc.

I have tested the programs, and they all work quite well - I have not
run into any limitations beyond those which happen on Hat on Linux as
well.

Thanks

Neil
From ndmitchell at gmail.com  Wed Jul  5 11:52:57 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Jul  5 11:44:12 2006
Subject: [Hat] Re: Hat for Windows
In-Reply-To: <404396ef0607050844xfadee6bl1a18695cb4d8e45a@mail.gmail.com>
References: <404396ef0607050844xfadee6bl1a18695cb4d8e45a@mail.gmail.com>
Message-ID: <404396ef0607050852q50d6bdbt7ed85168370de9b4@mail.gmail.com>

Hi

> All hat utilities are available and seem to work apart from:
hat-trail as well, because of escape codes - I had missed that on my first pass.

Thanks

Neil
From O.Chitil at kent.ac.uk  Wed Jul  5 14:11:52 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Wed Jul  5 14:02:42 2006
Subject: [Hat] Pattern match errors in do?
In-Reply-To: <20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>
References: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>
	<20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <44AC00E8.3070908@kent.ac.uk>


I can explain this.

A pattern match failure in a "do" will call "fail" (not "error" as other 
pattern match failures do). This is the "fail" of the IO monad, which 
calls "ioError". And "ioError" raises an exception. This exception is 
caught by a "catch" that Hat has put around "main" and that records the 
exception in the trace file and terminates the computation. However, for 
raising and catching an exception the standard Haskell functions are 
used, so no information about which expression raised the exception is 
actually passed to the "catch" around main. That's why it cannot write 
anything about the origin of the exception in the trace.

An idea that comes to my mind is that every expression raising an 
exception could record itself in a global variable in C land. So when 
the outermost "catch" catches an exception, it can read the origin from 
this global variable. There is no problem with normal "catch" functions 
in user programs.

It just isn't very nice and it wouldn't work with concurrency. Hat 
currently doesn't work with concurrency, but I believe currently  
concurrency could be done in principle by removing the shadow stack, 
which is only there for optimisation, but not strictly necessary. I 
cannot think of any solution that would deal with exceptions and work 
with concurrency. Any suggestions?

Ciao,
Olaf

Malcolm Wallace wrote:

>"Neil Mitchell" <ndmitchell@gmail.com> wrote:
>
>  
>
>>Running Main without any arguments via Hat gives me a trace, and the
>>error message:
>>    
>>
>>>Error: pattern-match failure in do expression
>>>      
>>>
>>Running hat-stack Main.hat gives me:
>>    
>>
>>>Tracefile "Main.hat" contains no reference to a program error.
>>>      
>>>
>
>Very strange.  The tracefile contains the error message (at the end),
>and an explicit reference to it (in bytes 8-11).  But it contains no
>reference (in bytes 4-7) to the expression that triggered the error, and
>so hat-stack quite reasonably complains.
>
>It looks like the library code to trap the error and tidy up the
>tracefile might have a bug.
>
>Regards,
>    Malcolm
>_______________________________________________
>Hat mailing list
>Hat@haskell.org
>http://www.haskell.org/mailman/listinfo/hat
>  
>

From ndmitchell at gmail.com  Wed Jul  5 17:41:47 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Jul  5 17:33:00 2006
Subject: [Hat] Pattern match errors in do?
In-Reply-To: <44AC00E8.3070908@kent.ac.uk>
References: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>
	<20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>
	<44AC00E8.3070908@kent.ac.uk>
Message-ID: <404396ef0607051441m62fe179ele1f737ad132feef7@mail.gmail.com>

Hi,

> A pattern match failure in a "do" will call "fail" (not "error" as other
> pattern match failures do). This is the "fail" of the IO monad, which
> calls "ioError".

I believe according to Haskell 98, fail in the IO monad calls error -
its only recent extension to GHC/Hugs which have resulted in ioError
and exceptions. Perhaps for the purposes of hat stuff, error should be
called instead? At least until a proper exception story can be
developed.

Thanks

Neil
From Malcolm.Wallace at cs.york.ac.uk  Thu Jul  6 05:35:44 2006
From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Thu Jul  6 05:29:24 2006
Subject: [Hat] Pattern match errors in do?
In-Reply-To: <404396ef0607051441m62fe179ele1f737ad132feef7@mail.gmail.com>
References: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>
	<20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>
	<44AC00E8.3070908@kent.ac.uk>
	<404396ef0607051441m62fe179ele1f737ad132feef7@mail.gmail.com>
Message-ID: <20060706103544.5a6b0001.Malcolm.Wallace@cs.york.ac.uk>

"Neil Mitchell" <ndmitchell@gmail.com> wrote:

> > A pattern match failure in a "do" will call "fail" (not "error" as
> > other pattern match failures do). This is the "fail" of the IO
> > monad, which calls "ioError".
> 
> I believe according to Haskell 98, fail in the IO monad calls error -
> its only recent extension to GHC/Hugs which have resulted in ioError
> and exceptions. Perhaps for the purposes of hat stuff, error should be
> called instead? At least until a proper exception story can be
> developed.

The problem is, that would require type information about which monad
the 'do' block belongs to.  For IO, it might be fine for a pattern-match
failure to call 'error', but it would be totally incorrect for, say, the
Maybe monad, or the list monad, where fail might be defined as e.g.
'const Nothing' or 'const []'.

Regards,
    Malcolm
From O.Chitil at kent.ac.uk  Thu Jul  6 05:40:33 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Thu Jul  6 05:31:23 2006
Subject: [Hat] Pattern match errors in do?
In-Reply-To: <404396ef0607051441m62fe179ele1f737ad132feef7@mail.gmail.com>
References: <404396ef0607050749r46704166ofd6a836bd5f5b8a9@mail.gmail.com>	<20060705162734.600cea52.Malcolm.Wallace@cs.york.ac.uk>	<44AC00E8.3070908@kent.ac.uk>
	<404396ef0607051441m62fe179ele1f737ad132feef7@mail.gmail.com>
Message-ID: <44ACDA91.5080900@kent.ac.uk>

Neil Mitchell wrote:

> Hi,
>
>> A pattern match failure in a "do" will call "fail" (not "error" as other
>> pattern match failures do). This is the "fail" of the IO monad, which
>> calls "ioError".
>
>
> I believe according to Haskell 98, fail in the IO monad calls error -
> its only recent extension to GHC/Hugs which have resulted in ioError
> and exceptions. Perhaps for the purposes of hat stuff, error should be
> called instead? At least until a proper exception story can be
> developed.

 From the Haskell 98 report:

The fail method of the IO instance of the Monad class (Section 6.3.6 
<http://haskell.org/onlinereport/basic.html#monad-class>) raises a 
userError, thus:

  instance Monad IO where 
    ...bindings for return, (>>=), (>>)

    fail s = ioError (userError s)

Also other IO operations (e.g. file not found) will directly raise an 
exception.

Ciao,
Olaf

From ndmitchell at gmail.com  Thu Jul  6 13:51:23 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Thu Jul  6 13:42:30 2006
Subject: [Hat] Hat-Gui, new tool
Message-ID: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>

Hi,

I have started writing Hat-Gui, a screenshot is available at:
http://www-users.cs.york.ac.uk/~ndm/projects/hat-gui.png

It is written with Gtk2Hs, and should be cross platform. This
screenshot is slightly misleading, only hat-stack works, the other two
tabs are just dummy's. However, hat-stack works perfectly, and you can
open a hat file, or associate them in your Windows environment.

In order to get hat-stack working I copied the HatStack.hs program,
renamed it to HatStackLib.hs and tweaked it a bit. Obviously this is
not the best way to do it. In order to get hat-gui working properly it
would be best to split every hat tool into a module which exports a
Haskell API interface (i.e. HatTools.Stack) and a command line program
that imports that as hat-stack.

What is the best way to acheive this split, and how should it be
organised? Most of the tools are already relatively abstract -
although will probably need tweaks.

Thanks

Neil
From O.Chitil at kent.ac.uk  Thu Jul  6 14:50:20 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Thu Jul  6 14:41:16 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
Message-ID: <44AD5B6C.9030703@kent.ac.uk>

Neil Mitchell wrote:

> I have started writing Hat-Gui, a screenshot is available at:
> http://www-users.cs.york.ac.uk/~ndm/projects/hat-gui.png

Great! For the interactive tools a GUI will be even better.

> What is the best way to acheive this split, and how should it be
> organised? Most of the tools are already relatively abstract -
> although will probably need tweaks.

I agree that splitting every tool module into a "model" module with a 
nice API and a textual "view" module is a very good idea. I wouldn't yet 
introduce any directory hierarchy (the hierarchical name space isn't 
Haskell 98 anyway). I think it would be slightly more meaningful if the 
models would keep the original names and the views be named e.g. 
HatStackText.

Do you plan extensions of the user interface? For a long time I thought 
it would be nice to make hat-observe source-oriented: Make it a source 
browser in which you can mark any expression and then this expression is 
observed. This could even be combined with hat-cover, because obviously 
you should not be able to observe a slice of code that was never executed.

Ciao,
Olaf
From ndmitchell at gmail.com  Thu Jul  6 15:44:39 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Thu Jul  6 15:35:54 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <44AD5B6C.9030703@kent.ac.uk>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
	<44AD5B6C.9030703@kent.ac.uk>
Message-ID: <404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>

Hi

> I agree that splitting every tool module into a "model" module with a
> nice API and a textual "view" module is a very good idea. I wouldn't yet
> introduce any directory hierarchy (the hierarchical name space isn't
> Haskell 98 anyway). I think it would be slightly more meaningful if the
> models would keep the original names and the views be named e.g.
> HatStackText.

Thats fine by me - I wouldn't have thought using hierarchical module
names would be a massive problem though, since every supported Haskell
compiler has them, and hat-trans looks as though it depends on them
(generating Hat.Something files) - but it doesn't make much difference
to me. If we ever wanted to provide Hat as a library for external
programs, as seems to be the trend (for example HsColour and Cpphs)
then hierarchical modules would be required.

> Do you plan extensions of the user interface? For a long time I thought
> it would be nice to make hat-observe source-oriented: Make it a source
> browser in which you can mark any expression and then this expression is
> observed. This could even be combined with hat-cover, because obviously
> you should not be able to observe a slice of code that was never executed.

My only planned extension is to have a continually available Source
window at the bottom of each pane, which is sync'd with the tool - for
example clicking on each line in hat-stack will jump to that line and
similarly for hat-observe. Of course, there is no reason that I can't
add links back from the source to hat-observe, and this source window
can certainly have hat-cover applied to it.

Once we have a "design" for the tool library/console split I will
commit my hat-gui and then anyone is welcome to add stuff to it!

Thanks

Neil
From ndmitchell at gmail.com  Fri Jul  7 10:52:53 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Jul  7 10:43:58 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
	<44AD5B6C.9030703@kent.ac.uk>
	<404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>
Message-ID: <404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>

Hi,

I have now committed hat-gui, with support for only hat-stack.

This version requires a split version of HatStack, where the existing
HatStack.hs is divided into HatStack.hs for the libary and
HatStackText.hs for the console input/output. Since this breaks the
makefile's for Linux, and is a reasonable amount of restructuring, I
thought I'd send the new versions of HatStack and HatStackText for
comments first. They are attached. Is this split/names/interface
acceptable?

Thanks

Neil

On 7/6/06, Neil Mitchell <ndmitchell@gmail.com> wrote:
> Hi
>
> > I agree that splitting every tool module into a "model" module with a
> > nice API and a textual "view" module is a very good idea. I wouldn't yet
> > introduce any directory hierarchy (the hierarchical name space isn't
> > Haskell 98 anyway). I think it would be slightly more meaningful if the
> > models would keep the original names and the views be named e.g.
> > HatStackText.
>
> Thats fine by me - I wouldn't have thought using hierarchical module
> names would be a massive problem though, since every supported Haskell
> compiler has them, and hat-trans looks as though it depends on them
> (generating Hat.Something files) - but it doesn't make much difference
> to me. If we ever wanted to provide Hat as a library for external
> programs, as seems to be the trend (for example HsColour and Cpphs)
> then hierarchical modules would be required.
>
> > Do you plan extensions of the user interface? For a long time I thought
> > it would be nice to make hat-observe source-oriented: Make it a source
> > browser in which you can mark any expression and then this expression is
> > observed. This could even be combined with hat-cover, because obviously
> > you should not be able to observe a slice of code that was never executed.
>
> My only planned extension is to have a continually available Source
> window at the bottom of each pane, which is sync'd with the tool - for
> example clicking on each line in hat-stack will jump to that line and
> similarly for hat-observe. Of course, there is no reason that I can't
> add links back from the source to hat-observe, and this source window
> can certainly have hat-cover applied to it.
>
> Once we have a "design" for the tool library/console split I will
> commit my hat-gui and then anyone is welcome to add stuff to it!
>
> Thanks
>
> Neil
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HatStack.hs
Type: text/x-haskell
Size: 1239 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/hat/attachments/20060707/f814aa73/HatStack.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HatStackText.hs
Type: text/x-haskell
Size: 2010 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/hat/attachments/20060707/f814aa73/HatStackText.bin
From O.Chitil at kent.ac.uk  Fri Jul  7 11:09:28 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Fri Jul  7 11:00:13 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>	<44AD5B6C.9030703@kent.ac.uk>	<404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>
	<404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>
Message-ID: <44AE7928.7050905@kent.ac.uk>

Neil Mitchell wrote:

> I have now committed hat-gui, with support for only hat-stack.
>
> This version requires a split version of HatStack, where the existing
> HatStack.hs is divided into HatStack.hs for the libary and
> HatStackText.hs for the console input/output. Since this breaks the
> makefile's for Linux, and is a reasonable amount of restructuring, I
> thought I'd send the new versions of HatStack and HatStackText for
> comments first. They are attached. Is this split/names/interface
> acceptable?

Great. I wonder whether it would be more sensible if the HatStack itself 
wouldn't do the trace file opening, hence also not get a FilePath as 
argument. In your GUI you want to combine several tools. So you open the 
trace once and then call the models of several tools. You might want to 
put the little code for rectifying the filename and opening the file 
into a general hat tool library. I guess the existing tools have a bit 
of code duplication.

Btw, feel free to add comments in the code ;-) I fear the code isn't 
well documented.

Ciao,
Olaf
From ndmitchell at gmail.com  Fri Jul  7 13:45:40 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Jul  7 13:36:48 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <44AE7928.7050905@kent.ac.uk>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
	<44AD5B6C.9030703@kent.ac.uk>
	<404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>
	<404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>
	<44AE7928.7050905@kent.ac.uk>
Message-ID: <404396ef0607071045o68114e3cla1f5fb967e399525@mail.gmail.com>

Hi,

> Great. I wonder whether it would be more sensible if the HatStack itself
> wouldn't do the trace file opening, hence also not get a FilePath as
> argument. In your GUI you want to combine several tools.
I considered that, however some tools are not going to use the
standard Hat library - for example w-hat, and then the person calling
the API will need to know how to open each hat file for each library.
However, I don't mind either way.

Thanks

Neil
From O.Chitil at kent.ac.uk  Fri Jul  7 14:14:29 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Fri Jul  7 14:05:14 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <404396ef0607071045o68114e3cla1f5fb967e399525@mail.gmail.com>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>	<44AD5B6C.9030703@kent.ac.uk>	<404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>	<404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>	<44AE7928.7050905@kent.ac.uk>
	<404396ef0607071045o68114e3cla1f5fb967e399525@mail.gmail.com>
Message-ID: <44AEA485.2000105@kent.ac.uk>


I wonder why w-hat doesn't use the standard Hat library. I see your point.

On the other hand, if you combine several tools and each tries to open 
the file you also run into problems. Most tools are interactive anyway, 
so they will need an initialisation and then several access functions.

I suppose it would have been better if the standard Hat library used a 
kind of handle for the trace. So you would first need to get the handle, 
like for a file. It would also allow processing several trace files at 
once (maybe rarely necessary). A handle would turn the trace into a 
normal abstract data type, not a single abstract value that needs 
magical initialisation.

So no clear winner, maybe adding more tools to your GUI you want to 
revisit this decision.

Ciao,
Olaf


Neil Mitchell wrote:

> Hi,
>
>> Great. I wonder whether it would be more sensible if the HatStack itself
>> wouldn't do the trace file opening, hence also not get a FilePath as
>> argument. In your GUI you want to combine several tools.
>
> I considered that, however some tools are not going to use the
> standard Hat library - for example w-hat, and then the person calling
> the API will need to know how to open each hat file for each library.
> However, I don't mind either way.
>
> Thanks
>
> Neil
> _______________________________________________
> Hat mailing list
> Hat@haskell.org
> http://www.haskell.org/mailman/listinfo/hat


From ndmitchell at gmail.com  Fri Jul  7 14:39:40 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Jul  7 14:30:46 2006
Subject: [Hat] Hat-Gui, new tool
In-Reply-To: <44AEA485.2000105@kent.ac.uk>
References: <404396ef0607061051l23a8f2d6maf8f936e09e5094e@mail.gmail.com>
	<44AD5B6C.9030703@kent.ac.uk>
	<404396ef0607061244j77579648u6289ab2129b63ed5@mail.gmail.com>
	<404396ef0607070752s23db8efcg2190df7e91d5ec6d@mail.gmail.com>
	<44AE7928.7050905@kent.ac.uk>
	<404396ef0607071045o68114e3cla1f5fb967e399525@mail.gmail.com>
	<44AEA485.2000105@kent.ac.uk>
Message-ID: <404396ef0607071139h4260dc7m4b87ef9bfa854d0d@mail.gmail.com>

> I wonder why w-hat doesn't use the standard Hat library. I see your point.
I believe Tom needs a lot more advanced access to the trace file than
any of the other tools, because he has much more powerful operations
for it.

> I suppose it would have been better if the standard Hat library used a
> kind of handle for the trace. So you would first need to get the handle,
> like for a file.
This is Tom's design of his library for Hat tracing, which he is going
to use in w-hat. It also allows things like comparing two trace
executions, by design.

Thanks

Neil
From i.normann at iu-bremen.de  Tue Jul 11 09:50:10 2006
From: i.normann at iu-bremen.de (inormann)
Date: Tue Jul 11 09:50:29 2006
Subject: [Hat] problems with debian
Message-ID: <5269742.post@talk.nabble.com>


Hi,

installation of hat on my debian Linux fails returning the message:
hat-ghc6: Depends: ghc6 (< 6.2.2+) but 6.4.1-1 is installed and it is kept
back.

Is there a newer deb-package around that supports ghc-6.4.1?

Alternatively I have just managed to compile hat from the tar-file and
started the little tutorial at
http://www.haskell.org/hat/tutorial1.html 

my session with the error report:
hat-trans   Insort.hs
hat-trans is not installed/configured for debian.
  (Tried directory /usr/local/share/lib/hat)
  See your system administrator, or install it yourself from
  http://www.haskell.org/hat/

Now I am really in a dead end :-(
replacing ghc-6.4.1 by ghc- 6.2.2 is not really what I want.

Any suggestions what to do?

Immanuel
-- 
View this message in context: http://www.nabble.com/problems-with-debian-tf1924566.html#a5269742
Sent from the Haskell - Hat forum at Nabble.com.

From p.s.nuttall at durham.ac.uk  Fri Jul 28 12:59:24 2006
From: p.s.nuttall at durham.ac.uk (Peter Nuttall)
Date: Fri Jul 28 13:58:41 2006
Subject: [Hat] GUI for Hat
Message-ID: <20060728165923.GA5561@compsoc.dur.ac.uk>

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.

Monad

A step over debugger for do blocks. This will be similar to normal
debuggers

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.

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.


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. 

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.

algorithmic

This will be a normal algorithmic debugger,  though I haven.t thought
of how it will work in a GUI.

Any suggestions, comments?

Pete



From ndmitchell at gmail.com  Fri Jul 28 15:01:29 2006
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Jul 28 14:51:00 2006
Subject: [Hat] GUI for Hat
In-Reply-To: <20060728165923.GA5561@compsoc.dur.ac.uk>
References: <20060728165923.GA5561@compsoc.dur.ac.uk>
Message-ID: <404396ef0607281201t7e49c499rd2c7856c48a220fd@mail.gmail.com>

Hi Pete,

> 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.
Is this not just hat-observe?

> A step over debugger for do blocks. This will be similar to normal
> debuggers
Is this intended to be a brand new debugging tool?


> 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.
So will this tool be an IO monitor? i.e. seeing all external actions
which occur, and in what order?

> 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.
I think this will probably be more like a tree than a graph? If so its
not that hard to do, lots of algorithms exist and they are pretty
easy.

> algorithmic
>
> This will be a normal algorithmic debugger,  though I haven.t thought
> of how it will work in a GUI.
I had a design for this, basically a list of alternating question answer lines:

sort [] = []
<yes> <no>
insert [] = []
<yes> <no>

When a user clicks on a yes or a no which is at the bottom line, it
generates a new question, when a user clicks on a yes or a no higher
up, and different from the previous answer, it deletes the list below
that point and generates a new question.

This lets the user see their "choice history", and change it at any
time, will being an essentially linear process for those people who
don't want any additional complexity.

> Any suggestions, comments?
black-hat, hat-nonterm? Both are pretty trivial to integrate into a
GUI, so it shouldn't be more than a few hours work. I would actually
suggest doing these two first, just to figure out how to attack this
on an easy problem.

One general point is that you seem to be proposing some new tools
here? ethereal, monad, redex. Implementing a new tool is likely to
take a lot longer than just guifying an existing one. You also might
be biting off more than you can chew with that many new tools. (of
course, if you can do it all, thats great!)

I am looking forward to using hat-gui as a real debugging tool!

Thanks,

Neil
From O.Chitil at kent.ac.uk  Fri Jul 28 15:37:57 2006
From: O.Chitil at kent.ac.uk (Olaf Chitil)
Date: Fri Jul 28 15:27:37 2006
Subject: [Hat] GUI for Hat
In-Reply-To: <20060728165923.GA5561@compsoc.dur.ac.uk>
References: <20060728165923.GA5561@compsoc.dur.ac.uk>
Message-ID: <44CA6795.60201@kent.ac.uk>


Hi Pete,

great to see another person working on a GUI for Hat.

I'd be a bit more careful with the problem description. Many of the 
tools are linked together, you can call one from the other. This is 
actually a very modular approach. Second, it is not immediate that a GUI 
makes a tool easier to learn or to use. The idea of a tool still needs 
to be understood and in how far is a GUI easier to use? Nonetheless, 
there is certainly the problem that the current text tools don't work 
under Windows and a GUI is more attractive for many users. And I'm sure 
mouse input and graphics can make a tool easier to use, but that needs 
more thought.

You list a lot of tools; several of which seem to be new. I'd 
concentrate on one or very few. Getting one that works really well is 
better than several half-working. Still, as Neil said, first providing a 
GUI for a simple existing one may be good practice to start going.

Much success,
ciao,
Olaf

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.
>
>Monad
>
>A step over debugger for do blocks. This will be similar to normal
>debuggers
>
>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.
>
>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.
>
>
>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. 
>
>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.
>
>algorithmic
>
>This will be a normal algorithmic debugger,  though I haven.t thought
>of how it will work in a GUI.
>
>Any suggestions, comments?
>
>Pete
>
>
>
>_______________________________________________
>Hat mailing list
>Hat@haskell.org
>http://www.haskell.org/mailman/listinfo/hat
>  
>

From tatd2 at kent.ac.uk  Fri Jul 28 17:58:05 2006
From: tatd2 at kent.ac.uk (Thomas Davie)
Date: Fri Jul 28 17:52:03 2006
Subject: [Hat] GUI for Hat
In-Reply-To: <20060728165923.GA5561@compsoc.dur.ac.uk>
References: <20060728165923.GA5561@compsoc.dur.ac.uk>
Message-ID: <EDD62FC8-3588-42DC-970E-EADCD4B02B13@kent.ac.uk>


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



From colin at cs.york.ac.uk  Fri Jul 28 20:30:37 2006
From: colin at cs.york.ac.uk (Colin Runciman)
Date: Sat Jul 29 04:37:32 2006
Subject: [Hat] GUI for Hat
In-Reply-To: <EDD62FC8-3588-42DC-970E-EADCD4B02B13@kent.ac.uk>
References: <20060728165923.GA5561@compsoc.dur.ac.uk>
	<EDD62FC8-3588-42DC-970E-EADCD4B02B13@kent.ac.uk>
Message-ID: <44CAAC2D.5030903@cs.york.ac.uk>

Peter,

Pleased to hear that you are planning to work towards some advances in 
the Hat tools.

> 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.

Hat-cover is pretty limited.  Just in the last few weeks I have 
implemented a new and more powerful coverage tool called hpc in 
collaboration with Andy Gill at Galois.  Hpc is not actually a Hat tool; 
its coverage records and index files are much simpler than Hat traces.  
But the approach is similar as we have a source transformation, run-time 
recording via a library, and separate viewing tools.  Hpc seems to work 
quite nicely with QuickCheck, and a simple script can be used to keep 
testing until coverage reaches a fixpoint.  Operations to combine 
coverage records (eg. union, intersection, difference) are still on our 
to-do list, but should be straightforward.  I attach a README and a 
tar-ball of our current development version.  Comments welcome.  We have 
a paper in preparation and I'd be happy to send you a copy when the 
first draft is finished.

I suppose there could be scope for an hpc GUI too! :-)

Colin R

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hpcproto.tar.gz
Type: application/x-gzip
Size: 84744 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/hat/attachments/20060728/268488c8/hpcproto.tar-0001.bin
-------------- next part --------------
HPC PRE-RELEASE PROTOTYPE
=========================

We are distributing the prototype of a Haskell tool called hpc to a few
potential users, such as yourself.  We hope you will try it, and give us
your reactions.

*** Please do NOT distribute this prototype any further. ***

Quite soon we expect to release a version of hpc for general use. It will
be open-source.

WHAT IS HPC?
------------

Hpc is a tool-kit to record and display Haskell Program Coverage. Hpc
includes tools that instrument Haskell programs to record program
coverage, run instrumented programs, and display the coverage information
obtained.

Hpc works by applying a source-to-source transformation; this
transformation also generates as a by-product a program-index file (.pix)
and module-index files (.mix). The transformed program is compiled with a
library; in addition to its usual run-time behaviour the program generates
a coverage record in a program-ticks file (.tix).  If the program is run
more than once, coverage data is accumulated to reflect all runs.

Hpc provides coverage information of two kinds: source coverage and
boolean-control coverage. Source coverage is the extent to which every
part of the  program was used, measured at three different levels:
declarations (both top-level and local), alternatives (among several
equations or case branches) and expressions (at every level).  Boolean
coverage is the extent to which each of the values True and False is
obtained in every syntactic boolean context (ie. guard, condition,
qualifier).

Hpc displays both kinds of information in two different ways: textual
reports with summary statistics (hpc-report) and sources with colour
mark-up (hpc-source).  For boolean coverage, there are four possible
outcomes for each guard, condition or qualifier: both True and False
values occur; only True; only False; never evaluated. In hpc-source
output, highlighting with a yellow background indicates a part of
the program that was never evaluated; a green background indicates an
always-True expression and a red background indicates an always-False one.

INSTALLING HPC
--------------

Requires ghc (6.4*); hmake (3.10); linux or MacOSX; bash.

There is not yet a slick installation kit.  Pick a suitable directory in
which to build hpc and try this:

1. tar xf hpcproto.tar
2. add HPCROOT=$(pwd)/hpc to your environment
3. cd hpc
4. make
5. add $(pwd)/bin to your PATH

USING HPC
---------

There is no fancy packaging of the hpc tools, just a few shell scripts.
Try this:

1. cd to the source directory for a Haskell program
   -- let's assume the main module is in Main.hs
2. hpc-build Main [build options such as -i..., -I... or -package ...]
   -- transforms for coverage and builds new executable
   -- in a subdirectory .hpc, along with index files
   -- and copies of original sources
3. hpc-run Main [args for Main]
   -- runs the transformed Main, recording coverage info
4. hpc-report Main [module-name...]
   -- writes a textual summary of coverage to stdout
   -- if no modules specified, reports on all
5. hpc-source Main [module-name...]
   -- generates highlighted <module-name>.hs.html for each module
   -- if no modules specified, generates all

See the ${HPCROOT}/test directory for examples, including a nice
way to use hpc with QuickCheck (hpc-fix).

LIMITATIONS
-----------

* The source transformation is not informed by operator priorities.
  Operands are treated as the immediate subexpressions of any chain of
  infix applications.

* Most ghc extensions are not yet supported.

* Various minor glitches -- you will encounter them soon enough!

* Developed using ghc under linux.  However, as hpc uses very few
  extensions beyond Haskell 98 it should port readily to other compilers
  and environments.

EXTENSIONS
----------

There are various ideas for hpc that we have discussed, put aside
for now, but might come back to. They include:

* extending boolean coverage to boolean arguments of Prelude functions;

* extending boolean coverage to functions and argument positions specified
  by the user;

* generalising boolean coverage to value-coverage for other datatypes;

* success and failure coverage of argument patterns;

* path coverage in the functional dependency graph;

* indicating frequency of use, not just coverage;

* combining information from more than one coverage record.

Andy Gill (andy@galois.com) & Colin Runciman (colin@cs.york.ac.uk)

19 July 2006 (revised 28 July 2006)