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

Talk about news #3

PhoneticNews を拡張し、Yahoo! Japan が提供する500以上のフィードにも対応した。そのために、フィード一覧のページに専用の content script を仕掛けるようにした。

ところで Chrome の拡張から任意のドメインにリクエストを飛ばすには、基本的にはマニフェストの permissions にその URL パターンを予め記述しておく必要があるのだが、yahoo 上のフィードにはそれが必要ないようだ。多分 cors に対応しているんだろう。

それはそれとして、Yahoo!上のフィードのリスト上に、こんな感じに各フィードにチェックボックスが追加される。また画面右下にはコントロールパネルが表示される:

で、適用を押すとこんな感じで念を求められ:

承認すると読み上げるフィードに追加される。

GRADIUS on GAE

ここの xrea サーバでは cron に任意のコマンドを登録できるのだが、間隔に制限があり、最短 1 時間は空けないといけない(その代わり 12 個までの個別のコマンドを登録できるので、頑張れば 5 分おきにまで縮められるが、まああんまりやりたくないバッドノウハウである)。多分この制限はコンパネ上だけのものなので、ssh でログインして直接 [cci]crontab -e[/cci]すれば迂回できるんじゃないかな…と思わなくもないが、試してない。

そんなわけで、cron 代わりとして xrea とは別に Google App Engine のアカウントを利用している。こちらにも cron サービス的なものがあり、間隔の制限はないので 1 分おきに xrea サーバにちょっかいを出させるのだ。ちなみにこの GAE アカウントの表向きの顔は HTML5 版の GRADIUS なのだった。

さて、ちょっと前に Google さんからお手紙を頂いた。それによると GAE で python2.5 で動かしてるインスタンスは削除しちゃうからアップデートしてちょということだった。なるほど。確かに GAE 上の GRADIUS は python2.5 のインスタンスで動かしている。

でもそもそも GAE のアップロードの仕方とかもう全くさっぱり何もかも覚えていないよ。1 から調べ直したところ、このへんに書いてあるとおりに進めればいいようだ。以前は appcfg.py でコントロールしてた記憶があるが gcloud というコマンドに置き換わっている。

ということで、直した。

Switching audio devices

ちょっと前に iBUFFALO USBオーディオ変換ケーブル というものを買った。これはマシンのイヤホンジャックがぶっ壊れていた場合のための保険として買った。

しかしイヤホンジャックは無事だったので使わずにいた…のだが、もったいないので使ってみることにした。感慨深いことに Xubuntu であっても単に刺すだけで使える。

音質は、たしかにマシン本体のイヤホンジャック経由よりもクリアになるようだ。2000円やそこらの製品でこれなのだから、ちゃんとした USB-DAC ならもっとすごいのかもしれない。この手のデバイスで泥沼にハマる人がいるのもわかる気がする。

ところで音質よりも副作用的に嬉しい点があり、マシン内蔵のスピーカーとイヤホンの出力切り替えがソフトウェア的に行えるようになった。イヤホンジャック経由だといちいち抜き差ししないといけなかったが、サウンドの設定パネルから切り替えられる。[cci]pacmd[/cci] コマンドで端末からも切り替えられる。