Eero Tamminen <mailto:oak@xxxxxxxxxxxxxx>
1. Mai 2018 um 16:31
Hi,
FIFO command support was easy enough that I already implemented it.
See the attached patch.
Could you test building the patch on OSX & Windows and see whether
it works correctly (supports this on OSX, doesn't on Windows)?
Usage:
$ rm cmd-fifo
$ hatari --confirm-quit off --cmd-fifo cmd-fifo &
$ echo "help" > cmd-fifo
$ echo "hatari-shortcut help" > cmd-fifo
$ echo "hatari-shortcut coldreset" > cmd-fifo
$ echo "hatari-shortcut quit" > cmd-fifo
- Eero
Eero Tamminen <mailto:oak@xxxxxxxxxxxxxx>
1. Mai 2018 um 15:45
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
tin@xxxxxxxxx <mailto:tin@xxxxxxxxx>
1. Mai 2018 um 13:29
Hello all,
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?
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). 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.
Anything I'm missing?
Regards,
tIn.