Programming」カテゴリーアーカイブ

SeeMe V5 001

SeeMe for Windows の Opera 10.60 対応版は IronPython で作ります。
一年前に途中まで作ってみたけど色々あってボツにした下記をベースで。

SeeMe is to IronPython

Linux しか使わなくなった作者が Windows のアプリを作るのは苦痛でしかない。
というより作者自身が使わないアプリを作ってもメンテナンスに疑問が残る。
こんな需要が少ないアプリを他の人がやってくれるとも思えない。
それより今の C# という言語が自分の趣味に合わない、Ruby が嫌いな理由と同じ。
ついでに VisualStudio を使いたくない、コンパイルもメンドクサイ。

一週間悩んだ結果、好き勝手にやることにした。
使いたい人は IronPython を導入してくれ、というトンデモネェ暴挙をマジでやる。

もちろんスクリプトのままで配る。
Windows しか使えない人の大半は EXE でないと拒否反応をするのは知っている。
それがキッカケで IronPython に興味を持ってくれる人が増えれば嬉しい。

戯言終わり、ということで。

xml:lang

現行の IronPyton では XAML に xml:lang=”ja-JP” を追記せずとも文字化けしない。
結局アレは IronPython のバグだったのだろうか?

WPF ListView DataBinding for IronPython

この pyevent.py をコピーさせなければいけないのもなんとかしたい。
ということでよく考えてみたらコレでいいのでは?と。

from System import *
from System.ComponentModel import *

# Search pyevent.py
import sys
tutorial_path = IO.Path.GetDirectoryName(sys.executable) + "\\Tutorial"
sys.path.insert(0, tutorial_path)
from pyevent import *

zip 版でも exe パス直下に Tutorial ディレクトリがあるのでイケるはず。
なんにせよ INotifyPropertyChanged は使わなければいけないわけで。
ただ zip 版を考えると os.path.join() は使えない…
追記 System.IO.Path.Combine() ってのがあった。

.NET Framework required BOM

この件もあった…
inifile8.py は他に os.path.exists を System.IO.File.Exists に書き換えて…
sys は組み込まれているけど他は Python 標準モジュールを使わないように…

SeeMe for Linux と共用できるコードがほとんど無いんだなコレが。

あとは x64 を見分けて Opera デフォルトインストール場所振り分けとか。
それから何があったかなぁ?もう少し更新が遅れるのはご了承。
とりあえず現在までのバックアップ。

seeme5_001.zip

少し楽しくなってきた、こんなことをやりながら作り上げていくのが楽しいんだよね。
「プログラミングを楽しむ」と「アプリを作って楽しむ」とでは実は少し違うのよ。

g_utf8_collate_key_for_filename of ctypes

g_utf8_collate_key_for_filename
がいったいどういう変換をしているかもう少し。

ところで端末に長々と打ち込むのが面倒なので GEdit 外部ツールに以下を指定。
GTK+ を使うには pkg-config 指定が必要なのよね、キーは F7 にした。

/*
gedit tool script

#!/bin/sh
gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-2.0`
*/

#include <stdio.h>
#include <gtk/gtk.h>
#include <glib.h>

int main() {
    gchar c[4];
    int i;
    for (i=0; i<105; i++) {
        sprintf(c, "%d", i);
        gchar *s = g_utf8_collate_key_for_filename (c, -1);
        printf("%s\n", s);
        g_free(s);
    }
    return 0;
}

端末だと解り難いにでリダイレクトしてみる。

十進で桁が増える毎にコロンが一つ付加されていくようだ。
なんだかよく解らない変換だけどこれで自然順ソート比較は上手くいくようだ。
色々やってみたけど結局 Python から ctypes を使う。

14.14.1 ctypesチュートリアル

ココに全部書いているんだが、Linux はちびっと面倒なのね。

glibc = ctypes.cdll.LoadLibrary('libglib-2.0.so.0')
cmpstr = glibc.g_utf8_collate_key_for_filename("a")

とやっても int が戻ってくる、実際にはポインタだが Python にはポインタ型が無いので。
つまり restype をキッチリ指定しないと全部 int になるってことですね。
ということで。

#! /usr/bin/env python
# -*- coding: UTF-8 -*-

import ctypes

glibc = ctypes.cdll.LoadLibrary('libglib-2.0.so.0')
cmpstr = glibc.g_utf8_collate_key_for_filename
cmpstr.restype = ctypes.c_char_p
cmpstr.argtypes = [ctypes.c_char_p, ctypes.c_int]

def sort_nicely(l):
    l.sort(lambda x, y : cmp(cmpstr(x, -1), cmpstr(y, -1)))

たまには lambda を使ってみようと思ったので。
ガベージコレクションなのだからコレでいいはずだけど…
とにかくこれでどうだ?

よし Nautilus とはドットファイルを除けば一致するようになった。
隠しファイルはリストアップに含めないようにする予定なのでどうでもいいけど。

でも Mandriva KDE 上で動かしたら何故か数値ソートしてくれなかった。
って ./ を付け忘れで以前のバージョンを起動しただけだった、GNOME と同様になる。
つか Dolphin のソートって以前の関数とまったく同じ結果じゃん!

これじゃ設定でどちらかに振り分けしてもらうしか両対応の方法が無さそう。

utf8_collate_key

いいかげんに Y901x が落ちまくる件とソート問題を解決させねば。
なんとかさせないと追加機能もやれないよ。
落ちる件は色々試しているんだがまだ原因が解らない、困った…

ソートに関しては自力を諦め Nautilus のコードをひたすら追う。
libnautilus-private/nautilus-file.c
に compare_by_display_name というソレっぽい関数をやっと見つける。

display_name_collation_key を strcmp で比較しているだけなのか。
g_utf8_collate_key_for_filename という glib の関数で代入している。

Unicode Manipulation

あれ、もしかして数値もドットもこの関数一つで解決してまうの?

The Whole PyGTK FAQ

Python には実装されていないようで。
最近のバージョンではあるかもと dir() で探しまくるも見つからず。

とにかくこの関数でどう変換されるのか気になるので C でやってみる。
Ubuntu 10.04 デフォルトでは gcc はあるけど gtk や glib のヘッダは無い。
Glade を入れれば依存関係で Devhelp を含めまとめて入るので Glade を入れる。

/*
gcc  b.c `pkg-config --cflags --libs gtk+-2.0`
*/

#include <stdio.h>
#include <gtk/gtk.h>
#include <glib.h>

int main() {
    gchar *c;
    c = "a1.mp4";
    gchar *u;
    u = g_utf8_collate_key_for_filename (c, -1);
    printf("%s to %s\n", c, u);
    /*g_free(c); is Segmentation fault*/
    g_free(u);
    return 0;
}

久々の C なんだがこんな感じでよかったかなぁ…
strcpy で警告になったのが Visual Studio と同じだったが代替が解らない。
とにかく結果。

なんだかよく解らないのに変換されとる。
後は比較関数を作って実験して上手くいったら…
Python で使うんだが、ctypes しか手が無いかな?

Human sort 2

仕事関連でドタバタしており Blog の更新が止まりがちになっています。
今月は落ち着きそうな希望が少々持てるのでちょっぴりがんばってみる予定。
ということで

前々回(って半月前か…)

の自然順ソート仕様で我が Y901x のリストアップを色々試していた。
サボっていたのではなく地味にテストはしていた、とにかく解ったのは問題だらけ!

最大の問題は aa.mp4 aa1.mp4 等というファイルがあったとき。
Nautilus では aa.mp4 が当然のように上になる、前々回の関数では逆になってしまう。

原因が解らなくてしばらく悩んだけど解ってしまえば単純。
前々回のコードではドットは単なる文字列の一部としか認識しないからだ。
分離され整数変換された値とドットという文字列を比較ならば当然ドットのほうが大きな値と認識する。
結果 aa.mp4 のほうが aa1.mp4 より大きいと認識するファイル名になってしまう。

なんだそれ…
これじゃ拡張子が付いたファイル名では全部同じようになってしまう。
いや Linux の場合はそれだけじゃない、ドットファイルという文化があるのだから。
以下のようなファイル名を用意してテスト、nautilus は隠しファイルを表示設定に。

Python の文字列比較は先頭から一文字単位で照合しているだけ、当然の結果。
整数文字列の比較は確かに行っているけどこうなってしまう、落とし穴が深すぎだった。
Windows の Explorer 名前順ではドットファイルは先頭になるが Nautilus は日本語より下。
同じ自然順ソートでもドットをどう扱うかが違うようで。

とにかくファイル名の場合は前々回のソート関数では Nautilus とは同じにはならない。
というかドットファイルどころかバックアップファイルにも無考慮だと今頃気がつく私であった。
後日に続く(終わりカヨ!

Visual Studio 2010

Visual Studio 2010 はこんな優待パッケージがあるのね。

今日現在 33,390 円にて予約受付中。
たしかにアップグレード版との比較なら超お買い得なんだが、正直微妙な値段設定だ。

Standard Edition ライセンス保持者対象だなんてありえない、挫折者九割越えが目に見えているのに。
VC6 の時一度挫折した人間は思う、Delphi 5 がこの世に出なかったら今の私は確実に只のオッサン。
開発に興味を持つ若い人の意識が当時と全然変わっていないなんて Blog 検索をすれば解る。
大げさに書くと統合開発環境を手に入れれば魔法のようにアプリが作れると思い込むとかね。

.NET Framework のメジャー更新毎に六万円を支払うことに疑問を持った人達を引き止めたいのかも。
それだったら一万円代が限界かと…

とはいえコッチより全然安い。
一旦 Std 版を手に入れ安上がりに Pro 版を仕入れたいなら面倒だけどこんなルートがある。
VS2008 Pro を持っている私には関係なかったりするんですけど。
少なくとも公開するアプリを作りたいなら正規のライセンスを持っていないと後が怖い。

さて私はどうしよう?
minipoli のメンテを続けるだけなら VS2008 のままでイケるわけで。
C# で SeeMe 以外を作りたくなったら、それまで待つと売り切れの可能性。
しかしその頃には別の販促バージョンが出るような、これは迷う。

IronPython つか DLR の初期化がもう少し早ければ笑い飛ばせるんだが…
と、Ubuntu Linux の Gedit で書いている現実では説得力の欠片もありゃしねぇ。