dgkf / dgkf/debugadapter

Robustness of stdout parsing

Open
#13 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
R
Stars
20
Forks
2
PR merge metrics
No merged PRs in 30d

Description

I think the mechanism of reading stdout from the process that runs browser `browser()` - which is currently done using `read_until_browse_prompt` function - should be replaced with something else. It is possible that something calls `print("Browse[1] ")` and then things would break badly. Probably this does not have too high priority but I wanted to mention it.

A solution would be that the process that runs `browser()` does not redirect its output directly, but that it gets the commands that it should execute wrapped in a function.
For example, the `browser()` process does not get the expression `print(x)` into its stdin, but `send_back_to_child(print(x))`. And the `send_backt_to_child` (should have a weirder name to avoid any name clashes) captures the output and then sends it back to the child via a pipe.

What do you think?

To do this, one would have to check before sending the command whether the command that is being sent is a standard R expression to be evaluated or a browser control symbol such as `"n"` or `"cont"` etc.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.