Visual Studio Live Share の活用

Visual Studio Code Advent Calendar 2018 の 16日目です。 🙂

今年もいろいろな分野で活躍してくれた VS Code でしたが、拡張として提供されている Visual Studio Live Share にもずいぶん助けられました。

Visual Studio Live Share は自分の Visual Studio から他の Visual Studio に接続してコード編集することを基本とするコラボレーション用の拡張です。ソースコード以外にも相手ホストのいろいろな機能に接続することができます。

  • ランゲージサーバーへの接続(相手の環境を使ってコード補完ができる)
  • プロジェクトファイル全体の grep 検索
  • 任意のポートにブラウザで接続
  • ターミナルに接続
  • デバッグ実行

自分の環境にソースコードや実行環境を持っていない状態でも、相手の環境を使って簡単にプログラミングを開始することが可能で、相手の環境で発生している不具合を手元で再現させながら修正するといったことが数分の準備で簡単に行えます。

接続はインターネット上に配置された Micsoroft の Live Share サーバーを介して行いますので、残念ながらクローズドな LAN 環境では使うことができませんが、代わりにルーターのポート開放など難しい設定なしに、どんな場所にいても機能を使うことが出来ます。

またクロスプラットフォームにも対応していますので、Windows から macOS に接続して動作させるようなことも可能です。ということで、いくつかの例を紹介してみたいと思います。

ランゲージサーバーとコンソール接続

Rust を編集している Linux をホストに Windows ゲストから接続して、Linux 上にあるソースコードと Rust Language Server に接続してみたところです。

補完も定義表示も相手の環境のものを使っていい感じに動作します。

Windows から Linux への bash の接続も OK で、ショートカットキーや Powerline の制御文字などもそのまま転送してくれます。相手の環境のコマンドがそのまま打てますので、Windows 側からビルドなんかもすることができます。すごい。

デバッガーへのアタッチ

ホスト側で起動したデバッガーにアタッチして、ゲストからステップオーバーやウォッチなどの操作をすることができます。 Linux / Rust / LLDB ホスト環境に Windows ゲストからアタッチした図です。

デバッグコンソールなども転送されてきます。

たとえば、Windows で動く LLDB を準備するのはちょっと大変ですが、このように Linux に接続できると簡単に環境を揃えることができます。(残念ながらゲスト側からデバッグの実行構成を起動することができませんでした。”The host doesn’t allow starting the debugger.” と言われてしまうので何かできそうな気がするのですが、引き続き調査してみます)

任意のポートにブラウザから接続

ウェブ開発をしている時に大きな力を発揮するのが、サーバーへのポート開放です。

今度は Windows で動作している Java ウェブアプリ環境に、macOS から接続してみます。Windows ホストに macOS ゲストから接続した上で、Live Share の Share Server を選択して、開けるポートを “localhost:8080” のように指定します。(この例は SpringBoot アプリケーションなので 8080 で起動します)

あとは macOS ゲスト側のブラウザから http://localhost:8080/ にアクセスするだけです。(localhost なのが不思議な感じですが VS Code がプロキシーして、ホストに接続してくれます)

macOS から Windows のターミナル(Powershell)に接続することもできますので、gradle を動かしてアプリケーションの起動停止をするようなこともでき、ソースコードを編集しながら、ブラウザで動作確認といったことがリモートで簡単にできるようになっています。

今年はお隣におられる方の環境につないでプログラムを修正したり、一番遠くは北海道・福岡間でプログラムの修正を行ったりしました。

特に不具合の修正では、それを手元で再現させる環境をつくるまでに時間がかかるものですが、VS Live Share を使えば不具合が起きている環境に接続してすぐ修正を開始することができます。(これができなかったら修正箇所が分らなかったのではないかということもありました。

VS Code はそれ自体の導入も手軽ですので、そのようなシチュエーションに出会ったら試してみてはいかがでしょうか。

あ、ひとつまえのポストも VS Code ネタですのでよければご一緒にどうぞ。。

AsciidoctorとGradleでつくる文書執筆環境

技術文書を書く環境が欲しくなり、VS Code と Gradle を使って Asciidoc 文書を執筆する環境を整えてみました。 お手軽に構成できて、300ペジくらいの文書でも耐えられそうです。

てなわけでまた来年もよろしくお願いいたします。。 🙂

Alacritty 高速ターミナルエミュレーター

Rust 方面で気になっていた高速ターミナルエミュレーターである Alacritty を Ubuntu 18.10 にて試してみました。

まだ alpha levelとのことですが、2日ほど使い続けてみましたが不具合もなく、むしろ速くてとても快適でしたので常用させていただいております。:)

https://github.com/jwilm/alacritty

Alacritty is the fastest terminal emulator in existence. Using the GPU forrendering enables optimizations that simply aren’t possible in other emulators.Alacritty currently supports macOS and Linux, and Windows.

サイトに導入手順がありますが、Ubuntu の場合はライブラリ依存関係と Rust のツールチェインを入れビルドをかけると .deb が作成されパッケージとしてインストール・することができます。

Rust ツールチェインの導入

https://rustup.rs/

curl https://sh.rustup.rs -sSf | sh

依存関係の導入

https://github.com/jwilm/alacritty/blob/master/INSTALL.md#debianubuntu

apt-get install cmake libfreetype6-dev libfontconfig1-dev xclip

Alacritty のビルドとインストール

https://github.com/jwilm/alacritty#debianubuntu

git clone https://github.com/jwilm/alacritty.git
cd alacritty
cargo install cargo-deb
cargo deb --install

起動すると設定ファイルが、$HOME/.config/alacritty/alacritty.yaml として作成されますので、画面サイズやフォントの設定をします。自分はプロンプトなどに Powerline を使っていますのでフォントの指定を Ricty Diminished w/ Powerline patched に変更しました。

font:
  # Normal (roman) font face
  normal:
    family: Ricty Diminished Discord for Powerline
    # The `style` can be specified to pick a specific face.
    # style: Regular

ということで起動してみると、、

フォントずれも発生せず日本語環境でもいい感じに動作しました!

IM による漢字入力についてはまだインライン入力ができないようですが、カーソル位置の適切な場所に吹き出し形式でインサートすることができますので、大量に日本語を入力しない限り違和感はないと感じました。

マウスエミュレーションも動作し、スクリーンショットのように tmux を動作させるとペインの移動やスクロールなどがマウスで行うことができます。

tmux(アプリケーション)にマウスを奪わせたくない場合は、一般的なターミナルエミュレーターのアサインと同様 Shift キーを押しながらマウス操作すればOKです。また OS に対するコピーアンドペーストは、Shift + Ctrl + c や v などが使えます。

検証もかねまして 2日ほどがちゃがちゃいじってみましたが、不具合を起こすこともなく快適に動作しています。すごい 🙂

(画面を覆い尽くす)Ctrl + Enter のフルスクリーンモードがあれば自分的には完璧だったのですが、issue も上がっていましたので少し経てば実装されるものと思います。

Alacritty は Windows 版も開発が進んでおり先日起動が成功したようです。

ためにし WSL(bash on Windows)で試したところ、マウスエミュレーションが動作しませんでしたが、かなり動き始めているようです。(残念ながら IM による日本語入力窓はへんな位置にポップアップしてしまいました)

Windows 上の Alacritty で WSL を起動する場合は $HOME\alacritty.yaml のシェルの指定を次のようにします。

shell:
  program: "C:\\Windows\\sysnative\\bash.exe"

Rust でつくられているということで高速で強固。自分は Rust の勉強中にてソースコードもかなり参考になりそうです。継続してウォッチしていきたいと思います。 🙂

Rust/WebAssembly でレトロシンセをエミュレートする

以前から WebAssembly を使ってレトロシンセ音源をエミュレートしてブラウザーで発声させてみたいと思っていたのですが、Rust が WebAssembly に直接コンパイルできるようになったのをきっかけに挑戦し、なんとか動かすことができました。

以下からデモを見ることができます。 🙂

Synth emurator by Rust/WebAssembly Rust/WebAssembly を使いレトロシンセサイザーをウェブブラウザ上でエミュレートして楽曲を再生します。

WebAssembly 非対応の IE を除く、PC とモバイルのほとんどのブラウザーで動作すると思います。(なお、iOS 11 Safari と Android Chrome はサンプリングレートを無視してしまう処理があるようで高め・速めで再生されています。iOS 12 Safari では修正されたようです。)

ソースコードも github にコミットしました。

https://github.com/h1romas4/rust-synth-emulation PSG(SN76489) VGM player by Rust

さて、初めての Rust だったこともあり製作に結構時間がかかりましたので顛末でも…。

何はなくとも Rust 言語を覚えなければということで、ちょうどオライリーから「プログラミング言語 Rust」が発売されたので購入。

読み進めるも若干飛ばし気味に進む展開に、まだ早かった…と先に公式ドキュメント版プログラミング言語 Rust を読みました。

プログラミング言語Rust: 2nd Edition”の日本語版PDFを作成した プログラミング言語Rust: 2nd Editionの日本語版PDFを公開しました!

550ページ以上の素晴らしい翻訳と組版で本当に感謝しかありません…。2週間ほどかかりましたが最後まで通して読むことができました(オライリーは少しできるようになってから読んだほうがいいかもしれません)

合わせて、海外のハッカーさんが Rust でライブコーディングしている youtube 動画を見ながらプログラムの組み立て方などを覚えています。こちらも非常に参考になりました。

そんなこんなで半月ほどかけて、C 言語でかかれた SN76498(PSG)エミュレーターを Rust に移植し、PCM サンプリングファイルを出力させることに成功。 🙂

このプログラムを元に WebAssembly 化していきました。

Rust 側での状態の保持

WebAssembly は JavaScript と WebAssembly 間で関数を公開し、互いに呼び出すことができますが、WebAssembly(Rust)側で状態を保持したいことがあります。

今回のプログラムの構成は JavaScript 側で AudioContext イベントを回し、発声バッファが必要になったタイミングで Rust 側で PSG をエミュレーションし 2048 サンプルごとに渡すようなロジックになっていますが、Rust 側では楽曲のどこまで再生したかなどなどを覚えている必要があります。

保持したいデーターをつめた Rust 側の構造体は次のようにしました。

struct VgmPlay {
sn76489: SN76489,
vgmpos: usize,
remain_frame_size: usize,
vgmend: bool,
buffer: [f32; MAX_BUFFRE_SIZE],
vgmdata: [u8; 65536]
}

C言語であれば static にしておけば OK ですが、Rust の static は実行前に大きさが決まっていないとコンパイルエラーとなるため、lazy_static! マクロを用いて Mutex 内にこの構造体を保持しています。

lazy_static! {
static ref DATA: Mutex<VgmPlay> =
Mutex::new(VgmPlay::from());
}

JavaScript に公開する関数では Mutex をロックした上で中の構造体を取得し、構造体に impl した関数を呼び出します。

#[no_mangle]
pub unsafe extern "C" fn play() -> f32 {
let vgmplay = &mut DATA.lock().unwrap();
vgmplay.play() as f32
}

ブラウザに実装された JavaScript はシングルスレッドであるため、関数に再入がかかったり同じ構造体を使う別な関数が呼び出されることはありませんが、Mutex につめておくと安心ですね。 このあたりは次の記事が大変参考になりました。

Rocket – A Rust game running on WASM Technically, this isn’t necessary in the case of Javascript, since there will only be one thread. Still, the type system knows nothing about that… Hence the mutex.

感謝。

メモリーの共有

JavaScript/WebAssembly 間でメモリーのポインタを共有をすることができます。今回はサンプリングバッファを割当て、Rust 側で PSG をレンダリングしたメモリーをそのまま JavaScript からアクセスして AudioContext に書き込むことで発声させています。

Rust 側でメモリーの位置を返却。

#[no_mangle]
pub unsafe extern "C" fn get_audio_buffer() -> *const f32 {
let vgmplay = &mut DATA.lock().unwrap();
&(vgmplay.buffer[0])
}

JavaScript 側で ArrayBuffer としてアクセス。

wasm_audio_buffer = new Float32Array(
wasm_memory.buffer, wasm_exports.get_audio_buffer(), SAMPLE_LENGTH);
// ...
ev.outputBuffer.getChannelData(0).set(wasm_audio_buffer);

また、楽曲データーである .vgm ファイルを http して Rust のメモリーに格納することもしています。

Rust で上記のサンプリングバッファ同様 vgm_data のポインタを関数で公開した上で JavaScript 側から fetch した値を Uint8Array として set。

wasm_vgm_data = new Uint8Array(
wasm_memory.buffer, wasm_exports.get_vgm_data(), MAX_VGM_DATA);
// load vgm data
fetch('./vgm/vgmsample.vgm')
.then(response => response.arrayBuffer())
.then(bytes => wasm_vgm_data.set(new Uint8Array(bytes)))
.then(results => {
// ...
});

JavaScript/WebAssembly でメモリーが共有できるため、余分なコピーが発生せず高速に処理することができました。今回は実装していませんが、Rust 側でサンプリングをフーリエ変換してフレームバッファメモリーにビジュアライズして書き込み、canvas に転送なんてこともできると思います。(Web Audio API にも FFT がありますが :D)

Web Audio API

WebAssembly だけの話ってわけでもないのですが、ブラウザの Web Audio API の使い方にちょっと困りました。

Rust 側としてはサンプリングを全て再生したタイミングで次のサンプリングを送り込みたいのですがそれを Rust 側で知るすべがなかったため、JavaScript 側の AudioContext の onaudioprocess イベントを使い(バッファを吐ききると発動する) Rust 側からサンプリングを渡す方式としています。

残念ながら現在 onaudioprocess イベントは JavaScript のメインスレッドを使いきる可能性があるということで非推奨となっており、Audio Workers を使えということのようです。

Audio Workers Audio workers を利用すると web worker のコンテキストで音声処理をおこなえます。Audio Workers は比較的新しいいくつかのインタフェース (2014 年 8 月 29 日に定義)によって定義されているため、これを実装したブラウザはまだありません。実装が完了すると、 ScriptProcessorNode, と JavaScript による音声処理 で述べた機能を置き換えることとなります。

が、まだ実装が進んでいないようです…。 とりあえず今のところ WebAssembly では、JavaScript のタイマーやイベントを契機に処理するという流れが良いかと感じました。

(追記:Audio Worker は仕様から消えて AudioWorklet になったようです)

というわけで、なんとなく WebAssembly でのプログラムの形がつかめてきました。 Rust も少しだけ分かってきましたのでまた何かつくってみようと思います。

WebAssembly はブラウザベンダー4社でつくってるだけあり、互換性もよく(今回 WebAssembly 的には何のトラブルもなく全てのブラウザで動作しました)、次のステップでは GC やスレッドも入ってくるということなので楽しみな技術です。

ついにブラウザーで好きなプログラムを動作させることができるようになって嬉しいす。 😀