LSPの実験の続き(gopls編)

goplsでcompletionの例。

gist2a2049bbd0d0ad67e728b7a02f1b043b

行頭で、"f"とタイプしたと思っておくんなまし。

"label"はシンプルなパターン。"insertText"は無し。 "textEdit"を使うパターンかな。

"insertTextFormat"の1はPlain Textって、"insertText"が無いなら、いらないんじゃないか?

"sortText"は"00000"となっていて、以降のデータでは"00001"、"00002"、・・・と続く。 この"sortText"の中身もサーバによってバラバラな印象。ソートできれば問題ないが。

goplsは、ログメッセージを"window/logMessage" notificationで送ってくる。

Language Server Protocolでのcompletion responseの中身

Language Server Protocolのサーバ側の実装リスト

Language Servers

を見ると、同じ言語でも複数の実装が存在するものが多く、 どれを選べば良いか、悩ましい。選択肢が多いのは良い面も多いが・・・

エディタによっては(Emacsとかvimとか) Tools supporting the LSP によると、クライアント側の実装も複数あり、組み合わせの問題は発生しそうである。

LSPの利点として、エディタ側は言語非依存になるから、開発が楽ということがあるが、 サーバの実装が異るようだと、対応するのは大変ではないだろうか。

例えば、補完リクエスト(textDocument/completion)の応答の中身なんかは、微妙な違いがあるようだ。

幾つか試した結果をメモっておく。

solargraph ( https://github.com/castwide/solargraph )の場合

solargraphはruby用のlanguage server。 試したバージョンは、0.31.2。

行頭で"c"とタイプしたときの補完リストの一部。補完候補の文字列は"label"や"textEdit"=>"newEdit"が使えるだろうか。

clangd (https://clang.llvm.org/extra/clangd/ ) の場合

C++用なのか。 試したバージョンは、 clangd version 8.0.0 (tags/RELEASE_800/final)

"#"とタイプした場合のレスポンスの一部。"insertText"があるが、これはdeprecated。"textEdit"は使えるが、 solargraphの場合と異なり、入力済みの"#"は含まれていない。"kind"は15なので、これはSnippetということらしい。

pylsの場合

python用。バージョンは、0.26.1 pylsだと、"insertText"はあるが、"textEdit"は返ってこない。 "documentation"が長い。 "detail"はからっぽ。

と、様々。

  • "label"は必ず付いているのだけど、"label"に含まれる情報は、サーバにより変わる。
  • insertText"と"textEdit"は無い場合もある。
  • 入力済みの部分が補完候補に含まれる場合と含まれない場合がある。

など、クライアント側でサーバの差を考慮する必要がある。

あぁ、困った。

Language Server Protocolのclientを書く

今どきのエディタはLanguage Server Protocol( Official page for Language Server Protocol ) を使えるものなようなので、そのクライアントを作ってみようと模索中。

まず、補完(completion)の機能を使えるようになることを目標にやってみる。

最短のステップは、

  1. サーバを起動して、initialize requestを送る
  2. サーバからのレスポンスを待つ
  3. didOpen notificationで開いたファイルを伝える
  4. textDocument/completion requestを送る
  5. サーバからレスポンスを受ける

エディタで編集している場合には、3.と4.の間で、didChange notificationを送らないと、だな。

作ってみて( https://github.com/masahino/mruby-lsp-client )、試してみると、サーバの実装にそれなりに差異があり、 個々に対応が必要になりそうな気配。

画像認識の実験

飼い犬の様子を見るために、Raspberry Piにwebcamを付けて見られるようにしている。 ついでに、画像認識で色々と識別できないか、試している。

Raspberry Piで完結できれば楽そうだけど、厳しいかな、と思いつつ探してみたら、

Using Tensorflow on a Raspberry Pi in a Chicken Coop というページを見つけた。 これでやりたいことはほぼできているじゃないか、 ということで、終り。

とはならず…

そもそも、カメラ用のRaspberry Piは1なのだが、 GitHub - samjabrahams/tensorflow-on-raspberry-pi: TensorFlow for Raspberry Pi は、2か3で使えるもの。

それではと、別のRaspberry Pi2にインストールしてみたが、 サンプルがエラーで動かなかった。

単純に画像判別だけであれば、 How to Retrain an Image Classifier for New Categories  |  TensorFlow の通りにやればできるので、当面macで動かすことにした。

ただ、誤判定がまだあり、チューニングが必要かもしれない。

scintermがscintilla本体に取り込まれていた

scintillaというテキストエディタのフレームワークがある。 そのscintillaのncurses実装に、scintermというのがあったのだが、 いつのまにか、本体に取り込まれていた。バージョン3.8.0かららしい。

scintillaの最新バージョンは、4.05だが、3.x系列は、long term3 branchという形で残っている。

scintillaの4系列は、新しめのC++コンパイラが必要。scintermは3.x系列のみサポートと以前より謳っていた。

それで、名前も変わっていて、ScintillaTermからScintillaCursesとなっている。

scintermのmruby実装(mruby-scintermを作っていたのだが、折角なので、新しくmruby-scintilla-cursesも作ってみた。

GR-SAKURAでGROVEのボタンと7セグメント4桁ディスプレイを使う

ボタンは単純にINPUTの状態を調べれば良い

GitHub - Seeed-Studio/Sketchbook_Starter_Kit_for_Arduino

のサンプルを参考に。

7セグメント4桁ディスプレイは、ライブラリを使う。

Arduinoで7セグメント4桁ディスプレイLED05291Pを試す - Qiita が参考になった。

ライブラリのヘッダについて、Arduino.h はrxduino.hに変更。 inttypes.hはインクルードしない。