gniibe

• 2007-07-19
  • Debian の gauche のUploaderのひとりとなった。gauche-gtk, gauche-glと一緒に保守できる。
  • GTK+ 2.10以降で、GtkWidgetの形が微妙に変わってgauche-gtk (0.4.1)がコンパイルできん。ガーン。
• 2004-03-07
  • #236420, 速攻で直った模様。
  • 下記が慣習(Best practice)のようである。
    • Interpreter が読み込む shared object (.so)は、/usr/lib/The-Interpreter/$VERSION/$ARCH/に置く。versionは付けないで、SOME-MODULE.so。
    • 他のアプリケーションからリンク、あるいはshared objectとリンクされるものは、/usr/lib/libSOME-MODULE.so.MAJOR.MINOR を実装、libSOME-MODULE.so.MAJORをインタフェースとして置き、libSOME-MODULE.so をリンク(開発時)の対象とする。
    • 実体 libSOME-MODULE.so.MAJOR.MINOR <-- 実行時インタフェースlibSOME-MODULE.so.MAJOR <-- 開発時インタフェースlibSOME-MODULE.so
    • Interpreter 以外から参照されるかどうかが別れ道か。
• 2004-03-06
  • gauche-gtk を Debian package にしていて気付いた 問題。BTS に報告。
  • libgauche.so の扱い。
    • これは他の extention が refer するのだから、libgauche.so.MAJOR をインタフェース、libgauche.so.MAJOR.MINOR を実装とするべきでは?
    • 帰って来たら報告書こう。

• 2004-03-04
  • Towers of Hanoi をGauche でいろいろ遊んでいます。

Gauche:Debian というページにすべきか？

• gauche 八田さんがメンテナー
• yaegashi さんが Build の問題を報告→解決 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173786
• 二つのパッケージに分けた方が良いのではと提案http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174314
• gauche-gtk も欲しい。
  • yokota さんにつくってもらった。ここ <-- なくなっちゃった(サーバ管理している僕のせいです)。BTS にRFPを出しました。

ここから下は、2002に書いたこと。

Gauche を Dreamcast, Zaurus で使うところ。 DirectFB + GTK+FB + Gauche-GTK + Gauche という構成。

UTF-2000 も。

Anthy の言語として Gauche 使えないかなぁ。

• Shiro (2002/11/27 17:16:32 PST): Boehm GCは動きますか? ＞Dreamcast, Zaurus。 あと、以前PlayStation2にSTkを移植した時に、 PS2では sizeof(long) ＞ sizeof(void*) ＝ sizeof(int) であるためにはまったのですが、Gaucheでもsizeof(long) == sizeof(void*) であると仮定してしまっている箇所がまだあると思います。 そのへんが引っかからなければ良いんですが。

• Boehm GC 動きます。GCC 3 のJava runtime にはいったので、 動かそうとみなやるようです。SuperH, ARM.

だんだん思い出してきたシグナルの話（つづく。。。）

SCM では、拡張の C のコードを書くのが大変だぁ、と思った。

• SCM では、シグナルハンドラとして、任意のコードを走らせることができる。
• SCM では、C level で任意の場所で割り込まれる可能性があり、 割り込みに対して 問題ないコードとするには、DEFER_INTS, ALLOW_INTS で割り込み禁止領域を 囲む必要がある。
  • kernel プログラミングみたいなもの。

Guile では

1998 年ころ SCM のセマンティックスは、あんまりだろうと いうことで、Threads Support の提案の際に変えることとなった。 Guile 1.4 以降は、Guile のシグナルは、C のコードの任意の間で呼ばれることは、 なくなった。

一般の UNIX プログラミングにおけるシグナルの利用

• あんまり使えない(Useful でない)。
• 以下の3種類ある。
  • 例外(NULL dereference など)をキャッチする。
  • (Ctrl-C で)処理を中断する。
  • プロセス間の通信として使う。
• もう一つタイムアウトに使うことがある。
• シグナルハンドラで任意のことができるわけではない。
  • Asynchronous Safety, Signal Safety と言われる。
  • 例: printf ダメ
    • printf の処理中にシグナルハンドラが呼ばれているかも知れないから。 シグナルハンドラが reentrant でないコードを呼ぶと内部データが壊れちゃう可能性 がある。
• プログラミングの規律として、2つ
  • 任意の場所での(割り込まれて)非同期実行を仮定する
    • 割り込まれたら困るところを囲んで守る。
    • シグナルのマスク／アンマスク（システムコールなので重い）
    • 印をつけて、非同期実行を遅延
  • ある特定の場所での割り込みの処理を仮定する
    • 例：eval のところ

マルチスレッドアプリケーションに使われるライブラリの性質

• Solaris のマニュアルでは、マルチスレッドに関して、記述される。
  • attributes(5): MT-Level
    • Safe
    • Unsafe
    • MT-Safe
    • Async-Signal-Safe
    • MT-Safe with Exceptions
    • Safe with Exceptions
    • Fork1-Safe
    • Cancel-Safety

ついでに思い出した SCM/Guile の話

• call/cc のサポートは言語として、どんなものかなぁと考えた。
  • 言語を設計する側とするとカッコいいかも知れない。 竹村健一先生のこれだけ！手帳宜しく、この基本要素でできるのだと。
  • でも、拡張言語として考えるといかがなものか。
  • 拡張する部分を書くのが大変。
    • eval をする場合、call/cc が起こるかも知れないので、
    • そこからのコードは N 回(N>=0)呼ばれる可能性がある。
  • N=0 の場合は、書くことも要求できるだろう。(unwind-protect しなさいと)
  • N>1 の場合どんなもんでしょうか。

Shiro (2002/12/01 23:33:13 PST): full continuationはCの実行モデルとの相性が最悪なので、 Cから手軽に呼べる拡張言語と位置付けるなら無理にサポートする必要は ないと思います。SCMの方法 (Cスタックまるごとコピー、リカバー)は確かに 目から鱗でしたが、いかなる場合でも複数回returnがあることを考えて Cコードを書くのはきつすぎます。 そもそもエラーハンドラをSchemeで書くことを許した途端、 基本関数でさえCから安全に呼べなくなってしまいます。

また、SCMの方法はcontinuationの作成も呼び出しも高価であり、 他で書かれたfull continuationを使ったコードを動かしてみることが出来る、 以上のメリットは無いと思います。 あれだけ重いと自分で書く時に積極的に使う気にはなれません。

さらに、既存の外部ライブラリへのbindingを書いて、 外部ライブラリからSchemeへのコールバックを許す場合、 その外部ライブラリが複数回のreturnを考慮されて書かれている 可能性はほぼ皆無でしょうから、実用上、コールバック内で作られた continuationはコールバックから戻った後では安全に呼ぶことは 出来ないでしょう。

拡張言語として使う場合、SchemeフレームからCフレームへのreturnは たかだか一回に制限する、ということで妥協するしかないと思います。 continuationのエクステントを制限したくない場合は、 C側で意識してトランポリンを書いてやれば良いわけで。

2002/12/02 16:33:30 PST Hagedou. Completely agreed.