[hatari-devel] Execution history debugger command

[Deniz Turkoglu]

On Fri, Jun 3, 2011 at 8:39 AM, Eero Tamminen <eerot at users.berlios.de> wrote:
> 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.

Depends. The most rated comment is negative about wxwidgets while some
of the rest are quite positive. I haven't done much UI so I can't
comment on the frameworks, but Qt has a long history and will probably
support most of the thing needed, even more, out of the box.

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

Having seen countless language wars I would say this also depends. I
am not a big fan of C++ either but the 'industry' seems to have
embraced it. To be honest I would also like to see hatari continue in
mainly C.

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

I haven't done thrift(facebook) but I have done protobuf (google),
they are similar and both needs a lib. I also was skeptical to this
idea first but once I wrote the code-generation for the services I
noticed how clean it made the overall API. Especially when we need to
expose a complicated interface like a debugger and want to extend the
functionality easily, I believe these protocols would work nicely.

On the other hand, there is always string based JSON, which is also
something I like. I said thrift because it comes with a network impl.
whereas in protobuf I had to write the RPC implementation.

-deniz

>        - Eero
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>