[hatari-devel] Execution history debugger command

[Nicolas Pomarède]

Le 01/06/2011 23:40, Eero Tamminen a écrit :
> Hi,
>
> On keskiviikko 01 kesäkuu 2011, Nicolas Pomarède wrote:
>> Le 31/05/2011 23:11, Eero Tamminen a écrit :
>>>> PS : for those who haven't tried it, just download Steem debug from
>>>> Steem website and simply run it with Wine if you use Linux or OSX.
>
> Is there any documentation or manual for it?

hi

documentation for what ? For Steem ? I don't know, honestly I don't see 
how someone used to emulation would not understand how it works in less 
than a few minutes.

>
>>> I don't like binary blobs, could you mail a screenshot of it and tell
>>> what exactly in it is nice?
>>
>> No, seriously, not again, you already asked me for this :)
>>
>> Honestly, there's no blobs in Steem,
>
> I searched the whole Steem site, but didn't find sources for it.
> Where they are?

At the time of using my Atari/Amiga, I knew a lot of useful programs 
freeware/shareware and the lack of sources never bothered me, I don't 
see why I would change my mind now. I prefer a useful program that costs 
nothing than no program at all just because I don't have the source.


>> just a zip archive with some
>> predefined directories ; unzip, run "wine Steem.exe", can't be much
>> easier.
>
> As a principle, I don't run/use things at home or work for which I cannot
> get source code for (like Flashplayer), except in (open source) emulators.
>
> (Wine isn't an emulator.  It provides Win32 API and emulates some things,
> but the x86 code it runs directly.)

Well, then as a principle, I'm afraid I can't help you there. I'm not 
asking you to install some commercial program, we're just talking about 
a very good ST emulator that many people still consider superior to 
Hatari because of its nice UI.
It won't install viruses, just test it for one hour and remove if after 
that if you prefer.


>
>> Doing screenshots won't help, there's too many functionalities to
>> describe ; you need to use it to get an idea of what it does, I think
>> the real strength is that everything can be done with the UI in a self
>> explanatory way (I don't have anything against CLI, but Monst or Steem
>> UI are really much easir to use ; combining Hatari's debuger with such
>> UI would be a great match)
>
> So Monst UI is fine as is?
>
> (that I'm somewhat familiar with and I still have the Monst manual.)

Monst UI is fine when using Monst, which was designed at a time where 
screen resolution allowed only 80x25 text. With nowadays standard, it's 
clearly inferior to what is provided by Steem, but still I think it has 
some advantages over CLI only debugger.


>
>> Regarding the UI toolkit, I don't think QT would be such a bad choice ;
>> at least it's really supported on Windows/Linux/OS X
>
> Supported significantly better than Gtk that's used by the current (remote)
> GUI?

Clearly, yes. Trolltech/Nokia put a lot of work to ensure good 
experience on all those 3 OSes.


>
> As the Qt OSX instructions mention Python:
>    http://doc.qt.nokia.com/4.7-snapshot/install-mac.html
>
> Why getting that&  Qt installed would be noticeably easier than getting
> PyGtk installed?  There's already an experimental all-in-one installer for
> it:
> 	http://sourceforge.net/projects/zero-install/files/PyGTK/2.22.0/
>
> For Windows there's already stable all-in-one PyGtk installer:
> 	http://www.pygtk.org/downloads.html
>
> (If the used Windows compiler doesn't support standard sockets, then
> somebody needs to add support for some Windows specific socket functions to
> Hatari for remote API code, but that's not an UI issue.)

Well, I think it's obviously easier to install QT than to install 
QT+python. Less dependencies for the user, he doesn't necessarily needs 
python, if the debugger's UI is built in "gui-qt/" then it's up to the 
user to choose to build this UI or not in addition to the usual "gui-sdl/"


>
>> and features all the functionnalities of modern toolkit and can be themed
>> to integrate with the user's computer.
>
> Well, if the debugger "UI" is modeled after Monst, it's supposed to look
> like an ST program, not Windows/OSX.  :-)

I didn't say the UI needed to be modeled like MonST. I meant Monst was a 
good approach some 20 years ago, but it would be limited to write today 
a debugger without having the possibility to have as many hex/asm 
windows (in any size) as the user want (as Steem does)

> If it's built into Hatari, I think it should be done with SDL[1].  This
> limits the "UI" to the size of the Hatari screen (SDL provides just one
> "framebuffer" as far as I know) which would complicate things because
> Hatari window size changes often on Falcon emulation.
>
> [1] While embedding Hatari SDL stuff to OSX UI is already working I think
>      adding Qt to that mix would be a bad idea.

Having SDL for the UI has the advantage of always being able to have all 
the settings on screen, even in fullscreen mode.

But doing a debugger limited to the size of the SDL screen is too limited.
Today, it's already complicated to add some options to the UI by taking 
care of the SDL window's size. At best we would have the same number of 
characters as in Monst, which is really limited considering most 
monitors go beyond 1280x1024.

I think we could have the usual SDL UI for running Hatari and for 
example a QT UI with external/resizable/movable windows for the debugger.


>
> As a separate program the UI could be any size and the size could be fixed
> at startup.  Instead of separate windows, it could have e.g. separate
> screens which are switched using e.g. function keys.

I prefer having separate windows than many screens, because it implies 
you can have only one screen at a time, which is often a limitation if 
you want to have several hexa/asm dump visible at the same time to 
compare them.

>
> Another problem of building it into Hatari is how you then use the debugger
> command line to do things that the UI doesn't support?  The command line
> has e.g, full debug symbol name TAB-completion.

Well, that up to the user. Use the CLI debugger for full access to all 
functionnalities, or use the UI if it features all the needed function 
for what the user has to do (with an option when running hatari such as 
debug=ui or debug=cli for example)


Nicolas