bazaarがすごすぎる

mainフォルダを作ってファイルを追加してコミット
bzr branch main trunkでtrunkブランチを作成
trunkでファイルを更新してコミット
bzr push main
bzr brach main testでtestブランチを作成
testでファイルを更新してコミット
trunkでbzr pull
trunkでファイルを更新してコミット
bzr push
testでbzr pull
testでファイルを更新してコミット
bzr push
bzr logで表示されるログがすごいことになってた。枝が一切なく真っ直ぐなログ。
もしかしてbzr branch は枝を作らずただbranch nickを書き換えるだけなのか？
意味不明すぎてすごすぎる。

utf8fixパッチの更新停止

更新しようと思っていたけどすっかり忘れていた。
理由はコミット時のトランザクションファイルを作成しているところでopenを使っているから、
どうしてもMercurialにパッチを当てないと対応できない。
openerを使わずにopenを使っている理由はどうもopenerにフルパスを渡すと例外が発生するからopenを使っているみたい。

wxPython+Twistedが動かない問題が解決

twisted.internet._threadselect.ThreadedSelectReactor._doSelectInThreadでselectした時にEINTRエラーが発生してスレッドがおかしくなっていた。
_threadselect.py 288行目のreturnをcontinueに変更したら一応動くようになった。

eventletのリポジトリ

bitbucketにリポジトリが大量にあってどれを使えばいいのかわからない。
サイトからリンクされているリポジトリは古い。

全角文字を含むパスでfixutf8が動かない

日本語が含まれるパスでfixutf8が使えないの続き。
fixutf-jpだとutf-8->unicodeの変換に失敗するとmbcs->unicodeに変換するのでhg initやhg statなどは動く。
しかしcommitが動かない。openにutf-8の文字列を渡しているのが原因。__builtin__.openをフックしてパス名だけをUnicodeに変換すれば動くようにできると思うがやりかたがわからない。

7/11追記
openが動かないのはローカルの環境だった。現状はopenまで行けずos.chdirでこける。
wrapしてないのが原因。os.chdirをwrapするとopenでこける。
__builtins__.openをwrapしてもwrapした関数が呼ばれず__builtins__.openが呼ばれる。

hg-fixutf-jp-patchを更新した。
fixutf8を更新するより、Mercurial内部のファイル名の文字コードをUnicodeに変換してリポジトリのファイル名の文字コードをutf-8にした方が絶対に楽だ。
fixutf8自体ascii以外のファイル名しか想定していない。リポジトリのパスにascii以外の文字コードが入るとを動かなくなる。

utf8fixのコマンドライン関連のパッチ

fixutf8を有効にすると --repositoryが使えなくなるバグを修正したパッチをbitbucketに置いた。
tortoisehgでコミットできない原因は削除されるパラメーターが間違っていたわけではなく、
コマンドを実行していなかったのでコマンドラインが取得できなかったのが原因。

hg-fixutf-jp-patch

日本語が含まれるパスでfixutf8が使えない

コメントで指摘されてた件ですが、
fixutf8を有効にすると --repositoryが使えなくなる原因でも少し書きましたが、起動時にリポジトリのパスを設定した後、プラグインのロードを行っているため、パスをutf-8に変換できずcp932で保存するためエラーになる。

対処方法としては文字コード判定処理を入れるのが一番簡単かもしれない。
やり方としてはutf-8からUnicodeに変換しているところで今はignoreを指定して変換してるがstrictを指定して変換するように変更し例外が発生したらstrictを指定してlocale.getpreferredencoding()で取得した文字コードからUnicodeに変換しまた例外が発生したらignoreを指定してutf-8からUnicodeに変換する方法が思いついたが責任は持てない。

fixutf8を有効にすると --repositoryが使えなくなる原因

mercurialは起動時にコマンドライン引数の内--config、--cwd、--repositoryオプションの処理をしてコマンドラインから削除してからプラグインのロードを始める。
fixutf8はロードされた際にコマンドラインをUnicodeで取得してutf-8に変換している。
この時に行われるコマンドラインを削除する処理が適当で、--config、--cwd、--repositoryオプションを削除しないといけないのに、削除されたコマンドライン数分前のコマンドラインを削除している。
このためhg -R /home/witten/hg commitのコマンドラインはcommitが残るがhg commit -R /home/witten/hgのようなコマンドラインは/home/witten/hgが残ってしまいそんなコマンドはないとエラーが表示される。
tortoisehgが作成するコマンドラインはhg commit --verbose --repository /home/witten/hg -m logのためエラーが発生する。

fixutf8を有効にすると --repositoryが使えなくなる

--repositoryを指定すると hg: unknown command path名と表示される。
tortoisehgでcommit出来なくなるのもこれが原因

Mercurial 1.3 のwindows binaryでfixutf8が動かない

ctypesがない。
Mercurial本体では使ってないからね。

Mercurial 1.3で文字化け

ubuntu Mercurial 1.3でhg helpを実行すると改行しているところで文字化け。

mercurial 1.3 + tortoisehg 0.8

windowsでfixutf8を有効にするとcommitできない。(すべてアルファベットでも)
それ以外のコマンドlogとstatは一応問題なく動いている。

fixutf8でUnicodeDecodeErrorを出さないようにする

fixutf8を使ってaddremoveをするとutf-8と元々の文字コード(日本語版のWindowsならcp932)の2つが混在し必ずUnicodeDecodeErrorが発生する。

win32helper.pyの81行目u = s.decode('utf-8')のdecode関数に'ignore'か'replace'の引数を追加することで2つの文字コードが混在していてもUnicodeDecodeErrorが発生しなくなる。

fixutf8を使うために設定しないといけないこと

環境を変えたとたんに動かなくなり、いろいろ設定を変更して動くようになった。

1. HGENCODINGをutf-8にする。しなくても一応動くがascii以外のログメッセージがコミット出来なくなる。

2. エディタはutf-8でbomを付けないものを使用する。notepadはbomを付けるので別のエディタにする。

fixutf8の説明に一切書いてないので苦労した。

UbuntuでwxPython+Twistedが動かなくなった

昔(8.10)は動いていたと思うが、9.04だと動かない。
web.clientをコールしたあと結果が帰ってこない。

hgsubversionのパス指定先を変更

今までプラグインのパス指定が~/hgsubversionだったのが~/hgsubversion/hgsubversionに変わってた。
setup.pyを追加するために変更されたらしい。

Scalaでプログラム

あまりにも資料がないためにまったく進まず諦めてPythonで作り直そうかと考えている。
かなりの時間をかけてやっとTabのなかにTableを入れるところまで出来たが苦労した。
JTable自体かなり特殊なのもあると思うが、Tableのヘッダーに文字を追加するのにこんなに苦労するとは思わなかった。
GoogleCodeSearchはとても便利だと改めて感じた。

UbuntuのDropboxをバージョンアップ

Ubuntuのバージョンを9.04にアップデートしたら今まで利用していたDropboxが動かなくなっていたのでバージョンアップした。
これまでGnomeのみで自動起動していたのが他の環境でも自動起動するようになっていた。

bpythonをインストールした

最初のうちは見やすくて補完などもちゃんとできていて使いやすいと思っていたが、
日本語を使おうとするとUnicodeDecodeErrorが発生して終了する。
日本語を使うことも多いのでまったく使えない。

pyqt 4.5リリース

pyqt4.5が6/5にリリースされた。ライセンスはGPLのままらしい。
今回のバージョンアップでpython3.0に正式対応している。他のGUIライブラリに比べれば速い対応だと思う。
今wxPythonを使っているので今すぐ使うつもりはないが、使ってみたいとは思っている。

hg-fixutf8が動くようになってた

これまでまともに動作していなかったhg-fixutf8がやっと実用できるレベルになっていた。
これでwin32mbcsを使う必要がなくなった。

win32mbcs-patchを更新

7890の変更でpconvertがutil.pyからwindows.pyに移動していた。
元々pconvertでは、util.splitpathを呼んでいたが、windows.pyに移動したためutil.splitpathが呼べなくなりpath.split(os.sep)を呼ぶように変更された。
splitpathはwin32mbcsでunicodeに変換して処理をしていたためpconvertを呼ぶとファイル名に0x5cがあった場合、動かなくなっていた。

今回の修正ではutil.pconvertとwindows.pconvertをwin32mbcsでunicodeに変換して処理をするようにした。

lxml.objectifyの問題

メソッドとタグ名が同じだとタグ名でタグにアクセスできない。
他のライブラリGnosis objectifyやBeautifulSoupでも同じようにアクセスできない。
Gnosis objectifyはメソッド自体がほとんどないのでそれほど気にする必要はないと思う。
Amaraは同じ名前があると_タグ名でアクセスできる。
BeautifulSoupやlxml.objectifyを使ってアクセスする場合はメソッド名をすべて把握して重複する時は、xpathやfindなど別の方法でアクセスする必要がある。
もしかするとAmaraのような回避方法があるかもしれないが調べてない。

BeautifulSoupの最新版

BeautifulSoupの最新版がLunchpadで公開されていたが大幅に変更されていた。
(LunchpadはBazaarを入れないとソースがダウンロードできなかったはずなのであまり好きではない。
Bazaar自体もローカルでコミット出来るサーバ型なのであまり好きではない。まともに実用できるsvkみたいなイメージがある。)
これまでBeutifulSoup.pyだけだったのが複数ファイルになり、その上lxmlを利用できるようになっていた。
パース時の速度がかなり遅かったのでこの変更は期待できるかもしれないがlxmlを利用してもそこ以外が遅ければまったく意味がない。
個人的にはxpathを使うよりBeautifulSoupの方が目的の要素を探すのが楽だから期待はしている。

chameleon.genshiが速い

chameleon.genshi

Genshi template 665.46 ms
Mako Template 102.64 ms
Djange template 784.00 ms
Spitfire template 87.78 ms
Spitfire template -O1 54.63 ms
Spitfire template -O2 23.70 ms
Spitfire template -O3 23.22 ms
Spitfire template -O4 14.42 ms
StringIO 113.35 ms
cStringIO 25.57 ms
list concat 20.83 ms
ChameleonGenshi 114.44 ms
ChameleonZPT 121.35 ms

spitfireに付属していたbigtable.pyにchameleon.genshiとchameleon.zptを追加して計測。
ただしspitfireのサイトにあるベンチマークの結果に比べてchameleon.zptが遅いのが気になる。

あとgenshiとどれくらい互換性があるのかわからないが普通に使う分にはとくに問題はなかった。
ただし改行の仕方がまったく違うのでその点は注意する必要がある。

makoとほとんど速度が変わらないのでこれまでxmlベースのテンプレートは遅いという理由でgenshiを避けてた人は
chameleon.genshiを使えば速度の問題は回避できそう。

どうでもいいけどspitfireの速さは異常。いくらpsycoを使っているとはいえ、一行ごとリストを追加するより速いとは。

win32mbcs-patch更新

最新だとパッチが当てれなかったので更新

pythonの次期VCSがMercurialに決定

http://mail.python.org/pipermail/python-dev/2009-March/087931.html

>The decision is made! I've selected a DVCS to use for Python. We're
>switching to Mercurial (Hg).

bazaarはブランチを扱うのが面倒だったりするので、
GitかMercurialになればいいなあと思っていました。

正式にmercurialへの移行が決まったことは今自分が使っていることもあり、良かったと思います。

lxmlがpython3に対応してた

lxml 2.2 beta4でpython3に対応したみたい。
lxmlが使っているCythonは去年の11月にリリースされた0.10で対応してたようだ。
Python3自体インストールしていないので試してはいない。

wxPython TreeListCtrl

TreeListCtrlを使うときはFrameでイベントをbindしても受け取れずにTreeListCtrl.GetMainWindowに対してbindするとFrameでイベントを受け取れる。
Linux(Gtk+)だと上からリサイズするとヘッダーが欠ける。

他のウィジェットとはかなり使い方が違う箇所がある上、ドキュメントもサンプルもほとんどない。
そのため動作が不安定な所があるが使い方を間違えているのか、TreeListCtrlのバグか判断することができない。

Amara2

Amaraでは4Suite_XMLを使っていたが、Amara2ではライブラリに依存せずC拡張を使っている。
速度がAmaraで5秒ぐらいかかっていたものがAmara2では1秒ぐらいしかかからなくなっており高速化されており、ElementTreeとほど変わらない速度になっている。
APIが大幅に変わっており、amara.parseはdomパーサに変わっており、Amaraと同じように使うには、amara.bindery.parseを使うように変更する必要がある。
関数名と同じタグがあった場合、Amaraだと_タグ名でアクセスする必要があったがAmara2だとエラーが発生する。
html5libを使えば、amara.bindery.html.parseでhtmlを扱うことも出来る。

Mercurial Bookmarks Extension

headにローカルタグを付ける拡張。ブランチのように利用することができる。
ブランチはchangesetに保存するため作成すると削除することができないが、
bookmarksは".hg/bookmarks"に保存するため"hg bookmark -d"で削除することができる。

>hg bookmark test
>hg bookmarks
* test 0:00465edff3ff
>hg commit
>hg bookmarks
* test 1:cad989aa14e1
>hg update -r0
>hg bookmark test2
>hg bookmarks
test 1:cad989aa14e1
* test2 0:00465edff3ff
>hg commit
create new head
>hg bookmarks
test 1:cad989aa14e1
* test2 2:bd7b9b5e2796
>hg bookmark -d test
>hg bookmarks
* test2 2:bd7b9b5e2796

コミットするとブックマークがheadに移動する。

BitbucketにPatchを登録する

1. BitbucketでPatchをあてるリポジトリを表示させてpatch queueを選択してリポジトリを作成。
2. 1で作成したリポジトリをhg qcloneをする。
3. MQを使ってPatchを作成する。
4. hg qcommitをする。
5. patchフォルダ(.hg/patches)に移動してhg pushする。

Patch Queues

mercurialで'0x5c'が含まれるパスに対応させるpatch

Mercurial 1.2がリリースされていたので、'0x5c'が含まれるパスでも動くようにするpatchを作成した。
簡単な確認をして動作を確認したものをbitbacketに置いておきます。

win32mbcs-patch

Mercurialでwin32text extentionを使うときに注意すること

win32text extentionを使う場合は、すべてのリポジトリで使った方がいい。
win32text extentionを使っていない環境でCRLFを追加してwin32text extentionを使っている環境に
持ってくるとすべての行が変更されたことになる。(リポジトリの改行はCRLFでファイルは変換されてLFになるため)
こうなった場合は、CRLFのファイルだけwin32text extentionを使わないようにするか、win32text extentionを使わないようにしてrevertするしかないと思う。

ちなみにCRLFのファイルを登録しないようにするには、win32text extentionを有効にして、
設定ファイルに
[hooks]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
と書けばいい。
そうするとCRLFのファイルがあるとcommitできなくなる。

Mercurialでファイル名に0x5cがあるとコミットできない

2chで話題になっていたんで試してみたら見事にcommitできず。
環境は、mercurial 1.1.2 windows win32mbcs extention有効状態
直接ファイル名を指定するとcommitできるけど、
hg commitだと追加したファイルだと認識されない。
原因はutil.pyでファイル名とディレクトリを分ける処理でrfind(sep)としているから。
これ以外にもフォルダ名の終端が'0x5c'だとabortしたりと悲惨なことになってた。
原因はosutil.cの_listdirでファイル名の終端がセパレーターか調べているところで、最後の文字がマルチバイトか調べてないから。

win32mbcs extentionが出て来たころはここまで酷くなかったと思ってたんだが。