mozc is … #2

日本語を入力するために mozc を使用しているわけなのだが、これが何だかよく分からないが微妙にヘンなのがすごく気になる。たとえば「〜方が」とか「〜という奴」などと打っても、「方」や「奴」を絶対に変換してくれない。つまり、それらを文節の区切りの開始として扱ってくれない。そして文節を指定しなおしてもそれを絶対に学習してくれない。どうしてなの。ハードコーディングされてるの?

そういうわけなので SKK に乗り換えてしまった。

基本的に特に設定を変えずに使ってるが、ローマ字変換テーブルだけちょっといじった。

$ mkdir -p ~/.config/libskk/rules/default-ex
$ cp -R /usr/share/libskk/rules/default/* ~/.config/libskk/rules/default-ex/
$ vim ~/.config/libskk/rules/default-ex/metadata.json
$ vim ~/.config/libskk/rules/rom-kana/default.json
--- /usr/share/libskk/rules/default/rom-kana/default.json	2018-04-03 21:32:28.000000000 +0900
+++ /home/akahuku/.config/libskk/rules/default-ex/rom-kana/default.json	2020-01-15 02:37:30.609068213 +0900
@@ -178,11 +178,11 @@
             "tyu": ["", "ちゅ" ],
             "u": ["", "う" ],
             "vv": ["v", "っ" ],
-            "va": ["", "う゛ぁ" ],
-            "ve": ["", "う゛ぇ" ],
-            "vi": ["", "う゛ぃ" ],
-            "vo": ["", "う゛ぉ" ],
-            "vu": ["", "う゛" ],
+            "va": ["", "ゔぁ" ],
+            "ve": ["", "ゔぇ" ],
+            "vi": ["", "ゔぃ" ],
+            "vo": ["", "ゔぉ" ],
+            "vu": ["", "ゔ" ],
             "ww": ["w", "っ" ],
             "wa": ["", "わ" ],
             "we": ["", "うぇ" ],
@@ -211,6 +211,7 @@
             "yo": ["", "よ" ],
             "yu": ["", "ゆ" ],
             "zz": ["z", "っ" ],
+            "z ": ["", " " ],
             "z,": ["", "‥" ],
             "z-": ["", "〜" ],
             "z.": ["", "…" ],
@@ -235,8 +236,12 @@
             ":": ["", ":" ],
             ";": ["", ";" ],
             "?": ["", "?" ],
+            "!": ["", "!" ],
+            "~": ["", "〜" ],
             "[": ["", "「" ],
-            "]": ["", "」" ]
+            "]": ["", "」" ],
+            "(": ["", "(" ],
+            ")": ["", ")" ]
         }
     }
 }

あとは fcitx を再起動して SKK の設定から新しく作ったルールを選び直す。ただ、SKK の辞書マネージャが明らかにちゃんと動いてないっぽいのが気になる。

まあこの GUI は使わず、タイピング方式は ~/.config/fcitx/skk/rule を、辞書のリストは ~/.config/fcitx/skk/dictionary_list を直接編集すればいいだろう。ちなみに fcitx に設定を再リロードさせるには fcitx-remote -r とすればいい。

I did nothing but

今日日のソフトウェアは自動的にアップデートが行われるものが少なくないので、「何もしてないのに壊れた」ということが結構起こる。数日前から gimp が起動しなくなってしまった。

dmesg を見てみると、何やら AppArmor のエラーのようだ。また、snapcraft のフォーラムにも同じような話題が投稿されている。しかし解決には至ってないようだ。

$ snap list gimp --all
Name  Version  Rev  Tracking  Publisher     Notes
gimp  2.10.12  189  stable    snapcrafters  disabled
gimp  2.10.12  227  stable    snapcrafters  -

$ snap info gimp
name:      gimp
summary:   GNU Image Manipulation Program
publisher: Snapcrafters
contact:   https://github.com/snapcrafters/gimp/issues
license:   unset
description: |
  Whether you are a graphic designer, photographer, illustrator, or scientist, GIMP provides you
  with sophisticated tools to get your job done. You can further enhance your productivity with GIMP
  thanks to many customization options and 3rd party plugins.
  
  This snap is maintained by the Snapcrafters community, and is not necessarily endorsed or
  officially maintained by the upstream developers.
commands:
  - gimp
snap-id:      KDHYbyuzZukmLhiogKiUksByRhXD2gYV
tracking:     stable
refresh-date: today at 03:52 JST
channels:
  stable:    2.10.12 2020-01-10 (227) 429MB -
  candidate: 2.10.14 2020-01-12 (243) 179MB -
  beta:      ↑                              
  edge:      2.10.14 2020-01-10 (243) 179MB -
installed:   2.10.12            (189) 229MB -

なるほど確かに数日前に最新版になっているらしい。最新だけど動かない。ダメじゃん。というわけで

$ sudo snap revert gimp                                                                                                                                                                   gimp reverted to 2.10.12

とこんな感じでひとつ前に戻すと起動した。

become a historian

ふたばの画像掲示板で履歴機能が拡充されたので見てみる。

もともと、カタログの1モードとして過去にレスしたスレッドを集計する機能があり、それが履歴という扱いだった。内部的に考えれば、post したリモートホストが自分であるレスを含むスレッドを select するというサーバ側の SQL のクエリの話になる。

最近拡充されたのはそれとは別立てで、開いたスレッドの履歴を持っていてその一覧を表示するというものである。開いたスレッドの一覧データはどこにあるかと言うと、サーバ側ではなく、クライアントの cookie である。つまりカタログをサーバへリクエストする際にその cookie を投げると、サーバはそれに対応したスレッドの一覧を組み立てて返してくる。

これは良くない設計に思える。これに限らず、クライアント側はセッション ID だけを持たせてセッションにぶら下がるデータはサーバ側が持つほうが正道に思える箇所が色々あるのだが、長いことふたばはその方法を取らない。

それはそれとしてもう1つ不思議なのは、post した履歴と開いた履歴は分ける必要なくない? ということだ。常に post した履歴は開いた履歴の部分集合であるはずだ。これは誰でもそう思う疑問のはずで、まあまだ色々と作りかけなのかもしれない。

そういうわけなのでとりあえず見た履歴の機能をベースにして、post したスレッドを先頭に寄せるという加工を施すようにした。見た履歴を追加したり削除したりする機能はまだ作ってない。

背景色が付いている方が見たスレッド、かつ post したスレッド。そうではない方は見ただけのスレッド

introduce the passive tracking

スレッドの自動追尾というものを先日作った。これはユーザの指示によってスレッドのオートリロードをオンオフするものであり、かつスレッドの勢いに応じたリロード頻度を用いるので、いわばアクティブトラッキングと言える。作った際の感想としては例えば実況スレとかよりもむしろ寝落ちしてしまった際に有効かもしれない…というのは以前書いた。ただし寝落ちするくらいフニャフニャな状態だと、自動追尾を事前にオンにしていない場合がほとんどである。これをどうするか。

というわけで今回はそれと対になるパッシブトラッキングというものを作った。これはスレッドの消える時刻を算出した際、その消える時刻と現在の時刻との中間地点で1回タイマーを仕掛け、そこで続きを読むものだ。例えばスレッドの寿命が最低1時間保証されている板でスレッドを立てた場合、30分後に自動的に続きを読む。その次は15分後、その次は7分30秒後…という調子だ。スレッドの寿命が尽きるまで追いかける機能はそのままで、アクティブトラッキングに対して続きを読む頻度は相当抑えられる。

パッシブトラッキングは常に有効で、どのスレッドでも開いた時点から動作する。ただしアクティブトラッキングとの併存はできず、アクティブ側が優先される。

Link to anything #2

めったにないことではあるが、塩辛瓶やあぷ小のファイル名をコメントに含める際、拡張子を省略する人がいる。その場合の自動リンクはどうあるべきか。

その場合、赤福プラスはいずれのアップローダに対してもファイル名の補完を試みるようになっている。塩辛瓶の場合は、補完のための JSONP インターフェースが用意されているのでそれを使う。誰が作ってくれたのか知らないけど、ありがたいことです。

さて、あぷとあぷ小のサムネイルサービスの場合はと言うとこちらも似たようなインターフェースを用意してある。https://appsweets.net/thumbnail/up2/fu99999s.js などと呼び出すと、拡張子は js だが、そのファイルの情報が json で返ってくる。なぜ js かと言えばそれによって CloudFlare のキャッシュに乗るからである。ちなみに Access-Control-Allow-Origin: * としているので cors の制限は受けない。普通に xhr や fetch で読み出せばいい。

{
  "content": "data:image/png;base64,...",
  "board":"up2",
  "name":"fu25465.png",
  "base":"fu25465",
  "mime":"image/png",
  "size":9152,
  "comment":"",
  "dimensions":{
    "thumbnail":{
      "width":188,
      "height":250
    },
    "original":{
      "width":300,
      "height":400
    }
  }
}

こんな感じで返ってくる。content はサムネイル画像を data URI にエンコードしたものだ。

Link to anything

コメント中の自動リンク処理を整理し、100件弱くらいのテストケースを書き、それにパスするようにした。また、いくつかの既知のサイトに関して override scheme/preferred schemeの機構を設けた。前者はつまり、youtube とかは http://〜 と書かれていても https でリンクされる。逆に塩辛瓶は https://〜 と書いても http でリンクされる。後者はスキームが省略された時に選択されるデフォルトのスキームであり、ふたば内のリンクに https が適用される。

building XPI

赤福プラスはFirefox版もビルドしている。個人的にはFirefoxを常用していないのでビルドする必要性は全然ないのだけど、Firefoxで動かしてみると思わぬバグを見つけたりするのでそういう意味での必要性はある。

そういうわけで動作することを保証するわけでも何でもない扱いなので、XPIをAMOで公開はしていない。あくまでgithubのリポジトリの隅っこに置いてるだけである。

さてそのXPIをビルドする際、rest APIが用意されていてweb-extからそれを呼び出すのだが、たまにビルドが失敗することがある。なんじゃこりゃ。

Before starting, please read and accept our Firefox Add-on Distribution Agreement as well as our Review Policies and Rules. The Firefox Add-on Distribution Agreement also links to our Privacy Notice which explains how we handle your information.

つまりAMOのアドオン配布ポリシーやルールに同意してね!という感じなのだが、同意するために具体的に何をすればいいのかは伝えてくれない。心の中ではい! 同意します! と念じても何も起こらない。

結論から言えば https://addons.mozilla.org/ja/developers/addon/api/key/ に行ってAPIキーを再承認すればいいらしいのだがいやそんなの分かんないでしょ。何をしたいんでしょうか…。あるいは実際に人によるポリシー同意を定期的に行わせるためにわざと不親切なエラーを出しているのかもしれない。考え過ぎか。

several thumbnails

-bash-4.2$ php70cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromwebp
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromxpm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
-bash-4.2$ php71cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
-bash-4.2$ php72cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
imagecreatefrombmp

ここのサーバであぷ/あぷ小のサムネイルを作っているが、jpg/gif/png に加えて webp にも対応した。これがなかなか面倒くさい。というのは現在このサーバの php のバージョンは 7.2 なのだがどういうわけかそれについてくる GD には webp を操作する機能が外されているからだ。

そういうわけで仕方がないのでごにょごにょっとして対応。

force disconnect (SSH)

ClientAliveInterval 等を設定している SSH サーバに接続すると、何も入力しないまま放置している接続は適当な間隔で強制切断される。

そんなわけでそんな感じのことをググると、ServerAliveInterval 云々を設定して回避しよう的なテクニックがよく出てくるのだが、しかしサーバ側にしてみれば放置したままの接続など切断するに決まってるに決まってるわけで、放置してるのに関わらず無駄にキープアライブパケットは送ってよこすとかそんな虫のいいことは困るのである。

従って、放置した接続が適宜切断されること自体はそれは正しい。ただしクライアント側で困るのは強制切断されて即 ssh が終了するわけではなく、数分間何も受け付けない状態になったあとでやっと Broken Pipe 云々が出る動作だ。これをどうにかできないか。

man ssh して ESCAPE CHARACTERS セクションを見れば全て書いてあるのだが、ssh での接続中には特別な入力シーケンスがあり、例えば Enter、~、. の順で入力するとクライアント側からの強制切断を行える。へー。なんとなく vim での編集中にやっちゃいそうなシーケンスのようなそうでないような。

* * *

適当なマシン A に ssh で接続し、さらにそこから別のマシン B に接続したりなんかしたりの場合。マシン B との接続が切られた際に上記のストロークを入力するとマシン A との接続が強制切断されてしまいますね。うーんまあそりゃそうだよね…。そうではないんだよなー。何をエスケープシーケンスの始まりとするか(上記の例で言う “~”)は接続の際に指定できるので1段めと2段めで変えればいいかもしれない。試してない。

the mystery of video thumbs #2

var/log/ のいろいろなログや、journalctl -e や、~/.xsession-errors なんかを見てみると、確かに thumbnailer 周りのエラーが起きまくってるのだが、同時に pulseaudio とか vlc もやたらエラーを吐いている。実際 vlc に動画を食わせてみても、ふええ音が出ないよぉという状態だ。また、/run/user/1000 以下に空き容量がなくてファイルを作れないというエラーも出ている。うーんこれがなんか気になる。

$ df -h /run/user/1000                               
Filesystem      Size  Used Avail Use% Mounted on                                                              
tmpfs           581M  581M     0 100% /run/user/1000

おお…。見事に全部使い果たしている。見てみると psd が管理する chrome のクラッシュプロファイルが残っていた。これらを削除することで全てが上手く回り始めた。psd のこの機能、不要かもしれない。~/.config/psd/psd.conf をいじって無効にしておこう。

ついでに前記事の ffmpegthumbnailer を入れたり、vlc を apt で入れ直したりした。どうも snap アプリケーションというのが、なんかまだへんてこなのだ。OS のテーマを無視したり、OS のファイルオープンダイアログを無視したり、キーバインドの設定を無視したりする。へんてこすぎる。特に gimp が gtk-key-theme-name に中途半端にしか対応していない上、emacs 的なキーストロークを入力すると時々数十秒固まってしまうのが非常に困る。でも新しい gimp は snap の方でしか提供されてないんですよね…。次の LTS で apt のリポジトリの方も更新されるのかな。

というわけで結局以前誰が動画のサムネイルを作っていたのかは分からないままだが、それ以外は解決したのでまあいいことにしよう。人間は根絶やしにされずに済んだ。