Debug Adapter Protocol の新しいホーム
2018 年 8 月 7 日 André Weinand, @weinand
7 月のマイルストーンの目標の 1 つは、やや不明瞭な GitHub プロジェクト に隠れていた Debug Adapter Protocol (デバッグアダプタープロトコル) を、より目立つウェブサイトに移動することでした (機能リクエスト #19636 を参照)。
このブログでは、プロトコル、Debug Adapter Protocol (デバッグアダプタープロトコル)、および移動の背景にある動機について説明します。
プロトコルによる分離の必要性はなぜか?
別の ブログ より
「Visual Studio Code は、使用するプログラミング言語に関係なく、すべての開発者向けのエディターです。」
この約束は、(少なくとも) 2 つの柱に基づいています。
- 誰もが簡単に貢献できる拡張可能なツールプラットフォームとエコシステム。
- あらゆるプログラミング言語に対して優れたツールサポートを簡単に追加できるテクノロジー。
開発ツールからプログラミング言語をサポートするということは、
- 言語の深い理解に基づく豊富な編集サポート (別名「言語のスマートさ」)。
- 編集ツールに統合された言語のデバッグサポート。
後者は驚きに感じる人もいるかもしれませんが、デバッグはソースコードが記述される場所、つまりエディターの不可欠な部分であるというのが常に私たちの確固たる信念でした。デバッグは、開発の「インナーループ」の重要な部分です。
しかし、IDE またはエディターに新しい言語のデバッガーを追加するには、標準的なデバッグ機能のリストが少なくないため、多大な労力がかかります。
- ソース、関数、条件付き、インラインブレークポイント、および ログポイント。
- ホバーまたはソースにインラインで表示される変数値。
- マルチプロセスおよびマルチスレッドのサポート。
- 複雑なデータ構造のナビゲーション。
- ウォッチ式。
- オートコンプリート (REPL) を使用したインタラクティブ評価用のデバッグコンソール。
新しい言語でこれらの機能を実装することは、多大な労力がかかるだけでなく、各ツールがユーザーインターフェースを実装するために異なる API を使用しているため、この作業を各開発ツールで繰り返す必要があることは、フラストレーションが溜まります。
これにより、次の図の青いボックスで視覚化されているように、多くの重複した機能 (および実装) が発生します。
Visual Studio Code の作業を開始したとき、私たちは常に「フロントエンド」UI を言語固有の「バックエンド」実装から可能な限り分離することを想定していました。言語のスマートさとデバッグサポートの両方でこれを行いたかったのです。
今日、私たちはこの野心的な目標を達成したと信じています。
「フロントエンド」の編集およびデバッグユーザーインターフェースを、「バックエンド」コンポーネントによって提供される言語固有のスマートさとデバッグ機能から分離できるようにする 2 つの抽象プロトコルを作成しました。
「言語の深い理解」は Language Server Protocol (言語サーバープロトコル) (LSP) によって表面化され、「デバッグサポート」は Debug Adapter Protocol (DAP) によって表面化されます。
Debug Adapter Protocol (デバッグアダプタープロトコル)
Debug Adapter Protocol (デバッグアダプタープロトコル) の背後にあるアイデアは、開発ツールのデバッグコンポーネントが具体的なデバッガーまたはランタイムと通信する方法に関する抽象プロトコルを標準化することです。
既存のデバッガーまたはランタイムがすぐにこのプロトコルを採用することは非現実的であるため、代わりに、既存のデバッガーまたはランタイム API を Debug Adapter Protocol (デバッグアダプタープロトコル) に適合させる役割を引き継ぐ 仲介 コンポーネントを設計しました。この仲介者はデバッグアダプターになり、プロトコルの名前である Debug Adapter Protocol (デバッグアダプタープロトコル) を説明します。
開発ツールが DAP を使用して、一般的な「gdb」デバッガーのデバッグアダプターと通信する方法の例を次に示します。
ユーザーはすでにデバッグセッションを開始していますが、現在プログラムのエントリーポイントで停止しており、ブレークポイントを設定 (および後でヒット) したいと考えていると仮定します。
- ユーザーは、ブレークポイントガターをクリックして、特定のソースファイルに 1 つ以上のブレークポイントを設定します。開発ツールは、gdb デバッガーにブレークポイントを登録するデバッグアダプターに
setBreakpointsリクエストを送信します。 - その後、ユーザーは 続行 ボタンを押して実行を再開します。ツールは、これを対応する gdb コマンドに変換するデバッグアダプターに
continueリクエストを送信します。 - しばらくすると、ブレークポイントがヒットし、デバッグアダプターは gdb から通知を受信し、これを DAP
stoppedイベントに変換して、開発ツールに送信します。 - この
stoppedイベントに応答して、開発ツールは UI を更新し、スタックトレースビューを表示します。これにより、個々のスタックフレームに対して表示されるすべての情報を返すstacktraceリクエストがトリガーされます。 - ユーザーが 1 つのスタックフレームを選択すると、開発ツールは
variablesリクエストでそのフレームの変数をリクエストします。
歴史的な理由 から、DAP は (現在廃止されている) V8 Debugging Protocol (V8 デバッグプロトコル) に触発された JSON ベースのワイヤー形式を使用します。この形式は、LSP で使用される JSON-RPC に似ていますが、互換性がないことに注意してください。
DAP 通信の簡単な例の後、DAP アプローチの特性を確認しましょう。
この図は、DAP アプローチの 2 つの重要な利点を示しています。
- デバッグアダプターは、さまざまな開発ツール間で共有できるため、開発コストを償却するのに役立ちます。
- Debug Adapter Protocol (デバッグアダプタープロトコル) は VS Code に限定されず、他の開発ツールの汎用デバッガー UI の基盤として使用できます。
これらの特性は、2016 年に独自の ウェブサイト で公開された Language Server Protocol (言語サーバープロトコル) の特性と似ています。
DAP の新しいホーム
今回、Debug Adapter Protocol (デバッグアダプタープロトコル) についても同様に、DAP 仕様を 古い場所 から新しいウェブサイト https://microsoft.github.io/debug-adapter-protocol と対応するリポジトリ https://github.com/microsoft/debug-adapter-protocol に移動しました。
この移動は、Debug Adapter Protocol (デバッグアダプタープロトコル) が Visual Studio Code に固有のものではないことを強調するものです。たとえば、Visual Studio も現在 このプロトコルをサポートしています。
新しい場所では、以下を提供しています。
- プロトコルの 概要と紹介。
- プロトコル仕様 (マシンで処理可能な JSON スキーマ として)。
- プロトコル仕様から自動生成された 詳細なドキュメント。
- プロトコルを実装する デバッグアダプター。
- プロトコルをホストする 開発ツール。
- プロトコルをサポートする SDK。
- バグ、機能リクエスト、およびプルリクエストは、新しいリポジトリの Issues (問題) セクションで作成できます。
古い場所 は、DAP 用の 3 つの npm モジュールのソースを引き続きホストします。
次は何?
Debug Adapter Protocol (デバッグアダプタープロトコル) はすでにしばらくの間利用可能になっているため、新しいウェブサイトへの移行は実際には開始ではなく、単に新しいホームへの移動にすぎません...
DAP の既存および将来のすべてのユーザーを、新しいホームにアクセスし、そこでコラボレーションを継続するように招待したいと思います。たとえば、次の Markdown ファイルに対して GitHub でプルリクエストを送信することにより、サポートツールと実装のリストを最新の状態に保つことができます: デバッグアダプター、 ツール、および SDK。
VS Code チームを代表して: Happy Coding!
André Weinand - Twitter で @weinand