今回は Python の
ctypes
モジュールを使い
C++ クラスを Python から呼び出してみました。
ctypes モジュールは
python2.5
以降では標準で含まれるようです。
まずは C++ クラスのコンストラクタ、デストラクタ、メンバ関数の wrapper 関数を作り、
Python から呼び出してみました。
題材は昨今作成中の詰将棋プログラムです。
以下のサンプル出力では、
まず共有ライブラリ
libcshogi.so
をロードし、
次にコンストラクタに盤面情報を文字列で渡し、
最後に探索メソッドを呼び出し、解答を出力しています。
ctypes は使い易い。Python 標準実装と云うのも心強いし、
とりあえず決まりかな^^
$ python2.5
>>> import ctypes
>>> so=ctypes.CDLL("./libcshogi.so")
>>> cp=so.cshogi_create('K32S22S34L11P13P23P44~R2BG3S2N4L3Pe/P54b53p41~G/')
9 8 7 6 5 4 3 2 1
|.|.|.|.|.|p|.|.|L|1 {R2,B,G3,S2,N4,L3,Pe}
|.|.|.|.|.|.|K|S|.|2
|.|.|.|.|b|.|.|P|P|3
|.|.|.|.|P|P|S|.|.|4
|.|.|.|.|.|.|.|.|.|5
|.|.|.|.|.|.|.|.|.|6
|.|.|.|.|.|.|.|.|.|7
|.|.|.|.|.|.|.|.|.|8
|.|.|.|.|.|.|.|.|.|9 {G}
>>> so.cshogi_solve(cp, 7)
G33 K2132 b3153 S3122 p3141 K3121 S32
G33 K2132 b3153 S3122 p3141 K1221 S21
SIP
を使い C++ クラスを Python から呼び出してみました。
他にも
boost
や
SWIG
などあるらしいけど、こいつは軽快。良いかも。
たとえばこんな C++ クラス word.h があったとして、
class Word {
private:
char* _word;
public:
Word(const char*);
const char* str() const { return _word; }
void set(const char*);
char* reverse() const;
};
sip を使いゴニョゴニョした後、
$ python
>>> from word import Word
>>> w=Word('abc')
>>> w.str()
'abc'
>>> w.reverse()
'cba'
>>> w.set('xyz')
>>> w.str()
'xyz'
こんなふうに Python からクラスとして扱えます。
"operator=" などサポートして無いものもあるらしいけど、スゴイ^^
これで Python や VC++ が入って無い環境でも棋譜ブラウザ zbrowser は使えることが分かりました。
それよりも Linux 環境でこしらえた GUI アプリケーションが、
そのまま遜色無く動作したことに感激してます。ありがたいことです。
もし試すなら 旧象歩から PyShogi-0.5.x.lzh の最新版をダウンロードし解凍してください。
zbrowser.exe をクリックするだけで左のような画面が現れるはずです。
「みんPy」 と云っても 某ベストセラー本 のことではありませんよ ;-p)
ming-py-0.3.0 に パッチ をあてました。 昨日の C++ コード を python で書き直したもの ↓ で試したところ、 SWF (FLASH) ファイル はできました。
# vim: set fileencoding=utf-8 enc=utf-8 :
from ming import *
movie = SWFMovie()
movie.setDimension(640, 480)
# 写真
photo = SWFBitmap('machi2006-02r.jpg')
movie.add(photo)
# タイトル
font = SWFFont('Mincho.fdb')
text = SWFText()
text.setFont(font)
text.setColor(0x00, 0x00, 0x00, 0xff)
text.setHeight(30)
text.addUTF8String("祭り唄")
item = movie.add(text)
item.moveTo(10, 30)
# サウンド
opt = SWF_SOUND_ADPCM_COMPRESSED | SWF_SOUND_16BITS
sound = SWFSound('machi-05k.adpcm', opt)
movie.startSound(sound);
movie.save('sample.swf')
ログを集計してみました。
縦軸は 対数目盛 にしてあります。
グラフの画像は procmail のログを python で抽出し、
PostScript 形式で出力して作りました。
unsure (判定できなかったもの) はこのところ 0.5% 前後と好成績。
日に一件くらいまで納まって来てます。
実用上無視できるレベルです。
それにしても、最近はスパムが 50% 越えてます。
仮にフィルタリングしないとすると大変です。
スパム送信者は回線コストを半分負担してほしい気持ち。
どういう理由か CO2 排出規制に消極的な御国からのメールが多いようです。
この一週間はスパム判定できなかったものが 0.45 % までになりました。
受信メールが 1117 件で判定できなかったものが 5 件。
判定ミスは 0 件です。
しかも判定できなかったメールはアマ*ンや*ラットホームからのダイレクトメール等、
自分でもどちらに振り分けようか悩んでるものでした。
新しいパタンのスパムが来れば、即座に判定できない可能性はありますが、
それを振り分けるのも面白いと感じるようになってきました。
この前、某メモでフレームになりかけた投稿があり、
ほぼスパム判定 (unsure) されて迷ったのですが、一応受け取ること (ham) にしました。
ところで spambayes-1.0.3 のパッチを持って行かれる方がいらっしゃります。
信用できないから web インターフェースのパッチだけで良いと云う場合は構わないのですが、
日本語トークン分割した
spambayes-1.0.4 は、こちら
ですので、興味ある方には試して貰えるとうれしい。
Vine-3.2 の方は extras を有効にすれば、apt-get で即入ります。
下記テーブルはオリジナルの SpamBayes を導入してからの集計です。
procmail のログから抽出しました。
「総数」は受信したメールの総数です。
「未判定数」は、スパムだけで無く、必要なメールも含んだ数です。
spambayes を POP3 Proxy として使ってみると、
from header やら subject の切り落としなどで文字化けしてます。
直そうと云う気が起きましたが、思い留まりました。
改めて tokenizer.py のソースを見ると、
subject と body の日本語対応だけにして置いたのは、結果的に良かったと思ってます。
オリジナルソースのコメントを読むと、いろいろ試行錯誤してたどり着いたことが見えます。
考えも無く修正を加えるのは愚かなこと。
オリジナルソースを汚すのは最小限にしないといけません。
それよりも、ベイズフィルタ部分を理解するのが先だし、
今のところ日本語スプリッタを深追いする気もありません。
web インターフェースは
spambayes-1.1a
を見ると i18n 化が始まってるようです。
しいて手を加えるとすれば、 rpm パッケージに POP3 Proxy 用
daemon スクリプト
を追加し、ついでに
Sylpheed
との連携を考えることくらいです。
モー少し便利になるかもしれません。
POP3 Proxy
動作 (sb_server.py) させてみました。
面白い^^。日本語もちゃんと評価されてる様子で、少し期待してます。
ブラウザで表示して見ると、日本語表示があちこち文字化けして、みっともないので
修正版
を置きました。このまま問題が出なければ、
週末に家の
imap
鯖のフィルタとして組み込んでテストするつもりです。
spambayes-1.0.4-*-patch
に関しては、みたところ
spambayes-1.0.3
と
1.0.4
の該当ソースに変更は無いので、
1.0.3
にもそのまま当たると思います。
(>
debian 方面の方
)
前回の
SpamBayes 日本語化
は、GUI 画面だけでしたが、今回は、日本語トークンの抽出を試みました。
トークンの抽出は、
UnicodeBlockTokenizer
を改造して使用しています。
処理速度を上げるため
generator
化しました。
また ascii 文字列も分割した方が良さそうでしたので、稚拙なコードを追加してあります。
今後、トークン分割で勝手にコードを追加して行くことになると思うので、
モジュールの名前は変更しました。
ソースとパッチは
ここ
にまとめて置いてあります。
日本語トークンはとりあえず
utf-8
でエンコードされた
str
型で返してます。
本来は
unicode
型で返したいところですが、
その後の処理を調べてませんので。
今回は
tokenizer
コードに手を入れただけで、
トークン抽出以降の処理はまったく調べていません。
とは云え (運良くこのまま) ベイジアンフィルタ処理部分が通してくれれば、
何もしないで動く可能性はあります。まあ、その反対は地獄と云うこと。
その話は、また次の機会ってことで、かんべん。
XMLRPC は難しいのかと思えば、
smallp2p
など参考にすると意外に易しいのかも。
鯖立てるのは下記のようなコード
server.py
でとりあえず可能でした。
#!/usr/bin/env python
from SimpleXMLRPCServer import SimpleXMLRPCServer
import sys, socket
class RPCMethods:
def next(self, s=''):
print 'received:', s
return 0
def main():
sv = SimpleXMLRPCServer((socket.gethostname(), int(sys.argv[1])))
sv.register_instance(RPCMethods())
sv.serve_forever()
if __name__ == "__main__":
main()
起動は
$ python server.py <ポート番号>
エイプリルフールねたで辟易していたら、寝しなにトドメをさされた感じ。
Guido さんが
Stricter Whitespace Enforcement
と云うお題で書いてます。
PyJUGもたちが悪い。
Python の新たな構文
なんてマジで解説してます。
これは困りました。
私は vi (vim) 使いなので、キーストロークが少なくて済む「TABを使う派」なのです。
えーTAB使えなくなるんですか?
タブがタブーなんて言ってる場合じゃないですよね。
確かに Python の最大の長所であり、かつ究極の弱点はインデントだと感じてたのですが。
これではエディタ選びから始めないと Python2.5 以降使えないですね (T.T)
Imaging-1.1.5c1
が公開されていました。
PNG 保存時に補助情報 (chunk) を指定できるようになってたので、
パッチ
は不要です。
dpi
は引数で直接渡し、
その他の補助情報は
PngInfo
インスタンスに格納して渡すことができます。
from PIL import Image
from PIL.PngImagePlugin import PngInfo
im = Image.new('RGBA',(200, 200),(0,0,0,0))
# 画像描画処理をおこなう
info = PngInfo()
info.add('bKGD', '\000\377\000\377\000\377')
im.save('img-rgba.png', 'PNG', dpi=(72,72), pnginfo=info)
雪山でキャンプしてる人達や、雪のため電車が遅れて打ち合わせに参加し損なった人が居る中で、のんびり 将棋界で一番長い日 を楽しもうと思ったのだけどやっぱり無理でした。
象歩の将棋盤は
Python Imaging Library (PIL)
を使ってダイレクトに PNG 画像を作ってるわけですが、
IE6.x では PNG の透明画像をうまく表示できないようです。 256 色パレットの透明色は表示できるようなのですが、RGB ＋ αチャネル付きが表示できません。
他のブラウザでは表示できてるから書いてるのですが。
少しだけ調べてみると PNG ファイルのヘッダに
bKGD chunk
ブロックを追加するとうまく表示できるらしいと判りました。
これは必須 chunk では無いので IE のバグでしょう。
ということでパッチ
Imaging-1.1.4-PIL-RGBA.patch
を作成。これで一応背景色は透けて見えます。
python 2.4 になると CJKCodecs が組み込みですが、兄弟のような名前の CJKSplitter はどんなもんなんだろうか? python2.3 環境で試してみました。
cjksplitter-0_7_1.tgz を解凍して実験。 zope モジュールを使うのでパスも通します。
$ cd CJKSplitter/
$ export PYTHONPATH="/usr/lib/zope/lib/python"
$ python
>>> from CJKSplitter import CJKSplitter
>>> u = unicode("漢字とカナabcだー!!oz,012 ^^ そんな※（−−；)", 'euc-jp')
>>> for x in CJKSplitter().process([u]):
... print x.encode('euc-jp')
...
漢字
字と
と
abc
だ
oz
012
そん
んな
な
>>>
追記: ごめんなさい。これは無知を背景にした脊髄反射的な誤解ですね。 フカマチさんの日記 (2006/01/06) にとても判り易い説明があります。
それではと、 UnicodeBlockTokenizer を試してみた。
Python で書かれています。
軽くてフィルタ効率が良いと評判のプログラムなのですが、日本語メールに対応していません。
スパムメールを振り分ける時に Subject が文字化けしてしまい困ります。
統計に人間の意志を加味するところが肝ですから残念。
ちょっとだけ修正してみました。
とりあえず Subject の文字化け対処と、
マウスカーソルを上に持って行ったときに出るサマリ表示はうまくいきました。
パッチは (ProxyUI, PyMeldLite) の二つです。
ftp://owa.as.wakwak.ne.jp/pub/spambayes
これは試験版 (無保証、無責任) なので、利用なさりたい方は覚悟の上でどうぞ。
Matzにっき
に nQueen の観戦記あります。Squeak 強し。
sumim's smalltalking-tos
読むと林さんの nQueen は全戦全勝だったらしい^^
そして梅澤さん (Squeak) のデモは大うけだっだと。
一方
turkyさん
の記事
見ると Python ではイテレータ、ジェネレータのお勉強ネタ。メモ(^_^)β...
nQueen のお題では Python 陣営頑張りすぎたのか;?
おおしまさん曰く
「処理系が速いのがSqueakの良いところのひとつでもありますね」とのこと。
でも本当のところは会場に行ってみないと判らないでしょうね、自分は外野席で寂しくテレビを見ておりました。
アジアカップ優勝バンザイ ^..^
LL Weekend
がまた開催される。あつい夏になりそう。
東京で仕事していた頃は、こういう企画があれば気軽に参加できる環境に居たわけだけど、なんとかの有難味は失ってみないと分からない。二日連続では無理かなー