Promise and Generator #4

ぼちぼち Selenium でテストし始める。

ところで Selenium でテストする際、ブラウザの console 出力を得たい時がある。…のだけど、いまいちそのへんのドキュメントが整備されていない気がする。javascript バインディングの API はドキュメントがあるが、これはあくまでリファレンスであってハウツー的なものはほとんど書いてない。

いろいろ調べてみたところ、

const webdriver = require('selenium-webdriver');
const chrome = require('selenium-webdriver/chrome');
:
:
var loggingPrefs = new webdriver.logging.Preferences()
loggingPrefs.setLevel(
webdriver.logging.Type.BROWSER,
webdriver.logging.Level.ALL);

var options = new chrome.Options();
options.setLoggingPrefs(loggingPrefs);

var driver = new webdriver.Builder()
.withCapabilities(webdriver.Capabilities.chrome())
.setChromeOptions(options)
.build()
:
:
driver.manage().logs().get(webdriver.logging.Type.BROWSER).then(log => {
// log は Entry インスタンスの配列で、
// 各要素の message プロパティに console 出力の各行が格納されている
});

という感じでいいようだ。message プロパティは前後にソースファイル名や行番号などが付加されていたりするので、そういうものを削ぎ落とす加工は必要。

Early arousal syndrome

Windows10マシンが、いつのまにかスリープさせると数秒後に勝手に復帰し、さらに数秒後にまたスリープし、そして再び数秒後に勝手に復帰…というのを繰り返すようになった。おもしろいので1時間くらい放っておいたが1時間くらい繰り返している。

イベントビューアからカスタムビューを生成して Power-Troubleshooter を抽出し、復帰の理由を見てみたところ、犯人は VBoxSVC.exe のようだった。つまり VirtualBox だ。お前かよ。お前かよ。

わりと既知の問題のようだ。

とりあえず VirtualBox のバージョンを最新にしたら今のところ収まったように見えるが、また再発するかもしれない。ちなみに復帰の理由はコマンドプロンプトから [cci]powercfg -lastwake[/cci] でも確認できる。

npm 5

npm の CEO である Isaac Schlueter 氏から直々にメールが来て(と言っても単に npm ユーザ全員に送ってるだけだが)、npm が version 5 になったよ! パフォーマンスとか可用性とか色々良くなったから使ってみてね! ということであった。

へー、と [cci]npm install npm@latest -g[/cci] と打ち込んでバージョンが上がったのを確認し、そのまま [cci]npm outdated -g[/cci] としたところ、出て来るべきものが何も出てこない。[cci]npm update -g[/cci] としても何も起こらない。

なんか、バグみたいだ。うーん。テストとかしないのかな。

* * *

件の issue に書かれているワークアラウンドを試してみたところ、さらになんかおかしい。

各モジュール自身のディレクトリがある。例えば [cci]~/.nvm/versions/node/v7.2.1/lib/node_modules/chromedriver[/cci] とか。これに対して [cci]npm install -g chromedriver[/cci] とする。すると、モジュール自身のディレクトリは消え失せ、その代わりに自分自身を指す間違ったシンボリックで置き換えられた。もちろんこれには全く意味はなく、当然モジュールも動作しない。

あらかじめ各モジュールのディレクトリを削除した上で再インストールすればいいようだ。うーんなんか…なんか…。

Promise and Generator #3

長い時間をかけてちくちくいじっていたものが終結しつつある。キーボード入力から vi コマンド / ex コマンドの実行、その実行の完了を保証するシーケンスポイントまでの一連の関数呼び出しが Promise の連鎖によって行われるように修正した。とても疲れた。

これにより、従来あんまり綺麗な形で実装していなかった非同期処理を、それを必要とする関数内に局所的に閉じ込める形にできて見通しが良くなった。例えばクラウドに対する読み書きの場合は、それを担当するのは ex コマンドのハンドラなのだが。応答が複数回来るので、一旦途中で ex 仮想マシンの実行を中断し、wasavi 側のグローバルなメッセージハンドラで受けて、適宜再開する…のようなことをしていた。バックエンドに対するメッセージは基本的に送信と応答の 1 回のやり取りで完結するので複数のやり取りに対応できないからだ。とても不自然。

これを、ex コマンドハンドラ内で Promise を生成し、新規に開いたメッセージポートを通して複数回のやり取りをし、すべてが完了したら resolve() するようになった。とても見通しがいい。

ex コマンドのエグゼキュータも Promise ベースで動作するように書き直した。疲れた。

マップマネージャもまた Promise を使用するように完全に書き直した。これもまた疲れた。

疲れすぎてもう海に還りたい。

Using redshift

いま使っているマシンは Thinkcentre なんとかという、いわゆる一体型 PC なのだが。このマシンを仮に明るい時間にいじっている際は、ディスプレイの輝度はそれなりに上げてほしい。しかし逆に、夜更けにいじっている際は輝度は抑えてほしい。このあたりを賢く調節してくれないだろうか。

というわけで redshift を導入する。~/.config/redshift.conf を以下のような形で適当に書き(経度・緯度は伏せたが、そのとおりの数値を書く)
[redshift]
temp-day=5500K
temp-night=5000K
transition=1
gamma=1.0:0.9:0.9
location-provider=manual
brightness-day=1.0
brightness-night=0.5

[manual]
lat=*
lon=*

これをログイン時に常駐させると、時間帯によってディスプレイの色温度やガンマ値や輝度を適切なものに調整してくれる。すごい。

これを導入する際に、ディスプレイ側の設定が必要になるかもしれない。つまりディスプレイ側で色温度やガンマ値や輝度をハードウェア的に設定できる場合は、それらをデフォルト…というか「なんにも弄らないモード」に戻したり、輝度の場合は最大に設定したりしないといけない。この辺の、ディスプレイ設定のハードウェアとソフトウェアのシームレスかつ密な連携ってどうなっているんだろうか。

* * *

ソースを見てみたら、redshift は色温度・ガンマ値・輝度の3要素を制御できるわけだが、最終的にはすべての要素を掛けあわせたガンマ値にして設定しているようだ。つまりそれぞれ色温度テーブルから求めたガンマ値、R/G/Bに個別に指定できるガンマ値、R/G/B一律に指定するガンマ値という扱いになっている。

cVim

Chrome に cVim を入れて常用ブラウザとしている。そして、多少 cVimrc をいじって、その中に編集可能な要素内で [cci]Ctrl+H[/cci] が押されたら、[cci]deleteChar[/cci] 関数を呼び出すような設定にしている。

…のだが、最近になってこれが動かなくなってしまった。キャレットの左の 1 文字が選択されるのだが、削除されない。選択されたままになる。

デバッガで追ってみると、選択した後にその選択範囲を削除しようとする箇所で、selection オブジェクトの type が Range であれば削除する…となっている処理がある。しかしナウい Chrome では、編集可能な要素の selection.type は Caret が返されるようなのだ。なので、削除処理がスキップされる。

まあ、そのうち直るんでしょう。cVim のソースは現在でもそれなりにメンテされている。

Mount a windows share folder #2

以前、Windows10 マシンのけっこう余っているハードディスク容量を活用するため、ディレクトリを Xubuntu 側に公開したことがあったのだが、実はそれをやって以降、ファイルマネージャである Thunar の調子がとても良くない。よく固まるようになってしまった。

固まる原因が必ずしもこの共有だという明確な証拠はないのだが、試しに共有をオフにすると安定するので、まあそういうことなんだろう。

さてどうしよう。共有のプロトコルは CIFS である。これがダメなのか? もしかしたら NFS にすれば安定するだろうか。というわけで調べてみたのだが、Windows マシン上で NFS サーバを動かすというソリューションが意外に少ない。まあ、でも、そりゃそうですよね…。

探してみたところ、

などがある。github のやつは、もともとは別の方が SourceForge で公開されていたものの fork の fork みたいな感じ。

この他は、大昔の SFU にそういう機能があったりしたようだが昔のこと。Windows Server であれば標準で NFS サーバになれる、と思うがうちのは Server じゃない。cygwin か、あるいは今流行りの Windows Subsystem for Linux (WSL) にもありそうだが多分 Windows のネイティブなサービスとしては動かせない。

ということで上記の3つを試したいのだがそれでも面倒くさいなあ。前述の通り、できればサービスとして常駐する機能を持っているものがいいのだけど。

Sentence of Acquittal

Unistring という javascript のライブラリを公開している。これは自分で言うのも何だが本当に重要なライブラリで、web アプリケーションにおいて BMP の範囲を超えていたり結合文字が混じりまくったりした Unicode の文字列を扱うとしたら、これがないと本当にどうにもならない。絵文字ひとつ扱えない。

このライブラリは UAX #29: UNICODE TEXT SEGMENTATION で定義される、Unicode の文字列を書記素クラスタへ分割する処理(Grapheme Cluster Boundaries)と、単語に分割する処理(Word Boundaries)を行う。実は UAX#29 ではこれ以外に、文に分割する処理(Sentence Boundaries)とハングルにおける字母の分割ルール(Hangul Syllable Boundary Determination)も定義されているのだが、それらは wasavi では使わないので実装していない。

実装していなかったのだが、issue が来てしまったので Sentence Boundary をえいやと実装した。しかし実装しといてなんだが、この機能実用になるんだろうか。UAX#29 でも Sentence Boundary は「文の抜き出しは字面を追うだけでは不十分で、ほんとは構文解析しないとダメだよ。でも殆どの場合はシンプルなやり方でも抜き出せるから一応紹介しておくよ」という位置づけでしかない。

それはそれとして、ググってみても UAX#29 をだいたい実装している javascript ライブラリというものが見つからないのだが(書記素クラスタに分割するものはある)、どういうことなんだろうか。誰も興味ないのかこの手の話。

Conversations of the Beasts

けものフレンズのスレが虹裏に立ち、「○話に誰それがなんとかって言った」とか、「誰それが○話で何をした」とか、そういう話になった時、手元で簡単に確認できると嬉しいわけで、すべての会話をテキストに起こした。これがあることで、たとえば各話中に「すごーい!」的なセリフは
$ grep -c "すっ\?ご" [0-9]*.md | awk -F: '{print $1,$2;c+=$2}END{print "total",c}'
01.md 8
02.md 3
03.md 13
04.md 8
05.md 20
06.md 7
07.md 7
08.md 11
09.md 8
10.md 2
11.md 6
12.1.md 1
12.md 6
total 100

回ある…などとすぐわかる。すごい。

kemono-friends-dialogs
https://github.com/akahuku/kemono-friends-dialogs