#あとmake maintainer-cleanからやっても落ちますか?
#maintainer-cleanからやり直したらmake check通りました！お騒がせですm(__)m
#makeの依存関係がちょっとゆるくて、srcのヘッダを変更してもext以下がリビルドされないことがあるんですよね。たまにしかひっかからないのでつい放置しちゃってますが。
#マクロ展開後のコードで実行時エラーが出たとき、これまではスタックトレースにソース情報が出ず [unknown location] になってましたが、HEADではマクロ定義の該当箇所およびマクロ呼び出しの該当箇所の情報が出るようになりました
#*** ERROR: pair required, but got 1
Stack Trace:
_______________________________________
0 (car (cxr a r '(1 2 3 4)))
at "/home/shiro/src/Gauche/test/macro-source-info.scm":15
expanded from (cxr a a r '(1 2 3 4))
at "/home/shiro/src/Gauche/test/macro-source-info.scm":15
expanded from (cxr a a a r '(1 2 3 4))
at "/home/shiro/src/Gauche/test/macro-source-info.scm":15
expanded from (cxr a a a a r '(1 2 3 4))
at "(standard input)":46
1 (eval expr env)
at "/home/shiro/src/Gauche/src/../lib/gauche/interactive.scm":354##WiLiKi のトップページが書き換えられているようです。
#どうも。今度気づいたら戻しちゃってください。(history → 一つ前のバージョンをedit → commit で戻せます)
#こんにちは。JSON を扱うときに、オブジェクト型は連想リストとして読み込まれますが、これの要素にアクセスするときに assoc-ref とかじゃなくて ~ を使えるようにする方法ってないでしょうかね？
#alistか普通のlistかって区別できないんですよね。listに対する~はlist-refになっちゃう。exact integer以外が来たらassoc-refというkludgeはあるけど、たまたまキーが整数だとはまるし。
#ただjson読んだあとの扱いが面倒なのは感じてるんで、jsonpathみたいなものが欲しいなとは思ってます。
#自分のスクリプトの中でやる分には define-method しちゃってもよさそう。 (というか私はやってます……)
#JSON から変換したものだとキーは常に文字列なので、連想リスト一般を考慮せずにあくまで JSON から変換したものを扱うという前提ならそれで困りません。
#アプリケーションなら使い道を固定できるのでそれでいけますね。
#~ の JSON (から変換したリスト) アクセス用版みたいなのを適当に用意すればそれで割と足りちゃいそうな気もしますね。
#JSONの出力構造のバリエーションは決まってるからできますね。というかなんかそういうの書いたような覚えがあるぞ…
#なるほどー。確かに JSON 用の ~ は簡単に書けそうですね。
#今後数リリースで、parameterの仕様変更を予定しています。srfi-226に合わせます。変更箇所は次のとおり:
- parameterはスレッドローカルではなくなります。スレッドローカル変数にはその名もthread-localというオブジェクトが別に用意されます。
- これまでparameterizeに「parameterっぽく使える手続き」を使うことができましたが、いずれ<parameter>だけが使えるようになります。
- フック機能は削除予定
何リリースかに分けて徐々に移行する予定ですが、「変えられると今あるコードがどうしようもなく壊れて困る」という方がいたらお知らせください。対応を考えます。
#parameterがスレッドローカルでなくなるということは、current-output-portを変更すると全スレッドに影響するということですか?
#parameterizeしていれば影響はその動的スコープだけに限定されます。
#ただ、primordial threadのグローバルで変えた時にうっかり他のスレッドに影響が出るといやなので、慣用的に使われてきたいくつかのパラメータについては、スレッド作成時に暗黙にparameterizeされることにした方が良さそうですね
#なるほどわかりました。今のところ影響を受けるコードはないんですが、他にもjson-*-handlerとかスレッドセーフでなくなると、ちょっと気を遣うかなあと思いました。
#原則、parameterizeだけを使ってる限りは安全で、mutateする時は普通に変数をmutateするのと同じ危険がある (スコープの範囲に影響を与えるという意味で) と考えると良いと思います。なので新規コードについては心配してないんですが、これまでのコードの安全性を検証するのは別途補助が必要そうですね。
#mutationに関しては今でも実は正しく使うのは難しくて、例えばスレッドプールに仕事を振った時にcallerの設定がworkerに見えてるつもりが見えてなかった、なんてことも起き得るんですよね。
#call/cc使ってないのになぜか途中式から2回帰ってくるという楽しいバグの原因をつきとめた
#parameterizeの仕様変更ですが、srfi-226での議論が進んで、現在のdraftではスレッドローカルなパラメータと共有されるパラメータをパラメータごとに指定できるようになっています。
#srfi-226ではmake-parameterで作るやつは共有、make-thread-parameterで作るやつがスレッドローカル、なのでスレッドに関しては、make-parameterをmake-thread-parameterにするだけで従来と同じ振る舞いになります。
#ただ、それとは別に、srfi-226セマンティクスのparmaeterizeとdynamic-windベースのparameterizeで、限定継続を使った場合に振る舞いの違いが出てくることが発覚しました (KahuaのテストがGauche HEADでこけてるのはそのためです)。こちらの互換性を保つ方法は考え中です。
#gauche.parameterをuseした時のparameterizeは従来の動作、組み込みのparameterizeはsrfi-226の動作、というのはどうだろう。古いコードはだいたいgauche.parameterをuseしてるからそのままで変化は見えない。
#以前、限定継続まわりを調査していたときに、
guard を限定継続で実現する方法があったのですが、
他の限定継続と干渉しないように、
guard 専用の prompt tag が必要なようでした。
#しかし、prompt tag を導入すると、入れ子だけでなく
たすきがけのようなケースも出てくるし、
ややこしそうだなと思った記憶があります。
Gauche > Archives > 2023/02/06