Robustness of stdout parsing

オープン
  • 何か問題がありますか？
#13 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
r
領域
devtools

調査の方向性

read_until_browse_prompt と browser() コマンドの経路から始め、標準的な R 式が "n" や "cont" などの制御シンボルとどのように区別されているかを調べます。評価された式の出力をブラウザプロンプトと取り違えられず、コマンドの出力が提案された capture and pipe mechanism を通じて返されれば完了です。この issue ではファイルもテストも指定されていません。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
R
スター
20
フォーク
2
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dgkf/debugadapter のほかの issue

dgkf/debugadapter の issue をすべて見る

似ている issue

R の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。