GOR
Reply
Author Archives: akahuku
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 サーバを動かすというソリューションが意外に少ない。まあ、でも、そりゃそうですよね…。
探してみたところ、
- Allegro NFS Server® for Windows
https://nfsforwindows.com/home - haneWIN NFS Server for Windows
http://www.hanewin.net/nfs-e.htm - WinNFSd
https://github.com/winnfsd/winnfsd
などがある。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] コマンドで端末からも切り替えられる。
Policy Violation
先週 Google Chrome web store team から、「wasavi が掲載ポリシーに違反している、1 週間の猶予をやるから直して再アップロードしろカスが」というメールが来た。
ポリシーというのはたとえば内容の表現とか、広告とか、ユーザーデータの取り扱いとか、そういうものだ。しかし wasavi が内包している内容と言ったらシンプルなエラーメッセージくらいだし、広告はないし、ユーザーデータもオプションページでいじれるもの以外にないわけで、違反ってなんのこっちゃという感じだった。そして困ったことに、どの点が問題なのかという肝心の点がメールに書いていない。
そんなわけでハドラーこれどうなってるの？ というお返事をしたところ、「なんか間違いだったみたい。気にすんなカスが☆」ということであった。
なるほど。
serif or sans-serif #2
このブログにたまにスクリーションショットを上げるが、それを見てもわかる通り Chrome のフォントをTakao P 明朝に設定している。これ自体はとても良く出来ているフォントなのだが、繁体字や簡体字の文字までカバーしているわけではないので、そこだけ別のグリフになってしまうことがごくたまにあり、それが気になる。
フリーで、Unicode の多くのコードポイントに対応していて、明朝体あるいは serif のフォントというと Google Noto Fonts の Noto Serif CJK JP である。というわけで、入れてみた。
Takao 明朝に比べると若干硬い感じを受けるが、それはまあ慣れなので。もうひとつ気になるのは含まれるアルファベットが若干アセンダ・ディセンダが広く、うわ〜気取りすぎ！な感じはなくもない。まあそれも慣れなので。
とは言え、慣れではどうにもならないものもあるのです。Chrome のフォントの設定は標準フォント・sans-serif フォント・serif フォント（と、その他）に分けられている。素直に考えれば、標準フォントはページになんにも font-family が指定されていないときに使用されるフォント、sans-serif と serif は font-family 中のそれぞれの総称フォントということだろう。
しかしこの通りに標準フォントと serif フォントに Noto Serif CJK を与えても、そのとおりに表示されない web ページはたくさんある。表示されないのは意図されたもので、つまり font-style に sans-serif を含んでいるページが多い。これは悪習なんじゃないだろうか。font-family には「ぜひともこのフォントで表示してほしい」ものだけを書いてほしい。そしてそのフォントは Web フォントの技術を用いて web ページ側が提供してほしい。font-family は「どういう風に表示されるかは保証しないけどこのフォントで表示してくれたら嬉しいな〜」なフォント名を書くものではない。