kernel-smp-2.6.12-0vl5 は残念ながら断念。 apt-get で調子良くインストールできたけど、X11 で固まる。gnome で落ちるのと同じ原因かも。 Serial ATA の HD 頂いたので、使ってみようと思ったけど、暫く延期です、残念。 ちょっと玄人志向 (RADEON 7000) を疑ってます (と云うかドライバを) 。 原因探りたくても、OS ごと落ちるので、HDD 壊したばかりの身では、あまり試したく無い雰囲気。 DVI 使えて、安くて、安定感のある video ボードは無いかなー kernel-headers は kernel22-headers が入ってしまって...なんか変。

Vine-4.0 のロードマップが更新 (6/9) されてます。 http://www.vinelinux.org/roadmap.html 書いて無いけど PPC 版は Apple に Intel 入ったら自然消滅か? # うちの G4 はお払い箱で、新しい仕事が舞い込んでくるのかなー (っそれは甘過ぎ;;

WindowMaker の最新では utf-8 になってるので、ちゃんと日本語タイトルが表示されます。 ○ WindowMaker-0.91.0-0vl3 -- OK ● WindowMaker-0.80.2-0vl3 -- NG でも、昨日は gnome も ok と書いたけど勘違い。うまく表示できません。 WM タイトルには euc-jp でも utf-8 でもそれなりに渡ってるみたいですが、表示は NG。 文字化けしてるだけで、表示桁は合ってるので、フォントの設定らしい。 XSetWMName() で渡してるので、ウィンドウマネージャが XGetWMName() で受け取った後の処理の話し。 いろいろ問題があるので、週末 upload の予定は止めるつもり。ウィンドウマネージャは他にもあるし。 Tk だけのせいじゃ無いようです。ごめんなさい。 追記: つい最近出た tk-8.4.10 に対応コードがありました。やはり問題があるのは解かってたらしい。古いコードに、追加する形式で修正されていたので、パクリました。ただ、tk-8.4.10 にするのは、他に影響が多いので、余裕がある時期に、いずれ。 と云うわけでパッチを修正しました(ファイル名は同じ) ftp://owa.as.wakwak.ne.jp/pub/Vine/VineSeed/patch/tk-8.4.6-tkUnixWm.patch

>>243 多分 tk8.4.6/unix/tkUnixWm.c の XSetWMName あたりの間違いか、環境設定 やはり tk のせい? tk8.4.6/unix/tkUnixWm.c の中では、ロケールにしたがって WM タイトルを書き出してます。 一方、最近の X11 は utf-8 でタイトルを書かないといけないみたい (自信なし)。 うちの WindowMaker 環境ではそのようです。X11 の環境変数にでも書いてあるのかな。 というわけでパッチ作成 ftp://owa.as.wakwak.ne.jp/pub/vine/4.0/patch/tk-8.4.6-tkUnixWm.patch いまのところ、tk や tkinter でうまく日本語タイトル表示されてます。 追記: どうせ忘れるので、tk でのタイトルなどの表示方法書いて置きます。 $ wish % wm title . "あいう" % wm title . あいう % tk_messageBox -title "かきく" (OK ボタンを押す) % label .label -text "名前:" .label % entry .entry -width 20 -relief sunken -bd 2 -textvariable name .entry % pack .label .entry -side left -padx 1m -pady 2m % ^D 起動→タイトル設定→設定値取得→ダイアログ表示→ラベルとエディットBOX表示→終了

python-PyGreSQL-3.6.2-0vl3 感謝です。 ^ ^/

>>242 Tcl/Tk でウインドウの日本語タイトルが出ません とりあえず Xlib でタイトル表示 (utf-8) のテスト。 ------------------------------------------------------------------------- #include <stdio.h> #include <X11/Xlib.h> #include <X11/Xutil.h> int main() { Display* d = XOpenDisplay(NULL); Window r = RootWindow(d, 0); Window w = XCreateSimpleWindow(d, r, 0, 0, 100, 80, 2, 0, 1); // char* s = u"あいう"; char s[] = {0xe3, 0x81, 0x82, 0xe3, 0x81, 0x84, 0xe3, 0x81, 0x86, 0}; char* sl[1] = {s}; XTextProperty ct; XStringListToTextProperty(sl, 1, &ct); XSetWMName(d, w, &ct); XMapWindow(d, w); XFlush(d); getchar(); XCloseDisplay(d); return 0; } ------------------------------------------------------------------------- $ gcc -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 hoge.c Xlib でタイトル表示はできるど、TclTk で出来ない理由は判りません。 多分 tk8.4.6/unix/tkUnixWm.c の XSetWMName あたりの間違いか、環境設定だろうけど、解かりません。 でも今週は時間がありませんので、深みに嵌まる前に、敵前逃亡します。スマソ;;

Tcl/Tk でウインドウの日本語タイトルが出ません。ascii なら ok。 $ wish % tk_messageBox -title "あいう" 他のウィジェットは正常に日本語が表示されます。出ないのはウィンドウマネージャのタイトルだけ。当然 tkinter の日本語タイトルも出ません。確か Vine-2.9 あたりでは、ちゃんと表示されていたと思う。そのあたりで WindowMaker も Gnome も utf-8 になってるし。Tcl/Tk も utf-8。ただ kterm は euc-jp なので、euc-jp で渡さないといけないのかも? うーん。Tcl/Tk と WindowMaker を最後に upload したのは僕なんだよなー 調べてみますけど、明日は出張なんで、今日は早寝します;;

>>237 pykf, kconv CJKCodecs があるのでいまさらの感じですが、日本語の文字コードを判別する場合に、今だ必須プログラムだと思います。 文字コード変換は、当然 python 標準の CJKCodecs を使うべきです。 なぜ kconv-1.1.8p-3 なのか 1. kconv-1.1.8 C 言語バージョンをなぜ使わないのか C 言語バージョンは落ちると云う話を、昔よく聞きました。情報源は記憶にありません。 現在の安定版は、古いですが 1.1.8p-3 だと考えてます。問題があればパッチを当てることで対処するつもりです。 2. 新しいメンテナの最新版 python-kconv-1.3.1 をなぜ使わないのか 仕様に変更があったのか、動かないと言われたことがあります。またメンテを引き継いだと云われるけど、 http://sourceforge.jp/projects/kconv/ ここを見ると、2003-02-12 のバージョンのまま放置されてます。 どちらも優れたプログラムです。だた本質的に判断できない文字列が存在します。この場合、経験的に pykf は Shft_JIS 側、kconv は euc-jp 側の判断を下すようです。なので、どちらも必要です。適用範囲や対応エンコードも若干異なります。また、これらを利用したプログラムが存在します。たとえば COREBlog や JCodeChanger です。 kconv に関しては、作者が問題ありとしてますので、この辺は考慮しないといけません。 http://apache.noexistent.com/~mak/kconv/kconv/index_jp.html とは云うものの、自分で使った感じでは kconv すばらしいと思ってます。

spec ファイルで python ビルドする時のメモ。 rpm 作成時に、ビルドする場所は ~/rpm/BUILD の下です。そしてインストール場所は別の場所。多くは *.pyc や *.pyo ファイルが出来るのですが、これは少し困ります。インストール後の実行時に例外が起きたりして、エラートレースが表示された場合 ~/rpm/BUILD のディレクトリがまる見えになるからです。本当は実際のインストール場所を表示してほしいです。 python ライブラリの場合は *.pyc, *.pyo は消してしまった方が無難のようです。どうせ import すれば *.pyc は出来ますし、オプティマイズをかけた *.pyo もどれだけ効果があるのか疑わしい。たとえば、こんな記事があります。 http://zenkai.atransia.co.jp/blog/32 python アプリの場合にも、上記のことが云えるのかもしれませんが、独自に手段を用意してるものがあるようです。 skencil の場合には、setup.py に与えるパラメタを、下記のようにすれば良かったです。 ./setup.py install --dest-dir=%{buildroot} --prefix=%{_prefix} zope の場合には ./configure --no-compile と云うオプションがあります。 そしてインストール後に $INSTANCE/bin/compilezpy.py を実行します。

命名法は難しいなー PIL を VineSeed に上げるのに、勝手に python-Imaging と云う名前をでっち上げたのだけど、世間では python-imaging と云うじゃないですか。元もと野良ビルドで python-PIL なんて、何も考えないで付けていたのが遠因。確かに python-Imaging なんて名前は変ですね。そして斬られました;; パッケージ作成ポリシなどと云う哄笑なものを私が考えたのが間違い。python ライブラリの頭には "python-" と付けましょう、などと云うくらいしか頭になかった。元からあるパッケージ名が Imaging なのだから、プレフィックスを付けて、pythin-Imaging だろうと単細胞的な命名。じゃあ本当は Python Imaging Library のパッケージ名はどうすべきなのか。 バージョンの振り方についても Squeak などを考えると、頭が割れそうになるくらい難しいので止めて。たとえば COREBlog を例にしてみれば、バージョン 1.11 の次は 1.2 になってます。これはカンマを少数点と考えてると受け取れます。でも rpm の世界は逆 1.11 > 1.2 です。もちろん、パッケージングは、オリジナルに従属すべきもので、作者に意見を言うべき筋合ではありません。キッパリ。 とか考えてたら、python パッケージングポリシには命名法も必要なんだと、やっと今日解かりました。