テクニカルプア

備忘録と若干の補足

uimで./configureに--enable-kde4-appletとか--enable-notify=knotify4をつけるとコンパイルに失敗する事案の解決法

結論

 automoc4とcmakeをインストールすればいい。

蛇足

 cmakeのほうはhttps://code.google.com/p/uim/wiki/InstallUim#Installing_required_packagesをみればわかるのだけれど、automoc4は必要とされるパッケージとして挙げられてないので忘れがち。でもautomoc4はcmakeに必要なパッケージだし、よく考えてみれば気付くはずだからわざわざ書くようなことはしてないのかもしれない*1

 Arch Linux公式のuimでは前述のオプションは無効化されており、これを使うにはabsからPKGBUILDを取得して編集し、パッケージを作らなきゃならない。そういう事情のため、uimのPKGBUILDにおけるdepends欄やmakedepends欄にはautomoc4及びcmakeの記述はない。ストレスなくuimのパッケージを作るには前述の要項をPKGBUILDに加えるパッチをつくるとよい。

*1:私は気付かなかった

QtEmuで設定できる仮想マシンのRAMの上限を拡げる

2013-09-23 追記

本文中で触れているgendeskをbuild()から呼び出す方法ではうまくいかないというのはgendesk 0.5.4におけるバグであったようだ。現在は0.5.5になり、バグも修正された(https://github.com/xyproto/gendesk)。本文での言及箇所には打ち消し線を引いた。

 

 QtEmuというのはQEMUGUIで扱うためのソフトウェアだ。

 QtEmuで仮想マシンをいじくるとき、RAMを1024MBまでしか割り当てられないのがけっこう不満だった。ある機会があってVirtualBoxを使った時、こいつはシステムが許す限りのRAMを割り当てることができて、RAM割り当てたい欲を満足することができた。

 QtEmuが仮想マシン管理のためにつくるXML(<仮想マシン名>.qte)のmemory要素をいじくってみても変更は反映されず、どうしたもんかなあと悩んでいたが、先程、ソースコードをいじればいいのだという着想を得た。得るのが遅すぎる。

 とりあえずQtEmuのソースを落としてきて、"1024"MBの制限を掛けているということから

$ find . -name '*.cpp' -print | xargs grep 1024

全文検索を掛けた結果、machinetab.cppがそれらしいという反応を得た。このファイル中の1024を軒並み4096に変更したら、仮想マシンに4096MBまでRAMを割り当てることができるようになった。RAM割り当てたい欲を満たすことができるようになった。

 パッチを書いた。手で書き換えるよりはマシだと思う。

自動的にこのパッチをあてて、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_filesに沿ったgendeskを行うためのPKGBUILD用パッチも書いた。

 

 このgendeskだが、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_fileshttps://wiki.archlinux.org/index.php/Desktop_Entriesで扱い方が異なっているのだけれども、どちらがよいのだろう。prepare()から叩くほうがわかりやすいかなと思うのだけれど。あとbuild()から叩いた場合うまく動いてくれず、prepare()からだと動いた。環境依存かもしれず怖い。

 

KonquerorやAkregatorとかの見た目がたまにショボくなる

 KonquerorとかAkregatorはデフォルトで使用すると起動時は以下のような感じになる。f:id:aaodsn:20130813225647p:plainKonqueror

f:id:aaodsn:20130813225911p:plainAkregator

 

 ただ、ふと思い立ってKonquerorをきちんと使おうとしていろいろいじくってみると、Konquerorの見た目が以下のようにショボくなることがあった。

f:id:aaodsn:20130813230025p:plainKonqueror(ショボい)

 

 Konquerorだけ影響を受けるのならまだわかるのだが、なぜかAkregatorにも影響が及んでしまってこちらもショボくなる。スクショを撮り忘れたが、他にもSystemsettings(KDE システム設定)などもショボくなった。

f:id:aaodsn:20130813230342p:plainAkregator(ショボい)

 

 短期記憶力が絶望的に欠如しているのでいつもKonquerorのどこをいじくったか忘れてしまって途方に暮れてしまい、これまではホーム直下の.kde4/share/configをリネームしたり削除したりで対応していた*1*2

 が、奇跡的に今日は短期記憶力がそれなりに使える日であったようで、直前に設定したAdblockのフィルターの設定(Konquerorの設定からWeb Browsing→AdblocK Filters)をデフォルトに戻したら、ショボい見た目がいつもの見た目に戻った。

 場当たり的な解決法で気持ち悪い。KonquerorAdblocKを使っても見た目がショボくならない方法を見つけたい。

 

*1:当然これまで設定してきた内容は無効になる。

*2:.kde4/share/config/konquerorrcをどうにかすればいいのではと思ったがどうにかしてもどうにもならなかった。

crfppを正しくインストールするためのパッチ書いた&"pkgdir"と"startdir/pkg"の違い

 昨夜、cabochaで遊ぼうと思ってkonsoleからコマンドを叩いたら以下のようなエラーを吐かれた。

cabocha: error while loading shared libraries: libcrfpp.so.0: cannot open shared object file: No such file or directory

 libcrfpp.so.0がないんですって。早速findで検索かけたがたしかに見つからない。crfpp(CRF++)はcabochaの依存関係に含まれるものであるのでインストールされてあるはずなのだが。

 浅薄なのはわかっているがここでcabochaの再インストールを試みた。が、今度はcabochaのコンパイルで以下のエラーが出てきた。

chunk_learner.cpp:6:19: fatal error: crfpp.h: No such file or directory

 これcrfppがどうにかなっているんじゃないか。ということでcrfppのPKGBUILDを見てみる事にした。すると現在は使用が非推奨になってる変数であるstartdir*1を用いてbuild()とかpackage()を書いていることがわかったので、startdir/pkgをpkgdirに、startdir/srcをsrcdirに変更してmakepkg、インストールした。この結果、cabochaのコンパイルも無事成功してきちんとcabochaが動いてくれた。

 AURのcrfppでもいちおうこの旨をコメントしておいたので重複するが、きちんと使えるcrfppのパッケージを作るためのパッチを下のリンクにおいておく。

 さて、なんでstartdirを使うとダメでpkgverおよびsrcdirを使うといいのかちょっと観察してみることにした。

まずtreeを用いてstartdirを使った場合とpkgdirおよびsrcdirを使った場合のディレクトリの様子をみた。通常makepkgするとPKGBUILDが存在するディレクトリ内にpkgとsrcの2つのディレクトリができるが、src下についてはstartdir/srcとsrcdirで内容に差異がなかったので省略する。

  • startdir/pkgの場合
.
├── CRF++-0.58.tar.gz
├── PKGBUILD
├── crfpp-0.58-1-x86_64.pkg.tar.xz
├── pkg
│   ├── crfpp
│   └── usr
│       ├── bin
│       │   ├── crf_learn
│       │   └── crf_test
│       ├── include
│       │   └── crfpp.h
│       └── lib
│           ├── libcrfpp.a
│           ├── libcrfpp.la
│           ├── libcrfpp.so -> libcrfpp.so.0.0.0
│           ├── libcrfpp.so.0 -> libcrfpp.so.0.0.0
│           └── libcrfpp.so.0.0.0
└── src

 

  • pkgdirの場合
.
├── CRF++-0.58.tar.gz
├── PKGBUILD
├── crfpp-0.58-1-x86_64.pkg.tar.xz
├── crfpp.patch
├── pkg
│   └── crfpp
│       └── usr
│           └── local
│               ├── bin
│               │   ├── crf_learn
│               │   └── crf_test
│               ├── include
│               │   └── crfpp.h
│               └── lib
│                   ├── libcrfpp.a
│                   ├── libcrfpp.la
│                   ├── libcrfpp.so -> libcrfpp.so.0.0.0
│                   ├── libcrfpp.so.0 -> libcrfpp.so.0.0.0
│                   └── libcrfpp.so.0.0.0
└── src

 PKGBUILDがあるディレクトリをカレントディレクトリとして.(ドット)、インストールするプログラムの名前をfooと表せば、startdirはそのままカレントディレクトリを指し、結果startdir/pkgは./pkgを指す。しかしpkgdirは./pkg/fooを指す。startdirをつかってインストール先を直接指定するよりは、pkgdirを用いて動的にインストール先を指定してもらったほうが便利だよ、という話のようだ。

 また、ふたつのtreeの結果をみるとわかるが、startdirを使った方はインストール先が./pkg/usr/binとなっているのに、pkgdirを使うと./pkg/crfpp/usr/local/binとなっている。crfppのMakefileには"prefix = /usr/local"が宣言してあり、pkgdirを使うとこのprefixが使用されるがstartdirではこれが使用されないようだ。結果、インストール先のディレクトリ構成が異なってしまう。ただ、Arch Linuxはすべてのパッケージは/usrを使用すべきとしており*2、その場合"prefix = /usr/local"という宣言は殺してしまうのがいいのかもしれない。./configureで--prefix=/usrしてるだけだった。

*1:startdir

           This contains the absolute path to the directory where the PKGBUILD is located, which is usually the output of $(pwd) when makepkg is started. Use of this variable is deprecated and strongly discouraged.

(PKGBUILDのman(pacman 4.1.2, 2013-06-18)より)

*2:https://wiki.archlinux.org/index.php/Creating_Packages

Nexus4買った

2013-05-31 追記

大変遺憾なことにNexus4は盗難に遭い、現在私の手元にない。仕方ないので画面の割れたGalaxy Nexusを持ち歩いている。

2013-06-07 追記

無事に戻って来た。

  

 4月上旬のある日の外出中、携帯(Galaxy Nexus)を地面に落下させた。

パーンという不吉な音がしたものの、あちゃー迂闊だったなーやっちまったなーと気楽な気持ちで拾い上げたら想像以上のことをやってしまっていた。

f:id:aaodsn:20130420131012j:plainこれはいけない

 まさか自分が液晶パネルを割るとは思ってもみなかった。

動揺して色々早まった行動を繰り返し、紆余曲折の末Nexus4を個人輸入してしまった。

 

 そして先日、Nexus4が届いた。個人輸入は長期休暇中にすべきという教訓を得た。

f:id:aaodsn:20130418195956j:plainはこ

f:id:aaodsn:20130420141453j:plainブツ

 いまさらな端末でありスペックも現行の最新機種と比べて特に優れているということはない(らしい)Nexus4ではあるが個人的には十分すぎるほど高性能な機械だ。

「入門 自然言語処理」第12章を読む上で必要なソフトウェアまとめ

 今日(正確には昨日)ようやく「入門 自然言語処理」を読み終えた。
かなり面白い本だったが、冒頭に必要であると明記されたソフトウェア群だけでは章が進むにしたがってだんだん内容をカバーしきれなくなっていて、いろいろとソフトウェアの追加をしなきゃならなかったりしてお茶目だと思った。11章まではそれで通った。
 が、12章に入ってから、扱う言語が英語から日本語にシフトしたためにNLTKではカバーできなくなり、形態素解析構文解析に使うためのソフトウェアを続々追加していかなきゃならなくなった。このソフトウェアたちが曲者で、Arch Linuxの公式レポジトリにない、AURにないの連続で、pacmanないしyaourtを叩いて待ってればオワリというわけにはいかなかった。もちろん今は時代が進んでいるので

./configure
make
make install

とか

python2 setup.py build
sudo python2 setup.py install

などとやれば簡単にインストールはできるのだけれど、困ったことに私は潔癖症の気があるようで、パッケージはpacmanで管理できないと嫌だ、という奴なのだ。半ば自分の潔癖症のせいでブチ切れながらPKGBUILDを書いてmakepkgを叩くということをしながら12章を読んでいたら、本文を読んでいる時間よりもPKGBUILDを書いてる時間のほうが長くなってしまったという悲しい結果に終わってしまった。

 さて、このようにブチ切れながらこの大変おもしろい本を読むような悲しい人間をこれ以上出さないために、12章を読む上で要求されるソフトウェア群を以下に列記する。12章を読む前にこれらをインストールして動作する状態におけばストレスを感じることなく本文を読むことができるだろう。
 なお、下にあるもので「AURになかった」ものについては私がPKGBUILDを書いてAURに公開しておきましたのでよろしければご利用ください。

形態素解析

最初に使われる形態素解析エンジン。AURにある(mecab)。

Mecabpython用インターフェース。AURにある(python2-mecab等)。

次に使われる形態素解析エンジン。AURになかった。

JUMANをpythonのモジュールとして使うためのバインディング。AURになかった。

構文解析

日本語係り受け解析器。AURになかった。

CaboChaのpython用インターフェース。AURになかった。

日本語構文・格解析器。ファイルサイズがすごく大きい。AURになかった。

megamをpacmanで管理したいのでPKGBUILD書いた

2013-04-08 追記

本文中のPKGBUILDを編集した。

 以前にも書いた「入門 自然言語処理」を読んだり読まなかったりしながらダラダラと過ごしている。

今日第7章を読み始めたのだが、第7章3節、7.3.3の以下の箇所で怒られた。

>>> chunker = ConsecutiveNPChunker(train_sents)
which: no megam.opt in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl:/usr/lib/qt4/bin)
which: no megam in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl:/usr/lib/qt4/bin)
which: no megam_686 in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl:/usr/lib/qt4/bin)
which: no megam_i686.opt in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl:/usr/lib/qt4/bin)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in __init__
  File "<stdin>", line 12, in __init__
  File "/usr/lib/python2.7/site-packages/nltk/classify/maxent.py", line 319, in train
    gaussian_prior_sigma, **cutoffs)
  File "/usr/lib/python2.7/site-packages/nltk/classify/maxent.py", line 1522, in train_maxent_classifier_with_megam
    stdout = call_megam(options)
  File "/usr/lib/python2.7/site-packages/nltk/classify/megam.py", line 163, in call_megam
    config_megam()
  File "/usr/lib/python2.7/site-packages/nltk/classify/megam.py", line 59, in config_megam
    url='http://www.cs.utah.edu/~hal/megam/')
  File "/usr/lib/python2.7/site-packages/nltk/internals.py", line 528, in find_binary
    url, verbose)
  File "/usr/lib/python2.7/site-packages/nltk/internals.py", line 512, in find_file
    raise LookupError('\n\n%s\n%s\n%s' % (div, msg, div))
LookupError: 

===========================================================================
NLTK was unable to find the megam file!
Use software specific configuration paramaters or set the MEGAM environment variable.

  For more information, on megam, see:
    <http://www.cs.utah.edu/~hal/megam/>
===========================================================================
>>>

 megamというプログラムがないらしい。困った

困った時のAURということで検索を掛けてみるとなんとAURに存在しない。更に困った。

 というわけでmegamをpacmanで管理できるように、makepkgでビルドすべくPKGBUILDを書いてみた。

 ちなみにmegamで検索掛けたりエラーメッセージのリンクを踏んでみたりしたがなかなか辿り着けなかったりリンクが死んでたりして苦労したので下の方にmegamのページのリンクを書いておく。ひとつめのリンクがそれに該当する。

 注意すべき点としてmegamの実行形式を作る場合、ソースを落としてきて解凍してmakeしてはい終了というわけにはいかない。実際にやってみると以下のようなエラーを吐く。

/usr/bin/ld: cannot find -lstr
collect2: error: ld returned 1 exit status
File "fastdot_c.c", line 1:
Error: Error while building custom runtime system
make: *** [megam] Error 2

 そのあたりも含めてパッチもつくってみたので以下に置いておく。ちなみにこの問題の具体的な原因及び解決法は下のほうのリンク先を参照してもらいたい。

  • PKGBUILD
pkgname=megam
pkgver=0.92
pkgrel=3
pkgdesc="MEGA Model Optimization Package"
url='http://www.umiacs.umd.edu/~hal/megam/'
arch=('i686' 'x86_64')
license=('custom')
depends=('ocaml')
optdepends=()
makedepends=()
conflicts=()
replaces=()
backup=()
source=('http://hal3.name/megam/megam_src.tgz'
        'megam.patch')                          # Makefileへのパッチ
md5sums=('a8b02d3b62933e2a7fb1f4412840a431'
         '0d79ac56e89615028895b8f5a4df4c27')

build() {
    cd "${srcdir}/megam_${pkgver}"
	patch < "${srcdir}/megam.patch"
	sed -n '/This code/,/ webpage./p' README > LICENSE
	make
	# READMEによると、makeで実行形式をつくるとsafe(安全?確実?)だが遅いものが生成される
	# safeじゃなくていいから速い実行形式が欲しいのなら以下をコメントアウトする
	#make opt
}

package() {
	cd "${srcdir}/megam_${pkgver}"
	install -D -m775 megam "${pkgdir}/usr/bin/megam"
	install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}
  • パッチ
--- Makefile.orig    2007-10-09 02:06:04.000000000 +0900
+++ Makefile	2013-03-16 23:45:19.420694775 +0900
@@ -55,19 +55,19 @@
 
 # Default setting of the WITH* variables. Should be changed if your
 # local libraries are not found by the compiler.
-WITHGRAPHICS =graphics.cma -cclib -lgraphics -cclib -L/usr/X11R6/lib -cclib -lX11
+WITHGRAPHICS =graphics.cma 
 
-WITHUNIX =unix.cma -cclib -lunix
+WITHUNIX =unix.cma 
 
-WITHSTR =str.cma -cclib -lstr
+WITHSTR =str.cma 
 
-WITHBIGARRAY =bigarray.cma -cclib -lbigarray
+WITHBIGARRAY =bigarray.cma 
 
-WITHNUMS =nums.cma -cclib -lnums
+WITHNUMS =nums.cma 
 
-WITHTHREADS =threads.cma -cclib -lthreads
+WITHTHREADS =threads.cma 
 
-WITHDBM =dbm.cma -cclib -lmldbm -cclib -lndbm
+WITHDBM =dbm.cma 
 
 #WITHCLIBS =-I /usr/lib/ocaml/3.09.2/caml
 WITHCLIBS =-I /usr/lib/ocaml/caml
@@ -84,12 +84,12 @@
 
 opt : $(EXEC).opt
 
-#ocamlc -custom other options graphics.cma other files -cclib -lgraphics -cclib -lX11
-#ocamlc -thread -custom other options threads.cma other files -cclib -lthreads
-#ocamlc -custom other options str.cma other files -cclib -lstr
-#ocamlc -custom other options nums.cma other files -cclib -lnums
-#ocamlc -custom other options unix.cma other files -cclib -lunix
-#ocamlc -custom other options dbm.cma other files -cclib -lmldbm -cclib -lndbm
+#ocamlc -custom other options graphics.cma other files
+#ocamlc -thread -custom other options threads.cma other files 
+#ocamlc -custom other options str.cma other files 
+#ocamlc -custom other options nums.cma other files 
+#ocamlc -custom other options unix.cma other files 
+#ocamlc -custom other options dbm.cma other files 
 
 SOURCES1 = $(SOURCES:.mly=.ml)
 SOURCES2 = $(SOURCES1:.mll=.ml)

 AURにも公開済みなので普通に使うならそちらを使ったほうが良い。

 ちなみにmegamをインストールして、先程怒られた箇所を再び叩いてみたが、以下のようになって一向に終わる気配がなくこの問題は解決したようには見えない。中途半端に終わってしまった。

>>>chunker = ConsecutiveNPChunker(train_sents)
optimizing with lambda = 0 
optimizing with lambda = 0
optimizing with lambda = 0
optimizing with lambda = 0
optimizing with lambda = 0
...(以下エンドレス)

参考

# 以下のサイトの手順をただパッチとして起こしただけなのでもしかしたらいろいろと良くない記事なのかもしれない……。