CaboChaをpython3で使うためのパッチ書いた

2014-10-28 追記

パッチの内容を編集した。とはいってもdiffをとるファイルの関係をちょっと変えただけ。

　CaboChaの更新を知り、AURのPKGBUILDを更新したついでに試みにやってみたら動いたっぽいので。

　このパッチを当てた後にインストールした後、setup.pyと同じディレクトリにあるtest.pyの動作にも成功したので、一応おそらく正常に動くと思われる。なお、test.pyにもpython3で動かすための変更を以下のように加えた。

xprofileとxinitrcとの違い

2014-06-14 追記

実体験に基づき追記。本文中に示したstartxでDEを利用する流れだが、どうにも異なるようだ。というのも、startxでDEを立ち上げた場合にxprofileの記述が反映されないことがあった。この場合、xprofile - ArchWikiに従ってxinitrcへ

[ -f /etc/xprofile ] && source /etc/xprofile
[ -f ~/.xprofile ] && source ~/.xprofile

と追記すればよい。追記する場所は"exec startkde"などのDEを立ち上げる記述の前にする。こういう事情があるので、startxすればxinitrcを読んだあとでxprofileを読みに行く、というわけではないらしい。

おことわり

　この記事の内容について、私はあまり自信を持てない。おそらくこうであろうとは思うのだが、明確な根拠を示せない。仮に正確な知識をお持ちの方がこの記事をご覧になり、訂正の必要があると判断された場合、ぜひとも訂正箇所をお教え願いたい。

本文

　uimを普通に使う時に、設定ファイルへ追記する

export GTK_IM_MODULE='uim'
export QT_IM_MODULE='uim'
uim-xim &
export XMODIFIERS='@im=uim'

という記述を、どのファイルへ加えればいいのか設定のたびに悩んでいた。Uim を使って日本語を入力 - ArchWikiに従えば、

~/.xprofile、~/.xinitrc、~/.xsession などに設定

とのことなのだが、この設定ファイル達の違いがわからない。 また、指示通りに記述してもuim-ximが立ち上がってくれなかったり、あるいはmultilibなソフトウェアで日本語が入力できなかったりという事があった。/etc/profileへ追記すればいい感じに動いてくれるということが判明してからは前述の記述を/etc/profileへ追記していたが、なんだか気持ちが悪い。
　なので、xprofileとxinitrcについて少々学んでみることにした*1。
　xprofileについては、xprofile - ArchWikiによると、ウィンドウマネージャ（以下WM）の起動前に実行したいコマンドを記述しておくものである。KDMとかGDMとか、名の知られたディスプレイマネージャ（以下DM）であれば、その実行時にユーザディレクトリ下の .xprofile を参照し、コマンドを実行する。WMとDMは独立して実行されるが、Xを使用するという意味ではDMのほうが先んじているので、DMがxprofileを参照することで、WMの起動に先んじて所望のコマンドを実行できる。
　xinitrcは、同様にxinitrc - ArchWikiによれば、startxやxinitなどの、デスクトップ環境（以下DE）を立ち上げる際に使用するコマンドが参照するものである。
　どちらもあまり変わらないような気がするが、このstartxやxinitといったコマンドが関わるかそうでないかが重要なところだ。SystemdなどでDMを有効にし、電源投入後に自動的に起動するように設定している場合、

$ ps aux | grep "startx\|xinit" 

とかやれば、startxやxinitが実行されていない事がわかる。つまり、DMを使用する場合、DEを立ち上げる上でstartxは実行されず、よってxinitrcは参照されない。従ってDEを利用する際、startxなどを使用して立ち上げるときはxinitrcに、そうでない場合はxprofileに設定を記述すれば、期待した動作を得ることが出来る、という訳なようだ。加えて、startxでDEを利用する場合でも、

1. startx
2. ~/.xinitrcを見る
3. DEが立ち上がる
4. WMが立ち上がろうとする
5. ~/.xprofileを見る
6. WMが立ち上がる
7. 見慣れた光景を得る

という流れのようなので、xinitrcではなくxprofileに設定を記述しても良い。

結論

　迷ったらxinitrcに書けばよい。

　ああ、つっかえていたものがとれたようでスッキリした。

参考

• xprofile - ArchWiki
• xinitrc - ArchWiki
• What's difference between .xinitrc & .bashrc & .xprofile / Applications & Desktop Environments / Arch Linux Forums

3番目のサイトではxprofileがいらない子扱いされている。

*1:xsessionについては、xprofileとxinitrcとを調べて解答を得た結果満足してしまったので調べていない。

単純な人工無脳書いた

2014-06-14 追記

コードをちょっと書き換えた。

　ツイッターを見漁っていたら、以下のようなpostをみつけた。

「ああ、そうなんだー」と「へー」と「すごいねー」をランダムに、20回に１回くらい「いや、それは違うんじゃないかなーw」って喋らせるプログラム作ったら多分一日中会話し続けちゃうと思う。

— りみく (@tasuroto0101) 2013, 11月 30

　じゃあ書いてみよう。ってことで書いた。

　元のアイデアをちょっと変更して、

• 「いや、それは違うんじゃないかな―ｗ」を挟むタイミングを変更可能にした
• 会話終了時の挨拶を付け加えた

となっている。

$ python SimpleChatBot.py 20
press 'Q' to quit
>やあ
Res. >> すごいねー
>ありがとう
Res. >> すごいねー
>それほどでも
Res. >> すごいねー
>いやいや
Res. >> ああ、そうなんだー
>はい
Res. >> ああ、そうなんだー
>そうですね
Res. >> すごいねー
>ありがとう
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうです
Res. >> ああ、そうなんだー
>はい
Res. >> へー
>はあ
Res. >> へー
>うん
Res. >> ああ、そうなんだー
>はい
Res. >> へー
>うん
Res. >> へー
>はい
Res. >> へー
>ええ
Res. >> ああ、そうなんだー
>そうです
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうなんですよ
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうです
Res. >> ああ、そうなんだー
>はい
Res. >> いや、それは違うんじゃないかなーｗ
>えっ
Res. >> ああ、そうなんだー
>あっはい
Res. >> へー
>q
Res. >> またねー

　どちらが人工無脳か見分けがつかない。

rm -rf / した後の廃墟を探索する

　2/28から3/1まで、OSC2014 Tokyo/Springが開催されていた。ノベルティ獲得を目的に2日間とも参加した。感想はこことここにクソみたいな内容で残してある。

　で、聴講したとあるセミナーにて、"rm -rf /"の話題が出ていた。rm -rf / はUnixとかUnix系OSではもはやおもしろワードのような扱いであり、実際に試すことは（少なくとも故意には滅多に）無いようなコマンドである。セミナー後、この話題について、ある質問が出ていた。

rm -rf / した後って何が出来るんですか？

　rm -rf / したあとなんて 、まっさらなファイルシステムが残されるのみであって、もはや何も実行できるものもない死の空間である、という認識しかなかった私にとって、その質問は興味深いものだった*1。

　なので実際にやってみた。

記録

環境

• QEMU
• Arch Linux (Kernel: 3.13-5-ARCH)

• archlinux-2014.03.01-dual.isoを使い、Installation guide - ArchWikiに盲従

• ホスト名はThereseとした。（'T'est -> Therese：私は使用するマシンのホスト名にはドイツ語圏の女性名をあてている）
• ブートローダはSyslinuxをいれた

実践

[root@Therese ~]# rm -rf /
rm: it is dengerous to operate recursively on `/'((実際には文字化けして"■/■"みたいになっていた。))
rm: use --no-preserve-root to override this failsafe

　親切だ。だがその親切は無用だ。

[root@Therese ~]# rm -rf / --no-preserve-root

<以下、cannot removeの嵐>

[root@Therese ~]# ls
-bash: /usr/bin/ls: No such file or directory
[root@Therese ~]#

　かくして廃墟が構築された。

　ここでお馴染みのUNIXコマンドを色々試してみたが、軒並み"command not found"か"No such file or directory"が返ってくるのみだった。当然だ。だが、中にはcdとかpwdのように、普通に使えるものも存在した。そこで、bashの補完機能（Tabキー押すやつ）を用いて色々観察してみることにした。

• /にてcdに対して補完

[root@Therese ~]# cd
boot/ dev/ proc/ run/ sys/ tmp/
[root@Therese ~]#

• /にてコマンドの補完

[root@Therese ~]#
:       builtin		disown	false		jobs		readonly	trap
!	caller		do	fc		kill		return		true
./	case		done	fg		let		select		type
[	cd		echo	fi		locale		set		typeset
[][[	command		elif	for		logout		shift		ulimit
]]	compgen		else	function	mapfile		shopt		umask[]
{	complete	enable	getopts		popd		source		unalias
}	compopt		esac	hash		printf		suspend		unset
alias	continue	evel	help		pushd		test		until
bg	coproc		exec	history		pwd		then		wait
bind	declare		exit	if		read		time		while
break	dirs		export	in		readarray	times
[root@Therese ~]#

　割と残ってるみたいだ。しかし見慣れないコマンドばかりだ……。

　では見るもん見たし、終了するとしよう。shutdownがないので、とりあえずexitでログアウトしてみる。今思うとCtrl+Alt+Delでも良かったかもしれない。

[root@Therese ~]# exit
logout

<応答しなくなった>

　死んだ。この後強制的に終了させた。

　この後、再び起動させてみると、以下のメッセージが得られ、臨終の旨を得た。

booting...
SYSLINUX 6.02 EDD Copyright (C) 1994-2013 H. Peter Anvin et al

Failed to load ldlinux.c32
Boot failed: please change disks and press a key to continue.

参考

　先人たちの記録である。

• – root ユーザで rm -rf / してみた

• rm -rf / するとどうなるのか » nksg.org

• 最近のGNUのrmコマンドはdefaultで"rm -rf /"が実行できなくなっている - うまい棒blog

*1:ちなみに質問に対する答えは「cdは出来たと思う」という感じだった。

ハードウェア的にもソフトウェア的にもキー配列を変更してみた

TL;DR

　/usr/share/X11/xkb/symbols/ 下のキー配列（例えばUS配列なら us ）と /usr/share/X11/xkb/rules/下の

• base.lst
• evdev.lst
• base.xml
• evdev.xml

を編集しXを再起動、そのあと「KDE システム設定」からハードウェア→入力デバイス→キーボードに飛び、キー配列タブから新たに追加したキー配列を加える。

経緯

　唐突だが私は無刻印キーボードとDvorakに憧れている。ふつうの刻印キーボードだとソフトウェア的にキー配列を変更した場合ハードウェアとソフトウェアとで入力に差異が生じて訳が分からなくなるが、無刻印キーボードだとそんなことはない。刻印に支配されない環境はさぞかし過ごしやすかろうと思う*1。Dvorakに憧れている理由は、打ちやすいという評判を知ったのと、キーボード左側に記号入力のキーが配置されてるのがエキゾチックな感じがしたためだ。

　で、刻印のあるキーボードでキー配列を変更する場合にキーボードのほうを如何とするかという問題の解決法はいろいろあって、キーをバラして入れ替えるとか、インレタやシールなどで新しいアルファベットをキーに振るというものがある。見栄えがいいのは明らかに前者なのだが、キーボード単体の場合はともかく、ノートパソコンのキーボードでこれをやろうとするとうまくいかない事が多いように思う。私が使用しているThinkPad X200の場合、トラックポイントを採用している都合上G、H、Bキーがトラックポイントにあわせてエグれており、かつFキーとJキーはホームポジションの目安のためにキーに出っ張りが有り、かつパンタグラフの形状が他のキーのそれと違うために他のキーとの入れ替えが不可能なのだ。

　つまりThinkPad X200のキーボードは

*2

で、これを物理的に組み替えてDvorakをやろうとすると、

*3

としたいのに

*4

となってしまうのだ。さらに付け加えれば上図でF、J、U、Hキーは嵌らず脱落した状態になるだろうし、I、D、Xキーはトラックポイントとの干渉箇所を整形しなくてはならない。

　ならば、ソフトウェアのほうをハードウェアの都合に合わせてしまえばいいのではなかろうか、つまり、下図のようなキー配列をでっち上げてしまえばいいのである。

*5

実践

　KDEはxkbの設定に従う。KDE上でキー配列を設定するのはxkb上でキー配列を設定するのと等価である。よって、xkbの設定ファイルに新しいキー配列を加えてやればいい。私はUS配列のキーボードを使っているので、この場合は /usr/share/X11/xkb/symbols/us を編集する。編集内容は以下の通り。新しく追加したキー配列は「cdv」で表現し、その説明は「English(customized Dvorak)」とした。

for /usr/share/X11/xkb/symbols/us

　次に、新しく加えたキー配列をxkbに読み込ませる。これは /usr/share/X11/xkb/rules/ 下の

• base.lst
• evdev.lst
• base.xml
• evdev.xml

を編集する必要がある。*.lst の編集内容は以下の通り。

で、*.xml の編集内容は以下の通り。

　以上を終えたらXを再起動させる。再起動後、「KDE システム設定」からハードウェア→入力デバイス→キーボードに飛び、キー配列タブから新たに追加したキー配列を加えれば、新しく追加したキー配列を使用できる。

使用感

　QWERTYに慣れすぎて使いづらい。だがこれは多分普通のDvorakを使おうとしても抱く印象だろう。しかし、キーの物理的制約でDvorakを崩した結果、母音がキーボード左部と中部に分散してしまい、Dvorakの特徴であるらしい、左手と右手でリズミカルにタイピングできるという特徴が損なわれている感じがある。

　ちなみにこの記事はQWERTYで書いている。QWERTY使いやすい。Dvorakは素のままのDvorakを使える環境が手に入るまでお預けとしたほうがいいだろう。

参考

• KDE - ArchWiki

• Keyboard Configuration in Xorg - ArchWiki

• Custom Keyboard Layout in Ubuntu (or just Linux :)

• kde - How to deploy a custom keyboard layout? - Super User

• How can I create a new keyboard layout for KDE 4? - Unix & Linux Stack Exchange

*1:無刻印キーボードを使える人は刻印があろうとなかろうと使用感に差は感じないんじゃないかと思わなくもないが、これは黙殺する

*2:https://upload.wikimedia.org/wikipedia/commons/d/da/KB_United_States.svgを編集して使用した

*3:https://upload.wikimedia.org/wikipedia/commons/2/25/KB_United_States_Dvorak.svgを編集して使用した

*4:同上

*5:同上

Pig Latinをするプログラム書いた

　Pythonでどれくらい書けるようになったかを試したくなったのとPig Latinで遊びたくなったのとを兼ねて書いてみた。Pythonの特徴を活用できていない感じがある。

　Pig Latinについてはhttps://en.wikipedia.org/wiki/Pig_Latinを参照のこと。

（2014-06-01 編集：オブジェクト指向っぽくした）

動作

$ echo "The quick brown fox jumps over the lazy dogs" | python PigLatin.py 
ethay uickqay ownbray oxfay umpsjay overway ethay azylay ogsday

CodingBatで悩んだ問題に対するメモ書き（其の一）

2014-05-17 追記

はてなブログの LaTeX 数式表示がデフォルトで MathJax 化された - 余白の書きなぐり ということなので、記事中の数式の書き方をなおした。本文も少し修正した）

　「其の一」とか書いたが続編なんか書きたくないぞ。

　最近、Pythonを勉強しようと思い、CodingBatで問題をちまちまと解き続ける生活をしている。今週の日曜日（12月15日）からはじめて現在Logic-1まで解き進めた。Logic-1までは対して悩むこともなく解き進められたのでこの調子でLogic-2も解いて行こうと挑戦してみたら早速第1問目(CodingBat Python Logic-2 make_bricks)で詰まってしまった。

　以下問題（と拙訳）。

We want to make a row of bricks that is goal inches long. We have a number of small bricks (1 inch each) and big bricks (5 inches each). Return True if it is possible to make the goal by choosing from the given bricks. This is a little harder than it looks and can be done without any loops.

goalインチの長さの煉瓦塀を作りたい。小さい煉瓦（各1インチ）と大きい煉瓦（各5インチ）がいくらかある。用意された煉瓦から適当に選び出して［注：用意された煉瓦全部を使わなくてもよいということだろう］目標の長さの煉瓦塀を作れるならTrueを返すようにせよ。この問題は見た目よりも若干難しい。それと問題はループなしで解くことが出来る。

　最終的には偶然が重なって解けたし答えの理屈もきちんとわかったので問題は解決している。しかし、この「わかった」内容をどこかに控えておかないと、たぶん寝て起きたら忘れてしまうだろうし、同じ問題でまた詰まってしまうのは避けたい。

　というわけでここに控える。はじめに断っておくとCodingBatでも言っているように他に解き方がいっぱいあるだろうし、私の解き方が最もふさわしいなんて言うつもりも全く無い。自分用のメモとして残しておくものである。

始めの一歩

小さい煉瓦が個、大きい煉瓦が個あるとして、長さの煉瓦塀を作ることを考える。煉瓦をすべてを使う必要はない。

考え方は、大まかに大きい煉瓦で煉瓦塀をつくっていって、細かい調整は小さい煉瓦で行うという方針になる（書くまでもないだろうけど）。

場合分け

まずとなる場合は明らかに長さの煉瓦塀を作れないのでFalse。この場合との値にもよるけど、煉瓦塀を作っていたら大きい煉瓦は与えられた個数を使い切ったが、最後の最後で小さい煉瓦の数が足りなくなった、というものに相当する。大きい煉瓦の数は足りていた、煉瓦塀の長さの端数が問題になった、というような感じか。

次にとなる場合、これは大きい煉瓦が余ってしまうという場合に相当する。よって小さい煉瓦の数が重要になってくるわけだが、小さい煉瓦を5個集めると大きい煉瓦1個と等価であることを考えると、（剰余）とを比較してならFalseとすればよい。つまりに対してが十分なだけあれば煉瓦塀は作れるという意味になる。

最後に、(2)は満たすが(3)は満たさないというとの組み合わせが求めるべき数の組み合わせであるので、このような入力の場合はTrueを返すようにする。

プログラム

一応。