#open-output-string で開いたポートを wrap-with-output-conversion に通して http-get の :sink に与えるとエラーになるみたいです。
#↓こんなの
*** ERROR: output string port required, but got #<oport [conv(euc-jp->utf-8) to "(output string port)"] 01e9d310>
#:flusherを与えていないからだったりしませんか? 現在ドキュメントされている仕様では、flusherのデフォルトは (lambda (sink headers) (get-output-string sink)) なので sinkにstring port以外を与えるとそのエラーになると思います。
#(^ _ #f) にしたんですが…
#wrap-with-output-conversion を通すと get-output-string できないんですね。
#おやん。じゃあどこがget-output-string呼んでるんだろう。
#念のため自分が書いたものを見直してみます。
#手元では :flusher を与えたらエラーにはならなかったです。
#と、思ったけど諦めてポートを通さない形に書き換えてた…。
#一応記憶を頼りにもう一度書いてみよう。
#sinkにはwrapしたものを渡し、flusherの方でwrapしない元のポートに対してget-output-stringを呼べば良いと思います。
#うわぁぁぁ。 :flusher のつもりが :flush と typo してたみたい。 λ...
#http-get はキーワード引数とリクエストヘッダを混在する記法なのでこういうとき捕捉されないんですね。
#確かに、捕捉されないのは問題をややこしくするかも。リクエストヘッダとして解釈できるキーワード引数に文字列以外のものが渡って来たらエラーにする、とかで改善できるかな?
#ところで話は変わりますが、 output string port に蓄積したものを今度は input string port として読み出したいってケースは珍しくないと思うんですが、 get-output-string で取り出して open-input-string するしか無いですか？ なんとなく非効率な気がするんですが、内部的には共有されてたりするのかな。
#ああ、get-output-stringはコピーが発生しちゃいますね。output string portは最終的な長さがわからないのでチャンクのリストの形でデータを保持してるので。今のところその蓄積されたデータを得る方法はget-output-stringだけです。
#procedural buffered portを使ったらパイプのような対のポートを作れるんじゃないかな。
#<buffered-output-port> を使えば案外簡単に出来そうな予感。
Gauche > Archives > 2011/02/10