[hatari-devel] Execution history debugger command
Nicolas Pomarède
npomarede at corp.free.fr
Thu Jun 2 00:20:21 CEST 2011
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
More information about the hatari-devel
mailing list