#count(=上限)がないという意味と捉えて#fをあたえるとか?
#実際、clampでは下限上限無しの場合に#fを当てていますね。ちょっといまいちな感じではあるんだけど、Schemeでは「無し」を表すユニバーサルな値はないからなあ。(CLなら迷わずnilなんだけど)
#そういえば型に厳密な言語で、こういうふうに「普通は実数や整数だけど理屈の上では上限/下限無しもありえる」っていうケースはどう表現するんだろう。いちいちMaybe型みたいなのでラップするのは面倒そうだけど、やっぱりそうせざるを得ないかな。
#超限順序数ωがあれば正確な無限大(のようなもの,より正確にはあらゆる正確数より大きい正確数?)が表現できるということですね.giotaでやるならそれが一番気持ちいいですね.(正確な無限大というのもあり得るのかな…)
#HaskellだとenumFromとenumFromToは別の関数になってますね.
#ωはあらゆる「有限正確数」より大きな正確数のうちで一番小さいもの、ということになりますか。ω+1とか2ωとかω^ωとかあり得るので、数の体系を全部拡張しないとならないでしょうけど。
#なるほど.大事になってしまいますね.
#そういうのが扱えたらそれはそれで面白そうではありますが、ωって具体的な値を計算するのに使うものでもないので、あって嬉しいかどうかというと微妙かなあ。
#・ω・
#http-getの:receiver APIがドキュメントにないのは何か事情があってのことでしょうか?
#まだオフィシャルじゃないのです。persistent connectionがある場合とか、ちょっと特殊な使い方をしたい場合とかにも対応できるAPIかどうか、もう少しこっそり使ってみて実績を積まないと確信が持てないので。でも興味があれば使ってみて (ソースのコメントには使い方が書いてあります)、「こういう使いかたをしたいけど困った」というケースをあげてもらえればありがたいです。
#parser.pegの$countと$repeatってダブってません?
#ダブってるね。どっちを残すべきか意見募集。
#私的には$repeatの方が直感的です.でもParsecはcountみたいですね.
#他のPEGライブラリはどうだろうか。特に強い理由がなければメジャーな方に合わせるかなあ。
#かなり初期の段階から両方あったようだなあ。私の感覚的にも$repeatの方が覚えやすい感じはする。
#http-getで読み込んだデータをだらだらと表示するだけのコードを書いてみたのですが、読み込むサイトによってエラーがでるのです。https://gist.github.com/3153651 #$ gosh t
#?="./t.scm":17:(http-get "www.google.com" "/" :receiver (dump-receiver))
#?=code
#?- "302"
#?=hdrs
#?- (("location" "http://www.google.co.jp/") ("cache-control" "pr ...
#?=port
#?- #<iport (socket input #<socket (connect "173.194.38.113:80")> ...
#?=size
#?- 221
#?="./t.scm":14:(read-block size port)
#?- #*"<HTML><HEAD><meta http-equiv=\"content-type\" content=\"te ...
#?=port
#?- #<iport (socket input #<socket (connect "173.194.38.113:80")> ...
#?=size
#?- 0
#?=code
#?- "200"
#?=hdrs
#?- (("date" "Fri, 20 Jul 2012 22:17:11 GMT") ("expires" "-1") (" ...
#?=port
#?- #<iport (socket input #<socket (connect "173.194.72.94:80")>) ...
#?=size
#?- 4096
#?="./t.scm":14:(read-block size port)
#?- #*"<!doctype html><html itemscope=\"itemscope\" itemtype=\"ht ...
*** HTTP-ERROR: bad line in chunked data: "ml:function(){},kHL:\"ja\",time:function(){return(new Date).getTime()},log:function(a,b,c,e){var d=new Image,h=google,i=h.lc,f=h.li,j=\"\";d.onerror=(d.onload=(d.onabort=function(){delete i[f]}));i[f]=d;if(!c&&b.search(\"&ei=\")==-1)j=\"&ei=\"+google.getEI(e);var g=c||\"/gen_204?atyp=i&ct=\"+a+\"&cad=\"+b+j+\"&zx=\"+google.time();"
Stack Trace:
_______________________________________
0 (receive-body in code rep-headers receiver)
At line 643 of "/usr/local/share/gauche-0.9/0.9.3.3/lib/rfc/http.scm"
1 (with-error-handler (lambda (e) (let ((e e)) (%guard-rec e e (else ...
[unknown location]
2 (request-response method conn host request-uri sender receiver `(: ...
At line 245 of "/usr/local/share/gauche-0.9/0.9.3.3/lib/rfc/http.scm"
3 (loop (cons uri history) (ref (redirect conn proto new-server) 'se ...
At line 261 of "/usr/local/share/gauche-0.9/0.9.3.3/lib/rfc/http.scm"
4 (http-get "www.google.com" "/" :receiver (dump-receiver))
At line 17 of "./t.scm"
#http-string-receiverを書き換えただけのつもりなのですが、read-blockの使い方はこれではまずいのでしょうか?
#read-blockが全部読み取ってませんね (read-blockはiportのバッファリングモードによっては、指定size読まずにreturnすることがあります)。ただ、なぜそうなるのか(なぜretrの返すポートがそういうバッファリングモードになってるのか)についてはrfc.http側の問題である可能性があるのでちょいと調べます。とりあえず、retrieverの中では確実にsizeバイト読むようにしてください。
#ソケット入出力はデフォルトではフルバッファリングになってない、っていうだけのことかな。read-blockやread-block!は低レベル手続きで、readシステムコールを使うのと同じ感覚のAPIです。つまりちゃんと全部読んだかどうかは呼び出し側がチェックすることを想定しています。
#仮想ポートを作って、copy-portするとうまくいったようです。https://gist.github.com/3153651 #(define dump-port (make <virtual-output-port> :puts (^x (debug-print x)) ) )
#ありがとうございます。
#あ、でもこれだとsinkを使ったほうがいいということに(汗
#(define (main args)
(debug-print (http-get "www.google.com" "/"
:sink dump-port ) ) )
##?="./t.scm":20:(http-get "www.google.com" "/" :sink dump-port)
#?=x
#?- "<HTML><HEAD><meta http-equiv=\"content-type\" content=\"text ...
*** ERROR: output string port required, but got #<virtual-output-port #f 0x8fabee0>
Stack Trace:
#仮想ポートへsinkできないのでしょうか?
#(define (main args)
(debug-print (http-get "www.google.com" "/"
:receiver (http-oport-receiver dump-port (^ arg #t) )
) ) )
#これならうまくいきました。
#:sinkを使うときは:flusherも合わせて指定しないとだめです。