星の贈り物

進歩と停滞と

[topic:Haskell]

同2日目。このスタイルならうーむ。もちろん、普段見てない GHC のソースを見ることは楽しいけど。帰ってから、CVS Head の方を覗いてみてタスクが１つ減ったらしいことを知る。Haskell 界の成果を手早くどんどん取り込んでいく、この貪欲さが GHC の魅力ですよね。

昨日 GHC 6.4 に対応した wxHaskell の新バージョンがようやく出てきました……とはいっても他のライブラリたちがまだなのを考えると早い方ですが。同時に wxWidgets の最新版にも対応していて、いつのまにか安定版の 2.60 がでていることを知ったり。Mac の方が最新安定板を使っていないけど、何か問題があるんでしょうか？ 2.5.5 で wxHaskell に必要なオプションを全部つけて wxWidgets をビルドしていたら、最後に ODBC のリンクに失敗してましたし。Windows の方は前々からバージョン上がらないので明らかに問題があるんでしょうけど。このことと久しぶりに Mailing-list に復帰してきた作者がこの 2 週間で SOEgraphics (現在 HGL パッケージに含まれる Graphics.SOE) の wxHaskell 移植版のサポートを取り込む予定だというのは嬉しいニュースなんですが、彼もやはり Microsoft で 2,3 ヵ月働くことになったようでその後 9 月くらいまで開発を離れるとか。HSQL の人も開発が中断しているのも 6 月ぐらいまで別のプロジェクトに参加していて手が出せないためだし、ちょっときついかも。

色々と試して見ました

[topic:Haskell]

先日言った HSQL の SQLite3 対応パッチはログを最後まできちんと読めば手に入ったようです。ああ見落としが……がくっ。ただしこちらの目的である HaskellDB と組み合わせて使うには SQLite 用の関数から obsolete になったファイルの書き込みに関するモードの設定の部分を取り除いてやる必要がありますが。外に見せる簡易インターフェースの法は書き換えなくていいかな？　backward compatibility というか操作用の関数を書き換える手間が惜しいということで。

今日 darcs を初めて使ってみました。……いや、get はしょっちゅうしていますがそれは CVS の co と同じで使っているとは言いませんし。send に委譲されたメーラーによる送信がうまくいかないので、( darcs record によって生成された)レコードにある patch から darcs send -o /tmp/f で送信用の patch に変換してメールに添付するという形になりましたが。まあそれでもサーバーにアクセスする権限なしで手元にあるファイルへの変更をそのまま送れるのが嬉しい。darcs といえば最近、Haskell XML Toolkit が分離して依存するようにした HTTP Module が同じく分離させて依存するようになった Cryptographic Library が (Windows の?) GHCi 上で実行しようとするとこけるようなので darcs get --to-match "hash 20050413104916-6cdb2-73a45f9330b85b629c3e4a1ad2a5e8b26429b7bd.gz" http://cvs.haskell.org/darcs/http/ と指定してとってくるところで hash がいると思わなくてはまりました。まあ、どっちみち普通に Haskell XML Toolkit をロードした状態で GHCi を実行しようとすると確保したメモリから溢れちゃって変更後リロードしたときに落ちるのですが。Cabal の登場によっとライブラリの分割がうまく進むようになったのはいいけど、こうなると依存したモジュールを一括で更新できる仕組みがそろそろ欲しくなってきます。まあ現に HackageDB とか cabal-get とかが出てきてはいるようですが。

で今日 darcs を触ったのは hs-plugins 用のパッチを送るためだったのですが、Cygwin がダメだったからって MSYS にしてみたり色々と弄ってみても HSbase_cbits.o　での __errno の参照エラーや一部でプログラムが止まるのが直らないということで大弱り。wxHaskell をインストールしていると lang パッケージ内のモジュールと同名のモジュールを作ったときにインポートされているモジュールと同名のモジュールがあると言う問題がでるという悪さをするので、同じような問題かなと思ってアンインストールして作業しているのですがやはりうまくいかない。SOEGraphics との兼ね合いで PanTheon や Fran の移植ともくっつけてやればかなり良い線にいくのじゃないかと思って hs-plugin に対して作業をやっているのですが。GHC 自体をインストールしなおしたり他のバージョンを使えばどうにかなるかなと思いつつ見ていたら home ディレクトリ以外では make check がやすやす動いてくれるような感じ。……が、表示が変だなと思ってわざと失敗するテストを入れたりしてみたところ、これはただ make check がきちんと働かないだけだった模様。Mac OS X Tiger でもこの表示なのでやはり……。

遷移図記述言語

[topic:C++]

C++ Template Metaprogramming (Amazon) ようやく読了。(C++ Template Metaprogramming サポートサイト) やっぱり出かけるのが少なくなるとなかなか読めない……。まあ、洋書読むの自体そんなに早くないっていうのもあるけど。

というわけで、この本を先に読むのがいいかそれとも Modern C++ Design を読んだほうがいいかという話ですが、Template を使ったテクニックを学ぶということや Boost 使い養成講座といった意味的的にはこちらを読んだ方が良いと思いますが、policy による設計やデザインパターンを自動生成するという思想的な部分で Modern C++ Design も読んでおいてもらいたいと思います。少なくとも下手に class による設計とかデザインパターンを学ぶより前に。で、設計やデザインパターンよりも前に学んでおいて欲しいところは C++ Template Metaprogramming の中にもやはりあって最後の DSEL (DSL) に関する2章だったりするのですが……。やっぱり、理想的には2冊とも早めに読んでもらうことかな？

Modern C++ Design 同様、後半の DSEL に関する記述はこれまでそうした世界は知らなかった人にとっては感激しっぱなしだと思います。最後にこれの作り方を解説していますし。

// concrete FSM implementation 
class player : public state_machine<player>
{
 private:
    // the list of FSM states
    enum states {
        Empty, Open, Stopped, Playing, Paused
      , initial_state = Empty
    };

    
    #ifdef __MWERKS__
     public: // Codewarrior bug workaround.  Tested at 0x3202
    #endif
    
    void start_playback(play const&);
    void open_drawer(open_close const&);
    void close_drawer(open_close const&);
    void store_cd_info(cd_detected const&);
    void stop_playback(stop const&);
    void pause_playback(pause const&);
    void resume_playback(play const&);
    void stop_and_open(open_close const&);

    
    #ifdef __MWERKS__
       private:
    #endif 
          friend class state_machine<player>;
    typedef player p; // makes transition table cleaner

    // transition table
    struct transition_table : mpl::vector11<

    //    Start     Event         Next      Action
    //  +---------+-------------+---------+---------------------+
    row < Stopped , play        , Playing , &p::start_playback  >,
    row < Stopped , open_close  , Open    , &p::open_drawer     >,
    //  +---------+-------------+---------+---------------------+
    row < Open    , open_close  , Empty   , &p::close_drawer    >,
    //  +---------+-------------+---------+---------------------+
    row < Empty   , open_close  , Open    , &p::open_drawer     >,
    row < Empty   , cd_detected , Stopped , &p::store_cd_info   >,
    //  +---------+-------------+---------+---------------------+
    row < Playing , stop        , Stopped , &p::stop_playback   >,
    row < Playing , pause       , Paused  , &p::pause_playback  >,
    row < Playing , open_close  , Open    , &p::stop_and_open   >,
    //  +---------+-------------+---------+---------------------+
    row < Paused  , play        , Playing , &p::resume_playback >,
    row < Paused  , stop        , Stopped , &p::stop_playback   >,
    row < Paused  , open_close  , Open    , &p::stop_and_open   >
    //  +---------+-------------+---------+---------------------+

    > {};
typedef
 
event_dispatcher<
    row<Stopped, play, Playing, &player::start_playback>
  , event_dispatcher<
        row<Paused, play, Playing, &player::resume_playback>
      , default_event_dispatcher
    >
>
 dummy;
};


int main()
{
    player p;                      // An instance of the FSM

    p.process_event(open_close()); // user opens CD player
    p.process_event(open_close()); // inserts CD and closes
    p.process_event(               // CD is detected
        cd_detected(
             "louie, louie"
           , std::vector<std::clock_t>( /* track lengths */ )
        )
    );
    p.process_event(play());       // etc.
    p.process_event(pause());
    p.process_event(play());
    p.process_event(stop());
    return 0;
}

これを見てしまうと、開発中の boost::statechart (旧称 boost::fsm) (現在リンク先の boost.org ではなく http://boost-sandbox.sourceforge.net/ に置いてあります)がこういう風に書けないのが惜しく感じられてしまいますね。UML をソースコード上で表現したいっていうように、そちらは focus している部分が違うからですが……うーん、あまりいい策だとは思わないなぁ。こういうのはここぞというところに適用することで宣言的に書けるのに価値があると思いますし。もちろん、そういう要求 (Executable UML) があるのは分かりますが。

陰陽大戦記 第34話 龍虎、再び

[topic:アニメ、感想]

もう一人の主人公ユーマが出てくると、やっぱり燃え展開になりますね。最近は話の意図は理解できるしところどころで萌えとかギャグとかのの狙い通りにはできているんだろうけど、いまいち感情移入しにくい回が続いてましたが三クール目後半の盛り上がりに向けてきちっとやってくれました。……まあ、ギャグとシリアス両方で出てくる、株で儲けたただの先物取引で立身出世だの企業の収益だのサービス残業だの妙に大人向けなネタは媚びてない分これまでもうまく回っていましたが。

ユーマの成長物語は良いんだけど、リクが成長から遠ざかっているだけにこれをどう回帰させて再びリクという主人公に感情移入させることができるようにするのか……リクがあんな主人公なだけに楽しみ半分うまくいかない怖さ半分。

視聴者にうすうすそうだろうなと思わせていた地流宗家がユーマであることを明らかにしたり、散々ほのめかしていたタイザンが地流内の神流であることを正式に明かしてくれたり、そして彼らにとって天流・地流ともに宗家というものが(封印を解くなどの)重要な存在であるというこれまでの伏線の続きを見せてくれたり、陰陽大戦記の手堅い作りが戻ってきてとても嬉しい。さーて地流側のミカヅチも神流の意図を知ってかうまく罠を避けている強かな男としても描かれているし、ただの悪役の親玉ではないという面が描かれ始めているのでこれをどう料理するのかがとても楽しみです。今回は完全に悪役だったけど前回裏で暗躍するだけの人物ではないという一端が明らかになった 雅臣 ( まさおみ、がしん ) のことも同じく楽しみ。