Dart-code: Support reading from stdin when debugging dart command line application

[GeneTab]

Probably it's not an issue and my problem is just a lack of my VSC/dart experience but I cannot figure how I can send input to stdin when launching dart program in VSC debugger. Stdout writes to Debug Console that also allows to type in but next it doesn't pipe my input to stdin. Such a dart-code debugger behavior doesn't seem to be easy altered sounds very weird for me as stdin/stdout is pretty basic user interface. Does it mean that I cannot use stdin/stdout in dart if I want to debug command line program in VSC?

[DanTup]

Unfortunately this is not currently supported. It's something I'd like to address (it's covered by #99) but it's been low priority since nobody has been asking for it. Currently we run the Dart process in the background and just capture stdout and dump it to the console. What we need to do to handle stdin is actually run it in the embedded terminal instead.

There are some complications - for example when we run it in the terminal we can't access stdout to get the debugger port, but I did have a (hacky) proof-of-concept working on a branch (though it's rotted for a while and will probably need a lot of work).

I'll keep this issue open for better visibility of this specific request though don't know when time will allow for it. Unfortunately I'm also not sure of any good workarounds off the top of my head.

[Skylled]

Would it be easier to have a debugger port pre-assigned instead of scraped?

[GeneTab]

Thank you for quick answer no matter it's not what I'd wish to hear :( At least it can help me to stop trying to get it in a straightforward way and to start thinking about a workaround. Will keep watching this issue.

[DanTup]

@Skylled

Would it be easier to have a debugger port pre-assigned instead of scraped?

That's the the proof-of-concept on the run-in-terminal branch (which is way out of date now) did; but there are many issues with it like handling multiple debug sessions (which might be from different instances of Code) and the port being taken by other processes. I had a TODO on there to randomly generate the port, but the problem is even if I can reliably detect it's not in use at the time of launching the debugger, it might be in use by the time Observatory tries to bind to it.

Having Observatory generate the port number is generally best (it can keep trying until it finds one) but obviously communicating that back is a problem (and it seems overkill for me to open a socket for it to connect back on).

Hmmm, actually, maybe we can give the user to set this in launch.json and otherwise generate random? At least that way they can avoid the random-failure if required. I'd just need to make sure we can handle the case where we give Observatory a port that's already taken reasonably well and don't just bomb out with no helpful info to the user.

@GeneTab

Thank you for quick answer no matter it's not what I'd wish to hear :(

Another issue that could've helped here, but also isn't available yet is #271, since that'd allow you to run in the terminal yourself and then attach manually.

I'm going to tag both cases with the v2.8 milestone so they're in my list to look at once v2.7 is out (which is mostly done, I'm just hoping for some beta testing). I can't promise either will be done, but I do want to make sure they don't get forgotten as I do think this is a reasonable hole in the CLI support that should be fixed one way or the other.

[DanTup]

Tidying up the issues - I think this is entirely covered by #99 so closing as a dupe.

[raygun101]

FYI
Here's how to debug/run a dart app in a terminal shell with a launch.json setting.

"configurations": [
    {        
        "console": "terminal",
        "name":    "🦋 App App (Dart VM)",
        "type":    "dart",
        "request": "launch",
        "program": "main.dart",
        "args":    ["--assetbasepath", "${workspaceFolder}/../@path", "--host", "server.com",  "--port", "8000"]
    },