emacs用 weblog client

mt.el をいじって遊んだわけではありますが、
よくみるとあんまり保守されてない気もする。
2002年だし。track backとかもないし。

と言うわけで新しい MovableType clientがないかと捜したら
時代は既に
weblogger.el
のようですね。
すでに日本語での
運用実績もあるみたいだし。うーん、時間を無駄にした。

まあ、emacsの multibyte-stringとか変なところを学べたから
いいってことにしよう。うん

mt.el で editができるようになった。

前回の記事では
失敗していた既存postの editができるようになりました。
例によってgitHubから
どうぞ。

結構悩みましたが、原因は emacsにおける unibyte-string と
multibyte-stringの相互変換にありました。

mt.el が xml-rpc.el 経由で使う url.el という libraryでは、
扱うデータは unibyte-stringでなくてはいけないという policyのようです。
これはurl-http.el のソースにも書いてある。

しかし xml-rpc.el は、そこんとこあんまり真面目に考えている風がない。
そもそも文字コードなんか 8bitをまるまる渡せばいいじゃん、ぐらいの
西欧お気楽主義にしか見えない。

そこをいじるのも面倒で、自分は xml-rpc.el も unibyte-stringだけを
受け付けると見なし、xml-rpc.el に渡す前に UTF-8 で encodingするように
しました。しかるに、そこに穴があって、一部の文字列が multibyteで
残っていたのです。

xml-rpc.el で、引数をまとめて一つの XML文字列にするとき、
一つでも multibyte stringが残っていると concatするときに
'make-string-multibyte' で全部変換されちゃうらしいっす。
そして前述の url-http-create-request 関数内で 'string-as-unibyte'
で変換しなおすと余計な byteがついて UTF-8としてただしくないものに
なってしまうという落ちでした。

で、今回はかなり場当たり的に xml-rpc.el に mutlibyte-stringを
渡してるところを塞いだけど、これだとまだ穴がありそうだなあ。

本当は xml-rpc.el で multibyte-stringの扱いをどうするか policyを
ちゃんと決めなきゃいけないんだろうけど。
unibyteしか扱えないというのは制限としてきつそうな気がする。
でも XML RPC で blob的なものを使いたかったりするとそういう
APIにしとくしかしょうがないかなあ。
いや、XMLで blobってのがナンセンスか。

と言うことで煮え切りませんが、とりあえず一歩前進したということで

mt.el with 日本語

今度こそ、日本語で post できて、 category も日本語で表示されるかな。

ということで簡単なテストもめでたく終わりました。 欲しい人はGitHub あたりから取っていってください。

xml-rpc.el もいるので、持っていってください。

Carbon Emacs 22.3.1 で試しました。ちなみにここ Cocologに対して しか試してないので、ほかのところで動くかはよく分かりません。 多分動くでしょう。ためしてみてくださるとうれしいっす。

でもなぜか新規ポストは動いても、既存のポストの編集は動きませんでした。でももう酒も回ってきたので寝ます。おやすみなさい

test of mt.el

I got new Mac. In fact, I got it last summer. But I haven't had enough time to install weblog environemnt on it.

Last time, I installed mapae. But It was terrible experiense. Perl5 with CPAN is totally Greek for me. I urged for another solution.

It's natural for me to try mt.el. It looks true blog environment for emacs user

Finally, I succeeded to post to this blog. But it still fails when I used any Japanese character. This'll be my next home work. I'll publish them if I succeeded to post japanese

Plz wait for it :)

いまさらの迷路

Google codejamとかに細々と挑戦して自分の能力も落ちたなあ、とか思ってたりする昨今ですが、つい調子にのって流行の問題に挑戦してしまいました。はてぶとかではやってるらしい迷路問題です。

こうして自慢げに書いているからには、一応Lv4までいきました。90分ほどでできました。見るほどのものでもないけどソースもおいておきます。

でも、他を見てると１時間切ってるのがおおいね。やっぱり上には上がいる。いいわけさせてもらえば、C++を使うのが久しぶりだったんで iostreamの使い方忘れてたのと、xとyを間違えたりしたせいです。Cだったら 60分切ってたはず！いや、でもqueueを作るのにリストにしようかarrayにしようか迷ったりしてだめだったかな。

元記事のコメントよんだらA*ってのがいっぱいでてたけど、はっきりいってそんなの思いつきませんでした。第一、こういうのでは実効速度の速さより実装の速さが重要だからBFSで充分だし。まあ、A*なんて使い慣れてないからハマってただろうけど。

ちなみに、人がどのくらいでできてるか見たくて、ちとまとめてみました。やっぱり早いなあ。

• 40 C++
• 60 C++
• 30 Python
• 20 Java
• 95 Python
• 70 Vim
• 50 C#
• 30 C
• 85 Scala
• ?Python
• 25C++
• 60 Ruby
• 60Perl
• 50 Ruby
• 120 Ruby
• 40 C#
• 60 Python
• 240 Go
• 90 ?
• 40Python
• ?Excel?