ATOK(iiim)+Firefox 4でFirefox終了時にクラッシュする

Ubuntu 10.04にhttps://launchpad.net/~mozillateam/+archive/firefox-stableMozillaのサイトにあるFirefox 4を導入したところ、いずれも終了時にクラッシュした。

バックトレースをとってみるとgdk_display_closeの中で転けている。

#0  0x00007fffe192a300 in ?? ()
#1  0x00007ffff30285de in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#2  0x00007ffff303c598 in ?? () from /usr/lib/libgobject-2.0.so.0
#3  0x00007ffff303da76 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#4  0x00007ffff303e033 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#5  0x00007ffff3b7a9b2 in gdk_display_close ()
   from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00007ffff622ec59 in MOZ_gdk_display_close (display=0x7fffec371190)
    at /build/buildd/firefox-4.0.1+build1+nobinonly/build-tree/mozilla/toolkit/xre/nsAppRunner.cpp:2701
#7  0x00007ffff6233b0f in XRE_main (argc=<value optimized out>, 
    argv=<value optimized out>, aAppData=<value optimized out>)
    at /build/buildd/firefox-4.0.1+build1+nobinonly/build-tree/mozilla/toolkit/xre/nsAppRunner.cpp:3859
#8  0x00007ffff7ff3ef1 in main (argc=2, argv=0x7fffffffdf78)
    at /build/buildd/firefox-4.0.1+build1+nobinonly/build-tree/mozilla/browser/app/nsBrowserApp.cpp:158

このあたりの関数名をキーワードに検索してみると、398512 - crash on shutdown and before restart (gdk_display_close) with gtk xim moduleが引っかかった。
GTK_IM_MODULEの設定によってクラッシュするとのことなので、

$ GTK_IM_MODULE=scim firefox

scimを指定して起動してみると確かにクラッシュしない。
さらにはこんなことが書いてある。

Looks like iiim is derived from xim and so has the same bug as the xim module (http://bugzilla.gnome.org/show_bug.cgi?id=483223).

あーATOK X3がiiimを使っている。間違いなくこれを踏んでいたわけだ。

パッチを当てるなら後の手間が少なそうなiiimかねぇ・・・

追記

http://memo.officebrook.net/20110407.htmlによれば、GTK_IM_MOUDLE=ximで起動すればよかったらしい。
ximへのワークアラウンドが入っているor既にximは修正されているのかしら。
しかし微妙に挙動不審なので後でiiimへのパッチも考える。

PlalaでIPv6サービスが始まったわけですが。

PlalaでIPv6サービスが始まったので接続できないかと思い調べてみた。
IPv6トンネル対応アダプタというのが必要らしいけれど、純正のハードウェアがなくてもソフトウェアで何とかなるだろうと高をくくりながら調べてみると、対応しているサービスがフレッツ光ネクストだけでBフレッツがない。

[トンネル方式]実現の要となる「アダプタ」の正体 | 日経 xTECH(クロステック) などを参照するに、どうやらNGN上で実現されているらしい。NGNを提供しているのはネクスト系のサービスだから、これは回線契約を変更しないと駄目か……。Bフレッツからフレッツ 光ネクストへ変更時の工事費についてをみるとマンションタイプでは2万円越え。月額は変わらないようだけれど、初期費用が結構高いぞ。

サービスのnice値

Scientific LinuxApacheの起動時にnice値を設定する方法を調べた。
初めに/etc/sysconfig/httpd

HTTPD="nice -n 1 /usr/sbin/httpd"

という設定を試みたが、stopするときにこのコマンド名でkillprocしているところが動作しない。

どうすればいいのかとスクリプトを読んだところ、プログラムの起動は/etc/rc.d/init.d/functionsに定義されているdaemonコマンドで行われており、この中で定義されていればNICELEVELという変数を使っている。
つまり、/etc/sysconfig/httpd

NICELEVEL=1

と設定すればよい。

MoinMoinでアクセス元によってグループに属させる

部で情報蓄積のためのWikiとしてMoinMoinを設置したのであるが、一部のページでログインしない状態では部室内部からのアクセスである場合のみ表示できるようにすることになった。MoinMoinにはACL機能があり、ページ単位でユーザ・グループ別のアクセス許可が出来るのであるが、アクセス元によって制御する機能はない。そこで自前で機能を追加することにした。といっても、本体ソースに手を加えるのはバージョンアップ作業が面倒になるので極力避けたいところであるので、モジュールの追加と設定で解決することにした。

認証処理を拡張して、部室からのアクセスであれば特定のユーザでのアクセスとする事も考えたが、これでは部室からのアクセスが常にログイン状態となり、個々人のログインが出来なくなってしまう。よってこれは却下である。

やはりアクセス元が設定されたものであれば、特定のグループに属しているものとして扱うのが自然だろう。しかし、 http://moinmo.in/Groups2009/ やソースを見るとグループとはユーザ名とグループ名の集合であって、ユーザに関係なくリクエスト単位で属しているかどうかが変わるような使い方はあまり想定されていないように見える。ただし、コンストラクタにrequestを取っているあたり、実装不可能なわけではなさそうだ。

そういうわけで、アクセス元が条件にあえばそのユーザ名のみを含むグループを、条件に合わないなら空のグループを生成するという構造で実装した。ログインしていないユーザに対してもこの構造で動作している。IPアドレス周りの処理はIPyライブラリに丸投げしている。逆引きしたホスト名でのマッチングには未対応である。
http://delegate.uec.ac.jp:8081/club/mma/~ytoku/moin/network_groups.py

設定にあたってはCompositeGroupsを使ってWikiGroupsと組み合わせることで、Wikiのページに記述する通常のグループとの共存が出来る。

from IPy import IP
from network_groups import NetworkGroups
from MoinMoin.datastruct import WikiGroups, CompositeGroups
class FarmConfig(multiconfig.DefaultConfig):
    ...
    groups = lambda cfg, request: CompositeGroups(request,
               NetworkGroups(request, { 'LocalComputer': IP('192.168.0.0/24') }),
               WikiGroups(request))

中途半端にplatex一式がインストールされたUbuntu 10.04でpowerdotを動かしたときの記録

TeXでプレゼンテーションの資料を作りたくなってpowerdotをインストールしたのだが、TeX環境のインストールが不完全だったので動くようになるまで試行錯誤が必要だった。

http://homepages.inf.ed.ac.uk/s0675112/powerdot_intro/powerdot.html を参考にしたが、システムグローバルな部分にパッケージで管理されているもの以外を極力インストールしたくないので、いつも通りスタイルファイルを追加する要領でホームディレクトリへのインストールを行った。

  • CTANからソースをダウンロード
  • 展開してrunディレクトリ以下を、~/.tex/styles/powerdot (TEXINPUTSに追加してある)にコピー

そして、サンプルファイルをダウンロードしてタイプセット。ここまでは順調だった。最初の問題はdvipsの時点で発生した。

$ dvips powerdot-styletest.dvi
This is dvips(k) 5.98 Copyright 2009 Radical Eye Software (www.radicaleye.com)
' TeX output 2010.07.16:0046' -> powerdot-styletest-jp.ps
dvips: ! Bad VF file goth10.vf: character code out of range

Ubuntu 10.04 + Japanese Team Repositoryのdvipsk-jaパッケージは依存関係が壊れているのでローカライズされていないdvipskで今までがんばっていたのだけれども、どうも調べてみるにここに来て問題が顕在化したらしい。
ありがたいことに依存関係を直したdvipsk-jaパッケージを提供してくださっている方がいたので、それを使わせていただくことにした。

インストール後にdvipsコマンドを実行したところ、rml-jis関連のエラーが出たような気がするが、残念ながら記録が残っておらず、入れたパッケージなどを消してみても再現しない。きちんとエラー出力を残しておくべきだったなあ。こんなエラーだったはず(Web上で見つけたよく似たエラーのコピーペースト)。

kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+359/600 --dpi 959 rml-jis
mktexpk: don't know how to create bitmap font for rml-jis.

これに関してはjisftconfig addをrootで走らせて解決した*1。以前にTeXをインストールしたときに実行してるはずだけれど、dvipsk-jaのインストール後にもう一回実行する必要があったのかもしれない。
(記憶によれば)これでdvipsはエラーなく処理が終わるようになった。しかし、出てきたpsファイルをgvコマンドで表示してみると日本語部分が完全にアルファベットと記号に化けていた。gvコマンドのエラー出力をみるとRyumin-LightがGhostScript下にないと言ったエラーが出ていたように思う。これはdvips側ではなくpsファイルのビューア側の問題らしいので*2 https://wiki.ubuntulinux.jp/JapaneseLocalizedDerivative/LaTeXForJapanese にあるパッケージ

  • xpdf-japanese
  • gs-cjk-resource
  • poppler-data

をインストールしたところ文字は正しく表示されるようになった。psファイルの文字化けに対してはgs-cjk-resourceが、ps2pdfでPDFに変換した後のevinceのエラーメッセージ

Error: Missing language pack for 'Adobe-Japan1' mapping

にはpoppler-dataが効いたのだったような覚えがある*3 *4



さて、PDFまで作成できたわけだができあがったPDFをみてみると何かがおかしい。スライドのサイズはpaper=screenになっておりスクリーン投影用の4:3であるが、よく見みると右側が切れてほぼ正方形になっている。探してみるとそのものなQAがあった。

dvipsのconfig.psが古いとのことである。しかし、dvipsは先ほど日本語対応のものをインストールしたばかりであるから更新する必要があるとは考えたくないので、回答に書いてあることを信じてconfig.psだけ最新版にすることを試みた。dvipsk-jaのconfig.psは/etc/texmf/dvipsj/config.psに、dvipskのconfig.psは/etc/texmf/dvips/config/config.psにある。dvipskのconfig.psをみてみると、確かにscreen用の記述がみられる。

@ screen 8.25in 11in
@+ ! %%DocumentPaperSizes: Screen
@+ %%BeginPaperSize: Screen
@+ /setpagedevice where
@+  { pop << /PageSize [594 792] >> setpagedevice }
@+ if
@+ %%EndPaperSize

そこでとりあえずバックアップをとってdvipsk-jaのconfig.psをdvipskのconfig.psで上書きしてみた。すると次のようなエラーになった。

$ dvips powerdot-styletest-jp.dvi 
This is pdvips(k) p1.7b Copyright 2010 ASCII MEDIA WORKS. (ptex-staff@ml.asciimw.jp)
based on dvips(k) 5.98dev Copyright 2010 Radical Eye Software (www.radicaleye.com)
' TeX output 2010.07.16:0046' -> powerdot-styletest-jp.ps

kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 2+186/600 --dpi 1386 gbm
mktexpk: don't know how to create bitmap font for gbm.
kpathsea: Appending font creation commands to missfont.log.
dvips: Font gbm not found; using cmr10

dvips: ! invalid char 9267 from font gbm

またフォント関連でエラーが発生している。config.ps中にあったフォントの設定を移さなければならないのだろうと見当をつけて読んでみると、dvipsk-jaに含まれていたconfig.psには

p +psfonts_jp.map

という記述があった。これを追加したところエラーが発生しなくなり、正しいサイズのスライドが出力されるようになった。


はあ、やっとこれでスライドが作れる……

contranym「先」

何となく使っていたけれど「先」という言葉はコントラニム*1だったのか。

さき【先/▽前】
8 未来のある時点。将来。前途。「―を見通しての計画」「―の楽しみな青年」
9 時間的に前。あることより前。「代金を払うのが―だ」「ひと足―に帰る」⇔あと。
10 現在からそう遠くない過去。以前。「―の台風の被害」「―の大臣」

デジタル大辞泉より

*1:それ自身、逆の意味も持つ単語 http://www.askoxford.com/asktheexperts/faq/aboutwords/contranym

-fformat-extensions

GCC4.4をインストールしてあるFreeBSD 8.0にfusefs-kmodをインストールしようとした所、次のようなエラーが出たらしい。

cc1: error: unrecognized command line option "-fformat-extensions"

調べてみるとこれはFreeBSD独自の拡張のようである*1
/usr/src/gnu/usr.bin/cc/cc_tools/freebsd.opt を見ると確かに

fformat-extensions
Common Report Var(flag_format_extensions) Init(0)
Allow FreeBSD kernel-specific printf format specifiers.

というオプションが用意されていた。どうやらGCC4.4の方にこのパッチがあたっていないようだ。