2017/04/05 9:31 pm
Save to #4
Uncategorized, ,

いくつか気なる点が出始めてきた。

Kokoni のコンテキストメニューは、image/video/audio に対するものと link に対する物の両方に対して表示するようになっている。ここで、例えば img 要素を含んだ a 要素に対してコンテキストメニューを出したとき、保存対象は a.href か img.src か? という難しい判断を迫られる。

Save file to ではこういう場合、リンク先を保存というメニュー項目と画像を保存というメニュー項目を両方出現させる。しかし Chrome の拡張の場合、それは不可能なのだった。コンテキストメニューのルートに複数のメニュー項目を追加しようとした場合、ルートには拡張の名前の項目だけが追加され、拡張側から追加しようとした項目はその下に迂回されてしまう。

つまり通常はコンテキストメニューから “ここに保存” -> “Pictures” というルートを辿るのが、上記のマークアップの場合は “Kokoni” -> “ここにリンクを保存” または “ここに画像を保存” -> (いずれかの)”Pictures” というように展開されるメニューが1段増える。

リンクに対するコンテキストメニューを出した時はそういうものだと受け入れるとして、問題はどうも拡張から生成できるメニュー項目数に妙な制限があるらしいことなのだった。つまりツリーに対応するメニュー項目群を2倍定義しないといけないのだが、そうすると簡単に制限に引っかかる可能性が高くなる。メニュー項目をより動的に生成できるようなイベントが用意されていればその都度必要とされる項目だけを生成することで解決するのだが、chrome のコンテキストメニュー API はいまいちその辺の融通が効かない。

もうひとつ、参照したディレクトリの履歴をコンテキストメニューに含めるようにしているが、現状では単純に最後に参照したディレクトリを先頭に持ってくるようにしているので、例えば 9 割方 Pictures/けものフレンズ に保存しているが、たまに Pictures に保存しただけで履歴の順番が変わってしまう。履歴のソート順として参照回数順、辞書順などのオプションを実装する必要がある。

2017/04/02 9:17 pm
Save to #3
Uncategorized, ,

インストール手順を英語でも書いた。

Enjoy Kokoni!
https://appsweets.net/kokoni/index-en.html

同時に、basename を省略してアクセスしても、accept-language ヘッダの先頭が ja かどうかで適宜振り分けるようにしたのだが。Chrome の場合 $ LANGUAGE=en google-chrome などとしても accept-language ヘッダの内容は変化しない、Firefox の場合は逆に言語設定で ja を先頭にしているにかかわらず accept-language には ja が追加されない…など、それぞれがなんか妙な動きをして困る。

困るといえば、テストのためにいろんな画像を虹裏から落としているのだが、割と同じ画像を保存してしまうことがある。こういう場合に Kokoni 側で面倒を見るべきだろうか。でもそれはそれで面倒くさいなあ…。

やっぱりやめた。

$ fdupes -fdN ~/ピクチャ/けものフレンズ

すればいいだけのことだ。

それにしてもこの手の拡張が Chrome にも欲しいという意見は2012年頃からあったのに、なんで誰も作らなかったんだろう…。

4:15 am
Save to #2
Uncategorized, ,

Chrome Web Storeに公開した。

それから、詳しいインストールの仕方を書いたページを作った。しかし絶対パスや相対パスというむつかしいこんぴゅーたー用語が万人に通じるのか若干不安がある。Chrome の filesystem まわりの API がフルパスの扱いに関してぶっ壊れっぱなしで、スクリプト側で良きに計らえないのが悪い。

2017/03/29 6:53 pm
Some purchases
Uncategorized

そういうわけで、左右のバランスが壊れているイヤホンを破棄し、新調した。SONY MDR-XB50というやつだ。

実を言うとオーディオ機器の良し悪しというのは全然さっぱりわからないので、別にこれが欲しかったとかそういうわけではなく、単に Amazon を見てて適当に決めただけだ。

それから、万が一イヤホンではなく PC の方に問題がある可能性もあるのでiBUFFALO USBオーディオ変換ケーブルなるものも注文した。これはいわゆる USB DAC と呼ばれるもので、USB 経由で音声データを取り出すのだが D/A 変換が PC の外で行われるためにノイズが軽減されるのだそうだ。ただしこの手のデバイスのお値段は正にピンきりで、注文したのは相当下のグレードだ。

で、とりあえず直接イヤホンを PC につなげてみたところ、バランスは元に戻ったので、やっぱりイヤホンが断線していたみたいだ。そういうわけで USB DAC は別に使わなくてもいいかなということに。別にノイズが乗るわけでもないし。

ついでなので、4GB のメモリも注文した。現在の PC のメモリも 4G なので、合わせて 8G だーわっほいと思っていたのだが、開けてみたらなんと 2G+2G の構成なのだった。そういうわけで 8G ではなく 6G になってしまった。

2017/03/28 7:50 pm
Save to
Uncategorized, ,

Firefox に Save File to という素敵な拡張がある。これはリンクや、メディアファイルに対するコンテキストメニューにホームディレクトリの任意のディレクトリツリーを展開し、選択したメニュー項目のパスへ直接ダウンロードする機能を提供する。つまり、とりあえず ~/Downloads に落として、落とし終わったら適当なところに移動…という手間を省ける。

似たようなものは Chrome にはないのだろうかと探してみたのだが、ないようなので作った。

本家には保存ダイアログにまで割り込んだり、サブメニューを左右交互に展開させるような芸の細かいオプションがあるが、残念ながら Chrome の拡張にそこまでの自由度はないので勝手に移植物としてはかなり不完全。

2017/03/22 7:27 pm
Promise and Generator #2
Uncategorized, , ,

そういうわけでちまちまといじっている。

とりあえず vi コマンドを回す部分に関しては修正した。これで非同期の処理だろうが同期の処理だろうが不自然なく呼べるようになった。それはいいのだが、vi コマンド群は本丸ではない。qeema が発生するキーボードイベントから、各 vi コマンドのハンドラに達するまで、せいぜい 4〜5 の関数がネストするだけであり、ただそれを Promise を使うようにすれば済む。

難しいのは ex コマンドの方なのだった。

ex コマンドは、ex コマンド列をコンパイルして中間コードの配列に落とし、それを逐一実行するという構造になっている。なので、修正するとしたら ex コマンドごとに Promise をつなげていく、ex コマンド自体はそれぞれ resolve() でコマンドの終了を通知するといった形になる。

ただいくつか面倒な点がある。

  • write、read、edit などバックグラウンドに処理を投げるファイルシステム系のコマンドは、読み書きの進捗イベントをバックグラウンドから複数回返される。従来は、この複数回返されるメッセージというのは ex コマンドのハンドラの外で処理していた。というのも非同期的な ex コマンドを実行する際は一旦そのコマンドの同期的な部分のみを実行したあと executor を一時停止し、バックグラウンドから処理完了メッセージが到着したら executor.resume() で再開するようになっていたからだ。これは処理が分散しているといえばそうなので、若干不自然ではある。

    個々の ex コマンドを Promise によって駆動するのであれば、複数回返されるメッセージの扱いというものも ex コマンドのハンドラ内で完結できるわけで、そうすべきだと思う。具体的にはハンドラ内で long-lived connection をその都度行い、コマンド完了時に閉じればいい

  • シグナルの扱い。シグナルというと若干語弊があるのだけど、つまりやはりファイルシステム系の時間がかかるコマンドの実行中、^C が押されたらキャンセル扱いにする処理のことだ。これも Promise 化によって中身がかなり変わる。

ちなみに非同期で実行される ex コマンドとしては

  • cd
  • edit
  • read
  • c オプションが付加された s
  • 非同期とマークされたオプションの値の変更を含んだ set
  • write

となっている。また、レジスタを指定できる ex コマンドで * レジスタが指定された場合も非同期になる。レジスタを指定できる ex コマンドは、

  • delete
  • put
  • yank
  • @
  • *

となっている。非同期とマークされたオプションは以下のとおり。

  • fullscreen
  • syncsize
  • columns
  • lines

2017/03/17 8:27 am
Promise and Generator
Uncategorized, , ,

Migemo Server for Google Chrome™ というものがある。これ自体は migemo のライブラリのように動作し、外部の拡張からのリクエストを受け入れ、適切な結果を返す。

これに対応してみようかなとコードを頭の中で組み立ててみたのだけど、すぐに行き詰まってしまった。というのも拡張から拡張への通信というものは非同期に行われるからだ。一方で wasavi がキー入力を処理する構造は同期ベースで、非同期な動作を組み入れるのはとっても大変なのだ。

この辺を、Generator と Promise を組み合わせて使うようにすればとてもすっきり書けるのだが。なぜ今までそうしなかったかと言えばすなわち Presto Opera でも動かすためだ。Opera 12 は Promise の Polyfill は動くが、Generator は無理なのだ。

しかし、もう wasavi/0.6.657 で Presto Opera のサポートは終了した。従っていよいよそのへんを書き直す頃合いだ。これは割と大掛かりな仕事になるかもしれない。

2017/03/16 6:39 pm
Mount a windows share folder
Uncategorized

Windows マシンを Windows10 にした際に HDD も新調して 2T の広さになったのだが、はっきり言って全然使ってない。というか、Windows マシン自体をほとんど使ってない。

もったいないので、ファイルサーバ代わりにしたい。つまり、Linux (xubuntu) 側から samba で恒久的にマウントしたい。恒久的というのは、xubuntu のファイルマネージャである Thunar 上からも一応 Windows の共有フォルダにオンデマンドでアクセスできるのだが、どこにマウントしているのかよくわからなく、Thunar の中で閉じているのが困るので。そうではなく単純に fstab に記述する形でマウントしたい。

というわけで文書を参考にマウント。

7:15 am
Unicode data updated
Uncategorized, , , ,

wasavi は内部(unicode_utils.js)にいろいろと Unicode のプロパティの情報を持っている。それらの情報は、例えば f/F/t/T コマンドにおける検索対象の判別とか、textwidth オプションを介した自動的な折り返しの際に適切な折り返し位置を見つける処理とか、さまざまなところで役に立っている、なくてはならないものだ。

今までは、それらのプロパティは Unicode 6.2.0 ベースだった。6.2.0 といえば 2012 年の話であり、さすがにちょっと古くなり始めた感が否めない。そういうことで今回 9.0.0 に引き上げた。同時に、プロパティを javascript のコードに変換するスクリプトを今までは PHP で書いていたが、javascript で書き直した。これで、wasavi 本体は当然として、ビルドスクリプトも、テストスクリプトも、データ生成スクリプトもほぼ全てが javascript になった(なったからどうというものでもないが)。

ところで Unicode の各種プロパティのバージョンを引き上げて、それでおしまいというわけではない。データを使用する javascript のコードも Unicode 9.0.0 に合わせる必要がある。ということで合わせた。とても疲れた。

Unicode 絡みで言うと、unicode_utils.js 以外に Unistring というライブラリも使っている。こちらもとても重要なものだ。Unistring が文字列を grapheme cluster 単位に分解することで grapheme cluster 単位のカーソルの移動を実現している。これがなくては、テキスト中に絵文字が 1 つあっただけでカーソル移動がめちゃくちゃになってしまうのだ。

ということで Unistring が持つ内部のテーブルも 9.0.0 に合わせた。4351 件のテストにもパスする。

2017/03/12 8:14 pm
Unit testing
Uncategorized, , ,

wasavi の動作の保証として Selenium を用いた機能テストを通してからリリースしているわけだが、まとまった、自動化された形でのユニットテストは行っていなかった。これはけっこうイケてないので、ユニットテストの仕組みを構築したい。

そんなわけでいくつかのユニットテストコードを追加した。特に難しいことはなく

$ mocha src/unit-tests/strftime.js

などとする。

アーカイブ