[eval] Sys.stdout does not work when using compilation server

[haxiomic]

Reproduced with 4.0.5 and development branch

Main.hx

class Main {

	static function main() {
		trace('this will print correctly, but if using vscode build, the next line will not appear');
		Sys.stdout().writeString('this will not print if using vscode build task\n');

		// when uncommented, this will print all the previous stdout writes in the terminal of the compilation server, **not this program**
		// Sys.stdout().flush();
	}

}

build.hxml

--run Main

In vscode, run build task (Terminal -> Run build task)

When running a haxe file that uses the compilation server, i.e. haxe --run Main --connect 3000, writes to stdout and stderr will not be printed. If flush() is used the output is printed in the compilation-sever terminal rather than the main terminal.

It might seem weird to use --connect and --run together but this is the default behavior when using vscode so it's a common occurrence in that workflow (i.e if you use the vscode haxe build task this will happen)

Attached repro files, including some scripts to show the flush() weirdness

eval-stdout-bug.zip

[RealyUniqueName]

I guess this may be pretty annoying for eval-based tools.
Probably also affects stdin and stderr.
@Simn do you think this should be fixed for 4.1?

[haxiomic]

I'd argue it's worth resolving for 4.1 as it's pretty close to haxe hello world in vscode – I came across it while making an example for a newbie, simplest thing seemed to be to use the --run target so you can edit and see the program output interactively

[0b1kn00b]

I just came across this one. Any news? @Simn?

[Simn]

I don't understand how this is supposed to work. If anything uses --connect to speak to a different Haxe process via sockets, then anything like Sys.stdout() is always going to refer to the server's stdout, not the client's. IMO --connect is fundamentally flawed in this regard and unless I'm missing something, this cannot be fixed.

[Simn]

Well, actually, if I'm not hung up on the idea of referencing the actual stdout of the client, I suppose we could generalize com.print to something that ultimately behaves like stdout.