(optionally) make it possible to talk to tcpser via pipes rather than sockets

[mrdudz]

It would be really nice if VICE could talk to tcpser via stdin/stdout (but still using the IP232 protocol). The big advantage would be that this way VICE has full control over when tcpser is started, and with what options. We could provide a default config and it would "just work" (many ppl have problems setting this up correctly).

[go4retro]

Can you provide more clarity? tcpser can be started from VICE today, and the command line args can be specified on the arg line.

[mrdudz]

Hu? How would you "start it from VICE"? I don't see how that can be done.

BTW, another big advantage would be that tcpser doesnt get confused by VICE connecting/disconnecting multiple times (which has been a constant annoyance at least on windows).

[go4retro]

On 4/24/2023 3:52 PM, Bob Andrews wrote: Hu? How would you "start it from VICE"? I don't see how that can be done.

VICE can start tcpser by fork/exec of "tcpser" with the respective command line args. It would require changes to the VICE source code.  But, I believe so would modifying tcpser to run from stdin/stdout, as VICE currently requires a socket connection.

BTW, another big advantage would be that tcpser doesnt get confused by VICE connecting/disconnecting multiple times (which has been a constant annoyance at least on windows).

That should be fixed in the last build.  But, if not, the same thing can be done via fork/exec.  the forked subtask can simply be cancelled, which would be the same way a stdin/stdout version of tcpser would be used.

…

— Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGXYKSO4OB7UUIP3JXWRWX3XC3R2LANCNFSM6AAAAAAXJTPUHM>. You are receiving this because you commented.Message ID: ***@***.***>

-- RETRO Innovations, Contemporary Gear for Classic Systems www.go4retro.com store.go4retro.com

[mrdudz]

It would require changes to the VICE source code

doh. Sure. Everything can be done then >_<

But, I believe so would modifying tcpser to run from stdin/stdout

We already do this for printer output, so most of the functionality is already there. It would also be consistent with how other tools are being used via piping.

That should be fixed in the last build.

Apparently it is still a problem... Unfortunately the ppl reporting those have not been very helpful with debugging this (and in trivial tests it works)

But, if not, the same thing can be done via fork/exec. the forked subtask can simply be cancelled, which would be the same way a stdin/stdout version of tcpser would be used.

You must have misunderstood what i ment. The point is that like this the subtask would only be started once, and it doesn't matter if VICE start/stops using the pipe, tcpser wouldn't even notice.

[mrdudz]

We already do this for printer output, so most of the functionality is already there. It would also be consistent with how other tools are being used via piping.

correction: it is already all there, there is even a default setup that pipes from/to netcat. So no changes would be required in VICE :)

[go4retro]

On 4/24/2023 4:38 PM, Bob Andrews wrote: We already do this for printer output, so most of the functionality is already there. It would also be consistent with how other tools are being used via piping.

It should not be too tough to denote a port value that signifies stdin/stdout (like - or something, I'll have to check how other UNIX apps denote stdin/stdout in lieu of a port).  It's a small change, just want t make sure it'll have any value.

That should be fixed in the last build. Apparently it is still a problem... Unfortunately the ppl reporting those have not been very helpful with debugging this (and in trivial tests it works)

That's unfortunate.

But, if not, the same thing can be done via fork/exec. the forked subtask can simply be cancelled, which would be the same way a stdin/stdout version of tcpser would be used. You must have misunderstood what i ment. The point is that like this the subtask would only be started once, and it doesn't matter if VICE start/stops using the pipe, tcpser wouldn't even notice.

Yes, I misunderstood.  Yes, tcpser would not notice.  However, VICE would need to reset all of the controls every time the user opens the serial port (DTR, etc.), as the previous session may have left things in a weird state. Though, I still don't understand why VICE doesn't just save off the open tcpser port and re-use it instead of trying to open a new one. I suggested this as the way to address the issue initially (have a flag on whether the port has been opened.  If not, open it, but if so, just re-use it and reset the control lines.  That option was discarded earlier for some reason.

…

— Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGXYKSNSRA2RSUOPWY52Q3DXC3XETANCNFSM6AAAAAAXJTPUHM>. You are receiving this because you commented.Message ID: ***@***.***>

-- RETRO Innovations, Contemporary Gear for Classic Systems www.go4retro.com store.go4retro.com

[mrdudz]

It should not be too tough to denote a port value that signifies stdin/stdout (like - or something, I'll have to check how other UNIX apps denote stdin/stdout in lieu of a port). It's a small change, just want t make sure it'll have any value.

"-" is often used for stdin/out instead of a file name, i dont know if there is a common convention for "port".

Though, I still don't understand why VICE doesn't just save off the open tcpser port and re-use it instead of trying to open a new one. I suggested this as the way to address the issue initially (have a flag on whether the port has been opened. If not, open it, but if so, just re-use it and reset the control lines. That option was discarded earlier for some reason.

The biggest problem there is that this code is rather complex, and even arch specific - which makes it a pain to debug. (For example this reconnection problem does not exist in Linux at all). Using pipes is trivial compared to that, there is hardly anything that can go wrong. So yes, of course, the network code in VICE needs to be fixed too. However, none of us is in the position to do this atm.

[go4retro]

I just committed a revision that will accept - for -v port number. It looks like it maps data to STDIN/STDOUT, but I don't have a nice test program to try as yet. I hope you can test.

[mrdudz]

For example this reconnection problem does not exist in Linux at all

I found out this is not true... there are also problems on linux, i will do more testing and open another ticket eventually (i am not sure what exactly happens at this point)

Will try to test the pipes thing...

[mrdudz]

Unfortunately it does not work in VICE - but i cant really tell if the problem is in VICE or tcpser.... a test program is needed so we can rule out one or the other. It's a bit annoying to debug both at the same time :)