[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On torstai 02 kesäkuu 2011, Deniz Turkoglu wrote:
> For the UI, there are also other alternatives. Qt is one, and I think
> they are quite popular, but other one is wxWidgets that I know of. Of
> course both has pros and cons, and of course SO has a discussion on
> this:
> http://stackoverflow.com/questions/2886258/wxwidgets-vs-qt

Ok, that doesn't give very positive view on wxWidgets compared to Qt.
Main advantage of wxWidgets (and several other toolkits) is that they're
smaller (=have less features) and therefore programs using them start
faster.


> I haven't used many Qt backed programs but some famous ones --binary
> blobs, are Skype and Google Earth on linux (afaik), KeepassX is open
> source and is also built using Qt, and those would be ideal to have a
> look at how Qt looks like.

Well, I know Qt fairly well although I've never written any real programs
with it.  I think Qt is actually one of the best widget sets, it's
the C++ that I don't like.

Qt has two separate bindings for Python (PySide is by Nokia), but I guess
people would have the same problem with them as with PyGtk...


> For debugging I have another idea, may it be radical or not feasible.
> Browsers have been working on remote debugging for sometime, almost
> all has an option; Chrome/Webkit : Remote Inspector, Firefox : Firebug
> + Crossfire, Opera : Scope.
> 
> http://www.webkit.org/blog/1620/webkit-remote-debugging/
> http://getfirebug.com/wiki/index.php/Crossfire
> http://dragonfly.opera.com/app/scope-interface/
> 
> I think a wire protocol would benefit Hatari as well, esp. for
> debugging on devices, for instance N900.

Hatari and the PyGtk Hatari UI, including its debugger GUI, worked on
the N900 phone just fine when I last tested them.  But the debugger UI
indeed has trouble fitting to the screen even in it's current form.

You should be using Hatari's CLI console from SSH login, that way you
can use any terminal size you want to.


> I have been checking the
> options and couldn't decide on the protocol, mainly the serializer.

The current protocol is ASCII strings terminated with newlines, sent over
a socket.  With ASCII there's no need for serialization, structure/member
padding/alignment and byte swapping which makes the API easier to use
& debug:
- from higher level / script languages
- by Atari programs utilizing XBios(255) when --bios-intercept is enabled

Currently only information coming back through that socket is Hatari window
size changes (needed for window embedding), and even that comes only if
it was requested.

When adding support for breakpoints to the remote UI, there needs also to be
information sent through remote API when the internal debugger is invoked,
with something identifying why (user, breakpoint, exception....) the
debugger was invoked.

The actual debugger data comes back through a separate, one-way fifo.


> I
> am interested in using thrift (http://wiki.apache.org/thrift/Tutorial)
> to remotely debug/control/test hatari but it doesnt support events out
> of the box, which makes it a plain RPC and not fit for debugging. JSON
> is of course an option but I really like google-protobuff or thrift,
> mainly due to code generation and overall cleaner API that can be
> built with them.
> 
> Having a clean protocol also means the UI can be done in any language,
> thrift has bindings for almost every language and it would be easy to
> build an UI that supports both local and remote debugging.

Would that add an extra dependency to build process & run-time?


	- Eero