kiyoka日記。NendoやSekkaの開発や、最近思うことなど
最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list
[img]  
このブログを書いている人: 西山 清香(kiyoka) - twitter: @kiyoka
----
 
 
* kiyoka.2015_10_04[電話料金][MVNO] docomoファミリー割引からIIJみおふぉんへの移行料金
 
自分用のメモ。家族のガラケー2本のうち1本をiPhoneにする計画。
本当にできるかどうかはさておき、費用を計算してみる。
月1200円安くなるが、移行月はiPhone本体が1万円で入手できたとしても約30000円の出費となる。
 
## 移行前
- docomo SSプラン x 2 (ファミリー割引)
 ( +
 3600円  ;基本料金(ss)
  -1760円 = (-860 + -900) ;いちねん割引 + ファミリー割引
  +xxx ;いろいろ
 )
 約2300円
 2人分 約4600円
 
- イオンSIM
 約1000円
 
- 合計
 約5600円
 
## 移行後
- docomo SSプラン x 1 (ひとりでも割引)
 3600円
  -1300円 ; ひとりで割引
 約2800円
- IIJみおふぉん 音声付き 3GB
   1600円
 
 約4400円
 
## 移行時費用
- iPhone本体
 約10000円
- iPhoneバッテリー修理代
    9800円
- IIJみおふぉん契約料金
    3000円
- docomo MNP転出代金
    3000円
- docomo 1ねん割引解約違約金
    2000円
- 合計
   27800円
----
 
 
* kiyoka.2015_10_03[iPhone][MVNO] IIJみおふぉんで使える古めのiPhoneリスト
古めの安いiPhoneを探している。
 
** 条件
- IIJみおふぉんの動作確認済み機種
  https://www.iijmio.jp/hdd/devices/
- テザリングができる
- iOS9が動く
- ストレージ32GByte以上
- Retinaディスプレイ以上
(つまり、今もっているiPod touchにSIMが挿せたとしたら実現できるスペック)
 
## 機種リスト (新しいのは除外)
- iPhone6 SIMフリー版
- iPhone6 docomo版
- iPhone5s SIMフリー版
- iPhone5s docomo版
- iPhone5c SIMフリー版
- iPhone5c docomo版
- iPhone5 SIMフリー版
- iPhone4s SIMフリー版
 
リストアップしてみると、意外と選択肢が狭い…
 
comment (disabled)
----
 
 
* kiyoka.2015_04_29[Sekka] Daybreakというpure rubyのkey-value-storeを試してみた
 
** 目的
Sekkaの辞書データベースとして、プラットフォームに依存しない形式は無いものかと探している。
Sekkaの辞書データは結構大きいので、Sekkaインストール時にInternetから取得する方式にしているのだけど、プラットフォーム依存だとどうしても導入時に変換が入ってしまう。
その変換時間がバカにならない。
できれば、ダウンロードして即動かしたい。
現在Sekka辞書 1.6.1でサポートしているフォーマットはgdbm/TokyoCabinet/Redisで、どれもtsvからの読み込みが発生してしまう。
 
** 結論:Daybreakはメモリ消費量が多すぎてボツ
これが、試しに実装してみたブランチ。リリースはしない。
 https://github.com/kiyoka/sekka/tree/daybreak_db
 
in memoryデータベースなのでしょうがないとはいえ、Sekka辞書ver1.6.1では3GByteのメモリを消費してしまう。
同じin memoryデータベースのRedisだと1.2GByte程度で収まる。
Daybreak 0.3.0のドキュメントを読む限り、内部はRubyのHashをそのまま保持しているようだ。
それに対してRedisはデータ圧縮などの工夫や、その他の工夫をしているようで、メモリフットプリントが少ない。
 
** 感想
一般論として、pure rubyのまともなkvsは実現が困難だと思う。
データ量が小さいのであれば、pure rubyのHashクラスをそのまま使うのはありだろうが、ある程度データ量が増えると、どこかでDISKに退避したりメモリフットプリントを減らす工夫が必要だと思う。
結局RedisやTokyo CabinetなどC言語などできめ細かく実装するしかないと思う。
 
comment (disabled)
----
 
 
* kiyoka.2015_02_23[Sekka] SKKユーザーを満足させるのは難しい
 
前回の記事で、Sekkaをレベルアップできないかという話題を書いた。
SKKライクなIMEの特徴である、シフトキーを頻繁に押さないといけないという問題をなんとか改善できないか…
ローマ字先頭の大文字を指定しなくても快適に使えるようにならないかということを軽々しく書いた。
 
** SKKユーザーを満足させるのは難しい
いろいろ試してみて、漢字とひらがなは「現段階では」人間が細かく指定したほうがよいという結論になった。「現段階では」という括弧書きだが。
いくらIMEが賢くなってもどこかでユーザーの考えていることとくい違ってしまう。つまりそれは誤変換だ。
本当のことをいうと、ユーザーが考えていることと完全に一致した結果を返せれば、それは誤変換は無いということになるので、完全に満足できる「賢さ」というポイントは必ずあるはずだ。
しかし、コンピューターの能力は有限なのでどこかでその壁が来る。
 
試しに、共起頻度の辞書100MByte分を追加して実験してみたが、変換中の単語の直前2語が辞書にヒットするとは限らず、どの単語が確からしいかは推定できない。(bigramとskip-bigram)
辞書には "日本語" と "変換" は共起するという情報があるので "日本語"の直後の"henkan" は漢字の"変換"と推定できるが、いつもこのようにうまくいくとは限らない。
自分の文章が必ずセオリーどおりのパターンで構成されているわけではない。辞書に無ければそれでアウトだ。
SKKユーザーはこの「漢字」と「ひらがな」と「カタカナ」間の誤変換というのを普通の人以上に嫌うので、なかなか難しい問題だ。
 
** パーソナライズというもうひとつの問題
Webコーパスなどから集計した共起頻度の辞書を使うと、例えば句読点として「、。」を使うのか「,.」を使うのかという個人設定を維持することを困難にする。
コーパスとその人の趣向が一致しない場合、期待しない候補が選択されてしまう。(まあ、狭い範囲での解決策はいろいろあるが)
この点、SKKは最後の選択肢が愚直に第一候補になるので、文脈によって変換候補の順位が影響を受けない。
 
** 結論
SKKユーザーのように少しの誤変換も許しがたいユーザーにとって、IMEの挙動に推測はなるべく入れないほうが良い。
恐らく、SKKユーザーを納得させることができるのは人間の知性を上まわる「強いAI」が完成した時しかありえないだろう。
 
** 使ったデータ
辞書は以下の2gmと3gmを使った。
 N-gram コーパス - 日本語ウェブコーパス 2010
 形態素 N-gram 頻度 10 以上のファイルリスト    圧縮時 12.1GB,展開時 75.2GB 
 
** GitHubの作業branch
多分リリース予定なし。将来の約に立つかも。
 https://github.com/kiyoka/sekka/tree/ngram_dict
 
** 感想
自分でいうのもなんだが、SKKユーザーはなかなか頑固ものである…
 
comment (disabled)
----
 
 
* kiyoka.2015_02_12[Sekka] SKKライクな日本語入力システムでシフトキーを押す回数を減らしたい
 
Sekkaを話題にするのがあまりに久しぶりなのだが、思い立ってSekkaをさらに改善できないか検討している。
今度は、大文字始まりのローマ字を入力しなくても単語が漢字かひらがなかカタカナかを勝手に推測してくれるというもの。
本来、SKKライクなIMEを使っている人は、ひと手間掛けてもよいから思考を乱されるような誤変換を減らしたいという心理で使っている。
なので、わざとひらがなで「ひらがな」と入力したいところを第一候補に「平仮名」という漢字が出てくるといやがられる。
 
ただ、使い易さというのはバランスなので、あまりにもシフトキーを押す回数が多い場合はそれも思考のさまたげになる。(小指が痛いというのも思考の妨げになる)
毎回先頭大文字のローマ字を入力しなくてもよいならそれに越したことはない。
 
回避策は二つあって、一つは形態素bi-gramの辞書を導入するもの。
隣りあう形態素同士の共起頻度を使って、文脈から明らかに漢字を優先すべきローマ字は漢字候補を優先する。
例えば、「漢字」で確定された次の単語で henkan と入力された場合でも Henkan  と入力したかった可能性も考慮し 「変換」 と 「へんかん」を共起頻度の得点を積んだ上で変換候補に入れる。
 
もう一つは、Ctrl-Jでの変換確定時にマウスのダブルクリックのように素早くCtrl-jを2回押すと先頭を大文字にしたとみなす。 (henkan Ctrl-j Ctrl-j」というキーストローク)
この案は安易すぎるかもしれないけど、意外とこういう姑息な方法でも効果があったりするのでやってみるのもよいかな。
 
comment (disabled)
 
----
 
 
* kiyoka.2015_01_19[Xwindow][RDP] rdesktop経由でリモート接続したWindows日本語IMEを有効・無効制御したい
 
自分用メモ。
** 環境
ハードウェア: PowerBook G4 (日本語キーボードモデル)
OS: MacOS X 10.5.8
RDPクライアント: rdesktop (MacPortsに入っているもの)
接続先Windows: Windows Server 2012 R2 on Amazon EC2
 
** やりたいこと
MacOSと同様に、Windowsでも「英数」キーでIMEをOFF / 「かな」キーでIMEをONしたい。
 
*** MacOS X上のX windowの設定
## rdesktopが認識できるキーシンボルを定義する
$ vi ~/.Xmodmap
 
## 以下の内容にする
 keycode 110 = Muhenkan
 keycode 112 = Henkan
 
## xmodmapを適用する
$ xmodmap ~/.Xmodmap
 
** WindowsのIMEの設定
MS-IMEのキーバインドの設定で、「英数」をIME-OFF / 「かな」キーをIME-ONに割り当てる。
 
** 参考リンク
 OSXのX11で英数キー、かなキーの設定を変更する - HongoWiki
 
comment (disabled)
 
 
 
 
 
----
 
 
* kiyoka.2015_01_15[Xwindow][RDP] rdesktop経由でリモート接続したWindowsの中でバックスラッシュが打てない
 
自分用メモ。
** 環境
ハードウェア: PowerBook G4 (日本語キーボードモデル)
OS: MacOS X 10.5.8
RDPクライアント: rdesktop (MacPortsに入っているもの)
接続先Windows: Windows Server 2012 R2 on Amazon EC2
 
** 現象
リモート接続して ¥キーを押しても、Windowsでバックスラッシュが入力できない。バー'|'は入力できる。
¥キーを押す度に、rdesktopがワーニングメッセージを出す。
$ rdesktop -f xxx.xxx.xxx.xxx
Autoselected keyboard map ja
WARNING: No translation for (keysym 0xa5, yen)
WARNING: No translation for (keysym 0xa5, yen)
WARNING: No translation for (keysym 0xa5, yen)
 
** 対処方法
*** rdesktopのkeymapsファイルを編集する。
$ cd /opt/local/share/rdesktop/keymaps
$ sudo vi ja
 
*** 編集内容
以下を削除
backslash 0x73
以下を追加
backslash 0x7d
yen 0x7d
 
** 参考リンク
 UbuntuPC/rdesktop(RDP)のかな入力が不正 - PelicanWiki
 
comment (disabled)
 
----
 
 
* kiyoka.2014_10_08[ssh][X] XQuartzが固まるのはX11Forwardingのタイムアウト設定のせいだった
 
MacOS XのXQuartzのX11プロトコル転送を使っていたら、とちゅうでよくsshが切れていた。
ずっと原因がわからなかったが、どうやらこれが原因だった。
 
X11 Display Forwarding Fails After Some TimeRandomness
 
MacOS X側(XQuartz側)の /etc/ssh_config にこれを定義して ssh -X [ホスト] で繋げばOK。
ForwardX11Timeout 596h
 
最近のopensshだと、デフォルトは20分くらいになっているそうだ。
なんとも単純だけど、今季最大の収穫だなのでメモ。
 
comment (disabled)
----
 
 
* kiyoka.2014_09_03[LLVM][実験] LLVMが楽しい
 [img] 
 
** LLVMが普及しつつあるけど実際どうなのか
ふと思いついてLLVMについて調べ始めた。
世間ではGoogle ChromeのPNaCLとかemscriptenやasm.jsが実用的に使われる気配が見えてきた。
AppleのMacOS XやFreeBSDのLLVMへの傾倒を見ると、そろそろどんなものか知りたくなってきた。
なぜか昔から自分はCross Platformの話題が好きなようで、i386で動くLinuxのエミュレーターをJavaで書いたこともある。(完全に黒歴史…)
 
** LLVM-IR
Cross Platformerとしての興味の対象はLLVM-IRなので、まずはここから。
LLVM-IRの言語仕様を調べたりclangの出力するLLVM-IRのコードを眺めてみたりした。
clangの最適化オプションを -O0 から -O3 にしてどれくらい最適化されるのかを眺めたり。
LLVM-IRの抽象度は非常に高く読みやすく(読むものでは無いだろが)Cross Platformな話題が好きな自分にはかなり楽しそう。
挙句の果てには、LLVM-IRのコードをEmacsLispで動かせないかと実験をしてみたりした。
 
** LLVM-IRをEmacsLispに翻訳
可能性を探るためにちょっとやってみたのだが、LLVM-IRのインタプリタlliコマンド の 約1000倍の実行時間がかかることがわかった。
ということでこれで思考実験は終わり。
 
このようなCプログラムをclangでコンパイルし、LLVM-IRを翻訳したEmacsLispで動かしてみた。
#include <stdio.h>

int main(void)
{
  int total = 0;
  volatile int i;
  for( i = 0 ; i < (1000000 * 1000) ; i++ ) {
    total += i+1;
  }
  printf( "total = %d\n", total );
  return 0;
}
 
"clang -O0 -S -emit-llvm loop.c" で出力したLLVM-IRコードもあわせて見るにはこちら。
 simple loop program.
 
つぎに愚直にEmacsLispに翻訳してみたのが loop1.el 
手でちょっとだけ最適化してみたのが loop2.el 
 Translate to Elisp from LLVM-IR code
 
** LLVM-IRをSchemeに翻訳
愚直にSchemeに翻訳してGaucheで動かしてみたのがこちら。
lliの100倍の時間がかかる。しかしGaucheは速い。
 Translate to Scheme from LLVM-IR code
 
** cmigemoをEmacsLispで走らせられないか(妄想)
cmigemoを1000倍非力なCPUで動かすとどれくらい使えないかを測ってみた。
cmigemoの検索クエリから正規表現への展開は1000回実行しても100ms程度で、実用的な範囲。
しかし、mcigemoが辞書をロードする時間は1000回実行すると3分もかかる。これは実用にならない。
 
っと、ここで夢から覚めて我に返った(←イマココ)
いやー妄想って楽しいもんです。
 
comment (disabled)
----
 
 
* kiyoka.2014_07_16[Sekka] sekka.elからpure emacsでhttp通信しようするも断念
 [img] 
Emacsも年々進化していることだし、もうそろそろcurlコマンドを使わなくてもEmacsだけでHTTP通信できるのでは?と思ってチャレンジしてみた。
今回はあきらめたのだが、理由を忘れそうなのでここにメモしておく。
gibthubのSekka作業ブランチは "http_pure_elisp" 。
  https://github.com/kiyoka/sekka/tree/http_pure_elisp
 
** url.elのリクエストが不正?な問題
Emacs-24に入っている url.elを使ってsekka-serverにアクセスするも、webrickが400 Bad Requestを返す。
url-retrieve-synchronously関数の返却バッファには、200 OKのレスポンスの後ろに、400 Bad Requestのレスポンスがくっついてくるので原因がよくわからない。
curlコマンドからWebrickにリクエストした時は発生しないので、url.elのリクエストがRFCに準拠していないのか、Webrickの潜在バグを突いているのか…
 
** url.elからのリクエスト中にEmacsのキーイベントが消費される問題
url-retrieve-synchronously関数を実行している間にCtrl-jを押しても効かない。
キーイベントがどこかで消費されているのかもしれない。
curlコマンドをプロセス起動した場合にはそのような現象は発生しないので、url.elの作りの問題なのかもしれない。
url*.elで "discard" や "event"  などで検索したがあやしい処理は見つからず…
 
** Webrickの代替が見つからない問題
Webrickの代わりに別のRackドライバを探したが、thinくらいしか見つからなかった。
thinを使ってみるも、Segmentation Faultで動かず断念。
 
こんな感じで、あまり時間をかけていないが、一旦断念。
また一年後くらいに再チャレンジするかも。
ただ、curlが非常に安定していることもあって、EmacsからHTTPリクエストする場合はcurlがデファクトスタンダードになっているようだ。
いっそEmacs本家にcurlをリンクしてくれたりいいのにと思うんだけどなぁ。
 
comment (disabled)