週刊nmosh - build-idの提供 - .mjtの日記復帰計画

そろそろリリースしないとヤバいという気持ちは有るけど。。

BSDの64bitビルドをFIX

__WORDSIZEがdefineされていないと、SIZEOF_INTPTR_Tが4になって悲しい気持ちになるのを修正。
少なくともFreeBSDの場合はLONG_BITが定義されているのでこれを利用できる。
...MacOS Xの64bitビルドはどうなってたんだろう。。
RELNOTEに書き忘れているのに今気付いた。

build-idの提供

nmoshは、全てのexpandしたライブラリにbuild-idを振っている。これにより、expandキャッシュのstaleなどを管理している。で、このbuild-idは(rnrs)のようなnmoshバイナリに内蔵されているライブラリにも振られているので、これを取得するインターフェースを準備した。
これはライブラリのpreキャッシュ( http://d.hatena.ne.jp/mjt/20120617/p1 )のファイル名の一部として使う。Windowsバイナリは今後preキャッシュがある場合は自動的に読みこむようにしようと思っているので、build-idをつかってキャッシュを読み込んでも安全かどうかを判断したい。
build-idはexpand中にexpanderの手続きを呼ぶことで取得出来るようにしている。R6RS schemeでは、低レベルマクロを使って次のように書ける:

(define-syntax define-build-id
  (lambda (stx)
    (syntax-case stx ()
      ((_ name)
       (with-syntax ((id (datum->syntax #'stx (ex:unique-token))))
         #'(define name id))))))

(define-build-id build-id)

ここで、ex:unique-tokenがexpand中のbuild-idを取得する手続きで、一度これを含んだライブラリをキャッシュすると、define-build-idによって定義された値build-idは何度ライブラリをimportしても不変となる。
逆に言えば、この手の低レベルマクロは本質的にキャッシュ安全でないし、nmoshはそれを検出する上手い手法を用意していない。
例えば、ex:unique-tokenの代わりに現在時刻を返すような手続きを使えば、ライブラリがいつキャッシュされたかを記録することができる。これが出来るということは、キャッシュの副作用が観測できるということも意味する。
nmoshは--disable-accオプションをつけるとキャッシュを無効にするが、(rnrs)や今回build-idを追加した(nmosh startup)のようなライブラリは常に(nmoshバイナリに内蔵された)キャッシュから読み込まれる。