| Re: [hatari-devel] Control socket server |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 05/01/2018 02:29 PM, tin@xxxxxxxxx wrote:
I have a question about the reasoning behind Hataris control sockets'
need for an external dedicated server.
Is there any reason to not serve/create the socket in Hatari itself
(other than additional complexity)? Is it planned to control more than
one instance from one server?
If user accidentally quits Hatari instance which is running
inside Python GUI, GUI just starts a new instance of Hatari.
I.e. the original use-case for control socket was 1:N-hataris,
whereas you're more interested about N:1-hatari.
I'm currently playing with this and it seems a bit of a hassle to have
every control application implementation set up a server (like e.g. the
PythonUI does).
You don't need to re-implement it, just use hconsole.
You start your own code from the "example.py" in tools/hconsole/.
My current testbed is a dead simple edit&continue
workflow involving Sublime and an Hatari debug script (aka "magic").
To make things easier on the Editors side, I patched Hatari for OSX
(domain socket) & Win (IP socket) to serve the connection. That way even
a simple shell script can control Hatari nicely along the lines of echo+nc.
It would be nice to simplify the control sockets for users/developers -
especially the "new" breed of text editors (Atom, Sublime, VSCode) lend
themselves nicely to send commands to Hatari. Of course the extensions
could spawn their own server, but it seems a bit of an overkill and adds
another hurdle.
If you need just write-only way to give commands to Hatari,
you don't need a socket, a non-blocking FIFO file would be
enough for that (see "man fifo").
That should work both on OSX & Linux, but I don't know whether
Windows supports something like that?
If you try that out and provide tested patch taking the FIFO
path e.g. from environment variable, I can add rest of the
stuff needed (command line option, doc updates).
- Eero