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
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
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
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
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
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
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
Hi, the API will need to know how to open each hat file for each library. However, I don't mind either way. Thanks Neil
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
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
participants (2)
-
Neil Mitchell -
Olaf Chitil