2008年4月アーカイブ

SubversionからMercurialへ。

| トラックバック(0)

 時間がかかりましたorz
何やってたかというと titleどおりなんですが、rubyの repositoryをまるっと mercurial用に変換してみたのでした。

 先日、ircで rubyの repositoryを hg convertするとうまくいかないという話を聞き(というか読み)、じゃあ最近 hgつかってるから debugにいいかな〜と思ってチャレンジしてみたわけです。
 最初、hg convert http://svn.ruby-lang.org/repos/ruby/trunk ruby だけしてみた時はすんなり動いたので報告してみると「trunkだけでは足りない」って御言葉が。というわけでじゃあ単純にでかくなるだけだろーと思って始めてみたわけですが。

 時間がかかるので放置していたら、

hgext/convert/subversion.py: libsvn._core.SubversionException: ('child raised exception', 175002)
とかなんかで .pyが例外で落ちてるわけです。しかも普通に cPickle.load(stdout)してるだけなんですな。こりゃ実は何か隱れた bugか?と喜んで(喜ぶなよ)今度は(片手でFFXIやりながら)画面をみていると、swapがごりごりいってるわけです。で、はたと。cPickleさんがコケるのはもしやして memoryまわりか?と。
 そんでまぁ適当に使わない applicationおとして試してみてもまだmemory fullになる。こりゃ実は memory eatで暴走か?とかおもって出来る限り memoryをあけて(OSXで1.7GBあけてみた) try. すると最大1.6GBちょい(本当にギリギリ)を時々消費してるんですな。なにか sortか searchかしてるんでしょう。ぐわっと heapとって見てはまた数十MBにもどり、また1GB over食っては戻り、を繰り返して今度はなんとか passしそうな感じに。

 で。それを一晩放置して朝おきて。まだおわってないので放置して晩になり。とだいたい丸1日消費して、hg convertは無事おわったのでした。 hg logも hg clone --revも動いたので、まぁひっぱるのはokかな?
 そんな感じで、Subversionから Mercurialへ hg convertをする場合、空きメモリには要注意してくださいという話でした。Python+swigでメモリ不足なことって初体験だったわけですが、良い回避or検出方法ってないものですかね。

Stackless Pythonって。

| トラックバック(0)
 先日かってきた SoftwareDesign 2008/05。その Python conference 2008の記事をみていて面白そうなものを発見。
 それが Stackless Python。まぁ簡単に言えば Erlangくさい another Python(笑)

 とりあえず、download and installはして sample動かしたり過去のブツを動かしたりで互換性とかは問題なさそーだなーという感じ。wxPythonとかも普通に動くので安心。
まぁ、単純に stack overflowを防ぐだけなら CPythonのままでも 'from itertools import ifilter' とか使えば解決するんだけど、細かいものをウジャウジャ動かすのが楽というのもまた良い。というか、networkで複数 connectionで処理かましながら、同時に GUIや local storageをつついたり、とかを書こうとすると多少なりとも面倒だったりするわけで、それを楽にできるのならいいなぁと。
 まぁ HiPE@erlangが OSXでも普通に動いたりすると幸せなんだけど、どうも面倒そうなので Stackless Pythonは悪くなさそーだなーと。あまり環境依存してなさそーだし。

 ところで資料みてたりすると、ネトゲである所の EVE Onlineが Stackless Python使ってるそうなんですな。面白い。そういうところで開発コストと信頼性を確保してるんだな〜と納得。
 まだ入れていじりだした所なので、何がどうとかいうわけでもないけど、cometdとかの真似やらせると得意そうだし、ちょいと興味が。まぁ fiber実装の良い使い道の1つとして勉強もしたいですしね。

??さて、今自宅では NAS箱数台で RAID5+1環境とかでファイル保存してるんですが、


  1. そろそろ3TBぐらいでは足りない
  2. 複数OSでアクセスするのが面倒な場合がある
  3. 新しい filesystemとかで遊ぶ容量がない
  4. 最近、TimeMachineなどのリアルタイムバックアップを常用する
とかの理由で、PCベースのファイルサーバーが欲しくなったり。
ただここで問題が。単純に network cardと HDDをつなぐだけのような(よくある)NAS箱を作るのならこの 1箱750GBで1万ちょいとかいう時代ならすぐなんですが、

  1. 暗号化やメタファイルシステムなど考えるとCPU性能が欲しい
  2. ランダムアクセスや小さいファイルアクセスが増えた
  3. クライアントに送る前に pre-processしたいファイルが結構ある
ってことで、RAMと(それなりの)processor speedが欲しいわけですね。
ところがぎっちょん(古い)、今は 8GB以上の物理RAM搭載が結構高くつく。DIMMも2GBより上だと容量単価が数倍にハネ上がり、swap/cacheに SSDを使おうにもやはりお値段が...
 というわけで、いろいろと悩み中。金があれば全部解決するんだろうけどさ!

 今考えているうちの最有力は「安マザーに安CPUと8GB RAMだけつっこんだ板を数枚LANで繋いで論理RAM容量を増やす」というマヌケっぽいアイデア...安いんだけどね。8GBふやすのに3万円ぐらいだから(笑)
 もうちっと、何かエレガントな技はないかなぁ。

思考実験を現実実験に。

| トラックバック(0)

 「漫画トレースもお互い様だが......」 竹熊健太郎氏が語る、現場と著作権法のズレ という記事をみた。本文自体は最近よくみる white-gray-blackの立ち位置話とかなんだけど、そこに個人的に興味深い話が。

 評論家の山形浩生氏曰く

「PC上で人格が作れるようになった場合、どうなるだろうか。例えば、僕のような文章を自動生成するジェネレータで作った文章を、僕の声をサンプリングしてリアルに発生できる音声合成で読み上げた場合、その文章の著作権はどうなるのだろうか」という思考実験を披露。

 これって、そう無理な話でもないと思うわけです。文章として完璧である必要もないわけですから。で、より一層すすめてサンプリングソースが集合や、GPL documentであった場合。どうなるんでしょうね。
しかも、これを動作させるのが cloud computing spaceだった場合には...
 実装を考えてみると、多少面白いように感じます。
そもそも著作とは何か、守るべきは何か。そういうものを考える具体例として実装してみたいと思いますね。

P2P platformで分散コンピューティングとかあると、こういう時よさそうなんですが、稼働中のものとかないですかねー?

 面白い記事発見。言語バリア撤廃へ向けて、最終報告書Common Web Language 要するに自然言語だけでもなく、modeling languageだけでもなく、両方において表現をサポートする記述言語の話。サンプルが w3c.orgのサイトにあるけど面白い。

? 例えば、`Long ago, in the city of Babylon, people begun to build a huge tower, which seemed about to reach the heavens.'という例文を CWL的な表現にすると
begin.entry.past-- tim->long ago
    --plc->city.def
    --agt->people.def
    --obj->build.past--obj-> tower<- aoj--huge<- seem.past
                     --obj->reach.bigin.soon--obj->tower
                     --gol->heaven.def.pl
となるようだ。構文ツリー解析ともまた違う表現で、たしかにこれが存在すれば読みこんで意味パーサを動かすのもできれば元文章とコレとで自然言語翻訳もまた丁寧に行なえるだろうなと思う。
? 当然、自然言語から一発でこの構造に変換できる技術なんてまだ完成してないわけだけど、各地で行われているそういう研究の共通叩き台として採用されるには良いかなと思う。  また、新規で何かコンテンツを作る場合には最初からこのへんを意図しておけばかなり楽になるはず。面白いよね。 ある意味、宣言型言語の書き方に近いような感じにもなるのだろうけど、blogとか雑談とは違い、何かを正しく伝達しようとするものの場合結構楽につかえて面白いかなと思う。

? なにも、文章<->computerだけではなく、文字文章から音声やモーションといった人間的な別表現方向への変換にも使えそうだしね。 いい意味で「人にも機械にも依らない表記」って方向は気にいった。ちょいとこれから追いかけてみたい技術ですねぃ。

このアーカイブについて

このページには、2008年4月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年3月です。

次のアーカイブは2008年5月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。