VSCode を手元でビルド・デバッグしてみた
VSCode を手元でビルド・デバッグしてみました。
とても簡単でした。
多分、node.js での開発に慣れてる人なら何にも困らないレベルです。
基本的には、ほとんどここに書いてあります。英語だけど。
How to Contribute · Microsoft/vscode Wiki · GitHub
なので、 Windows 上での作業の場合だけを、簡単に説明します。
準備
次のものをインストールしておきます。
- Visual Studio 2015 (C++入れとけよ)
- Python 2.7 (3.0系はダメ！わかります)
- Node.js/npm (とりあえず最新入れとけ)
Python はパス通すか、PYTHON 環境変数云々って書かれてるけど、要は、VS2015 ではデフォルトでハブられている、 C++ さんと Python さんをちゃんとインストールしておけよっていう。(F#は要らない)
Node.js さんは本家から最新入れましょう。npmはおまけで付いてくる奴でOKです。
npm install
node.js 系の開発なら最初にやる奴ですね。依存パッケージを全部自動的に取ってきてもらう。
ただし、なんか、scripts の下にある奴を実行しろって書いてあるので、従います。
cd vscode scripts\npm install
C++のビルドとかも走るので、ここはちょっとだけ時間がかかりますが、僕の環境では、5分ぐらいでした。
ビルド
VSCode を自分でどうにかしようと思ってるような人は、既にインストールしてると思うので、安定板 or Insider 版の VSCode を起動して、 vscode のフォルダーを開きます。
で、 Ctrl+Shift+B でビルドが開始されちゃいます！
劇的に簡単。
僕のマシンでは、2～3分ぐらいですかね。
実行
実行というか、デバッグするには、デバッグタブを開いて、起動モードから、"Launch VSCode" を選んで、実行するだけです。
おぉぉ、OSS Dev という名前が輝く、VSCode 様が簡単に現れるではないですか！
この状態で、適当なソースにブレークポイントとか張ると、普通に止まりますよ。
例えば、 src\vs\editor\contrib\find\common\findController.ts には、 replaceAll なんて関数が定義されていますが、ここにブレークポイントを張ると、全置換とかやったタイミングでブレークポイントで止まります。簡単すぎるだろw
まとめ
何にもやってないに等しいですが、このハードルの低さ。正直、びっくりしました。
何が素晴らしいかっていえば、VSCode 自体のセルフ開発環境として、VSCode が立派に機能することですね。ここまで来るまでには開発者の方々の大変な努力があったことは事実ですが、我々、ニワカ VSCoder は、この環境にただ乗りして、 VSCode をデバッグしたり、修正したりして、一日も早く、コントリビュータとしてデビューできるように頑張りましょう。
MX Anywhere 2 色違いも買ってみた
ロジクールのコンパクトマウスの最上位モデル、MX Anywhere 2 にカラーバリエーションが増えたということなので、早速、「ストーン」という色を買ってみました。
もともと、これの初期モデルというか、ブラックを使ってたので、今更、特に使い勝手で言及することなど何もないのですが、簡単に言えば、何の不満もないマウスですね。
ホイールはフリースクロールにもカチカチ感のあるスクロールにもなりますし、全体のプラスチック感は従来品に比べてチープに感じることもあるでしょうが、軽量になったと思えば、毎日使うものとしては全然悪い感じではないです。
ワイヤレスマウスで、ロジクールのUnifyingという独自形式か、Bluetoothのいずれかで接続できます。マルチペアリングで、3台のPC/Macとペアリングできます。
ロジクールといえば、昔は、悪名高い、SetPointというソフトウェアが付属していたのですが、今は、そんなダサくて酷いソフトウェアは付属しておらず、Logicool Options という、それなりの見た目のソフトウェアが付属しています。
面白いのは、1台のマシンに2台をペアリングしたりすると、
みたいにマウスのショーケースみたいな表示になることですかね。こういうところで Apple 的な配慮を行ってくれるようになったのは本当に良いです。
さて、まぁ、質感に関しては、十分に良いのですが、一方で、いわゆる、ベージュですし、光の角度によっては、こんな感じに見えてしまい、ブラックよりはチープに見えることもあるかもしれません。
ただ、机の上を白基調にしたいのであれば、良い色だと思います。
一緒に買うと良いもの
さて、このマウス、基本的には、ワイヤレス・内臓バッテリーなので、いつかはバッテリーを充電しないといけなくなります。
で、充電しながらでも使えるのですが、付属のケーブルは微妙に硬く、このケーブルで充電しながら使うと、せっかくのマウスの軽さが著しく毀損されます。
そこで、iBUFFALO USB2.0ケーブル(A to microB) スリムタイプ ホワイト 1.2m BSMPC12U12WH を買うことをお勧めします。
このケーブルは、非常に細くて柔らかいので、このケーブルで充電していても、ケーブルの重さを感じることはほとんどないでしょう・・・
って、そこまでしてワイヤレスマウス買うの？
って思った人にはこのマウスはお勧めできませんw
WSL (Bash on Windows) で Windows のプログラムが実行可能になったので遊んでみた
本当は、先週ぐらいに
Announcing Windows 10 Insider Preview Build 14951 for Mobile and PC | Windows Experience Blog
があって、この Build 14951 で、Windows側のプログラム呼べるようになったよんって書いてあったんだけど、待てど暮らせど、アップデートが落ちてこず。結局、
これが落ちてくるまで待つことになりました。
パイプが動く
さて、この仕組みで、実行できるだけなら普通なんだけど、ちゃんとパイプが動く。
なので、Windows 側の dir の結果を Ubuntu 側で grep したりできる。
まぁ、Windows の dir は内部コマンドなので、 cmd.exe を経由しないといけませんが、そうすればいいだけです。
素敵です。逆向きも当然。
GUIアプリを起動してみる
notepad.exe を起動するとどうなるでしょうか？
おや、 cmd.exe と違って、ターミナルに制御が戻ってきません(プロンプトが出てない)。
つまり、標準出力・入力系は繋がりっぱなしですね。これ。
そして、この状態で、Ctrl-C を押すと、ターミナルに制御が戻ってきます(プロンプトが表示される)。
ただし、 notepad.exe は死にません。起動しっぱなしです。
どういうこと？っていう感じで、もう一度、 notepad.exe を起動して、 ps でプロセスを見てみると、
Windows のプロセスは、 /init 経由で呼ばれてるんですね。
で、Ctrl-C で、 SIGINT を送り付けたら、 /init だけが死ぬと。
init が死ぬって結構、致命的に聞こえますが、まぁ、この init はそういうやつじゃないと。
で、 notepad.exe は死にませぬ。
なので、自分で起動したプログラムの面倒を自分で見切れないという意味では辛いかもしれません。
で、なんで Windows のプログラムが動くの？
スペシャルバージョンのカーネルが動いてます！・・・っていうわけじゃないです。
そもそも、この辺のバイナリは、普通の Ubuntu のものと同一ですしね。
何が起きているかというと、実は、スゲー昔に書いたことあるんですが、
の中に、追記で、 binfmt_misc って奴の話があります。これは、Owin の話ですね。
要は、Linux カーネルには、実行ファイルの先頭のバイト列を見て、そのファイルを解釈するプログラムを起動する仕組みがあるんですね。シェルスクリプトの #!/bin/sh とかの拡張だと思えばわかりやすい。
mono とか、 Wine はこの仕組みを利用して、 Linux 上で、 exe が直接動くような感じを実現しています。
細かいことはさておき、この仕組みで、 /init に引数として、 /mnt/c/Windows/System32/notepad.exe が渡されて起動するんですね。なので、実際のプログラムの実行処理は /init に任されてると。WSL の /init は完全に Windows の息のかかったプロセスなので、あとは・・・。
この辺のことは、下の記事に詳しすぎるぐらいに書いてあるので、英語で長文読むのが嫌じゃない人は、是非、読みましょう。
Ubuntu 16.04 on Windows 10 Insider Preview 14936
以前にこんな記事を書きました。
で、この時は、Ubuntu 14.04相当だったんですが、このたび、Insider Preview Build 14936で、Ubuntu 16.04が使えるようになりました！
Windows Subsystem for Linux (WSL) Updates
WSL will install Ubuntu version 16.04 (Xenial) instead of Ubuntu 14.04 (Trusty) in an upcoming release. This change will apply to Insiders installing new instances (lxrun.exe /install or first run of bash.exe). Existing instances with Trusty will not be upgraded automatically. Users can upgrade their Trusty image to Xenial using the do-release-upgrade command. Full WSL release notes can be found here.
適当に翻訳すると、
WSL は、次のリリースから、Ubuntu 14.04 (Trusty) の代わりに Ubuntu 16.04 (Xenial) をインストールするようになります。
インサイダーの方が、新規インスタンスをインストールする(lxrun.exe /install もしくは、最初の bash.exe の実行)場合にこの変更が適用されます。
既存の Trusty のインスタンスは、自動的にはアップグレードされません。TrustyのイメージをXenialにアップグレードするには、 do-release-upgrade コマンドを使ってください。
...
みたいな。既存の14.04は、普通の Ubuntu のように、 do-release-upgrade すればいいわけですね。
最近は、cmd.exeのコンソール機能も地味にまともになってきて、悪くない感じになってきました。とりあえず、
chcp 65001
しておけば、Unicode対応になりますし、フォントもConsolasとかも選べるようにはなります(日本語が表示できなくなりますけど)。
もう、最近は、ちょっとLinuxサーバーに接続ぐらいだったら、 cmd.exe の上から直接作業しても困らないぐらいにはなってきましたね。良いことです。
