#kahuaのstableブランチを久々にsvn syncして気づいたんだけど、この変更ってどこにも入ってないよね?
#--- src/kahua/protocol/http.scm (revision 3562)
+++ src/kahua/protocol/http.scm (working copy)
@@ -9,6 +9,7 @@
;; $Id: http.scm,v 1.4 2006/10/08 01:36:20 bizenn Exp $
(define-module kahua.protocol.http
(use srfi-1)
+ (use srfi-13)
(use rfc.cookie)
(use rfc.uri)
(use util.list)
@@ -128,14 +129,16 @@
(define (make-cookie e)
(define (make-karg k v)
(if v (list k (x->string v)) '()))
+ (define (nonlocal-domain h)
+ (and h (string-index h #\.) h))
(cons "set-cookie"
(construct-cookie-string
(or (and-let* ((domain (assoc-ref kheader "x-kahua-session-domain")))
(receive (scheme host port path) (apply values domain)
`(("x-kahua-sgsid" ,(cadr e)
- ,@(make-karg :domain host)
- ,@(make-karg :path path)
- ,@(make-karg :port port)
+ ,@(make-karg :domain (nonlocal-domain host))
+ ,@(make-karg :path path)
+ ,@(make-karg :port (or port 80))
,@(make-karg :secure (equal? "https" scheme))
:discard #t))))
`(("x-kahua-sgsid" ,(cadr e) :discard #t))))))#ChangeLogの2008-08-10の私のエントリって多分このfixのことを言ってるんだけど、ChangeLogの変更だけcommitしてこっちの方をcommitするのを忘れたのかなあ。
#にわかにはわからないです ^^;
##8/14のマージってどういう内容だか憶えてないんですが、たぶん過去の修正と処理がかぶってて整理したんじゃないかと思うんですが
#2008-08-14 Tatsuya BIZENN <bizenn@arthub.net>
* Fix: src/kahua/protocol/http.scm, src/kahua/server.scm
Merge the 2008-08-10 fix into the 2008-03-05 fix.
#trunkからのマージ時にrevertされてるな。これって他の箇所で習性されたんだっけ。
##いや、svn upしたらここでdiffが出たので、あれれと思っただけなんだけど。
#マージの際にしくじった可能性もあるので、後でチェックします。今ちょっと手が離せないので
#もし意図してのrevertでないのなら、こっちから再びcommitしときますよ。どっちにせよ急ぎではないです。
#了解です。さすがに2年前のことなので全くカケラも憶えてないので、どういう意図だったのか(そもそも意図して)だったのかわからないのです。
#stableからtrunkに移るのって結構大変? (Gaucheはtrunkを使ってるものとして)。Kahuaで運用してるサイトのパフォーマンスチューニングをする必要が出てきたんですが、stableでいじるよりtrunkに乗り換えた方が後々面倒でないならそうしようかなと思って。
#yasuyukiがstable1_0に加えた変更もtrunkにマージしてないんだよなそういえば。
#いや、そんなことはないとおもいますよ
#特に設定やアプリケーションコードの書き方が変わることはないはずです
#ただ、こないだGauche trunkの機能に依存する変更を加えたので、Gaucheのtrunkでしか動きませんが
#おっけー、そんじゃこれを機にtrunk試してみます。
#だから問題ないと思います
#お願いします
#あ、Gauche trunkのpartial continuationは大丈夫かな…まあdogfoodingになるからちょうどいいか。
#dogfoodingって言い方変? 動詞ならdogfeeding? それも妙だな。
#今のところ自宅のサーバで軽く運用していますが(アプリケーションはkahua-web)、落ちたりはしていないです
#ぐぐってみたらdogfoodingで良いようだ。
#アクセスがほとんどないのでテストにならないけど(笑)
#今の仕事が一区切りついたらKahua HEADをtrunkに入れ替えよう >おれ
#arityの逆に、関数が返す値の数のことを何と呼ぶのだろう
#む、言われてみれば…わからない。"n-ary" に対応するのは "n-valued" って気もするけど、そのnのことを指す単語って無いような。
#多値ってやっぱり日陰者なんでしょうかね...
#多値を返すのは関数とは言いたくないなぁ．数学としては．
#多値は一級市民じゃないから > 日陰もの
#半人前？
#あまりに期待通りの反応 ;-)
#もちろんarityも常に1だよね?
#あまりに期待どおりの反応 :p いやでもね．多値から多値への射というの考えるとなにかこれまでにない表現ができるかも．
#そういえば、curryingの逆(?)ってのはないのかな
#uncurry ?
#いや
#返すべき値を1個ずつ返す
#.1対多の写像と考えてもイヤですか。そうですか。
#values がそうじゃないの？
#I/Fがうまい具合に行かないな
#何となく考えたのは
#あるthunkをある手続きに適用すると
#値がひとつと、thunkが返す値の個数-1個の値を返すthunkが返る
#CPSde
#みたいな感じ
#CPSで考えて継続がcurry化されてるとしたら
#多値の直感的な意味ってどういうものかしらん．なんかうまい例というか説明ってあるの？
#なんかSafariだと異様に重いから、SRWare Ironに乗り換え
#ああ、でも継続をthunkとして取り出さないと結局扱いにくいか。
#いや、今サーバ自体がちょっと重め。load avgが8くらい。
#おっと、そうでしたか
#多値って、そんなに説明が必要?
#m-in、n-outって自然な気がするんだけど
#いや，上手く使いこなせない感じがする．
#行儀の悪いクローラが来てるっぽい。
#そうなんだけど．出力を入力に直結できない．
#それはAPIの問題?
#あれ、topで見ててCPUが9999%になることがあるんだけどなんじゃらほい。
#APIの問題ではあるんだけど．そのまま放置されているのはそれなりの理由があるのではないかという予感．
#>nobsun 私の多値関数のイメージは電子回路です。プログラムコードが書きにくいのは記述の問題だと思う。
#例えば、今仕事でCascadingってフレームワーク使ってんだけどさ
#これはHadoopの上に組まれたフレームワークなのだけど
#APIの問題と記述の問題の区別がついてない > 儂
#タプル in タプル outですごい使いづらい
#普通に引数m個でn個返せたらどんなに楽かと
#うわload avgが20
#で、処理間をつなぐのはフレームワークまかせなので
#chatonのアーカイブに絨毯爆撃
#タプルの使いにくさというのは，分解が面倒ということ？
#そう
#Javaだから分配束縛使えないし
#よっぽど、クロージャごしにCascadingの処理を書いて、*.cljは「設定ファイルだ」と言い張ってやろうかと思ったけど、大人なのでやめた
#(***) :: (a -> b) -> (c -> d) -> (a,c) -> (b,d) みたいなコンビネータがあればよいのでは．そうじゃない？
#Clojureね
#Javaでコンビネータ書けるの? それが書けなくてまた一苦労してんだけど
#そんな．おとなぶってるやつばっかだったから，今苦労してるとおもわない？
#それはともかく、コンビネータがあれば多値がいらない、という理屈になるの? そこがちょっとわからないところ
#いやそうじゃなくて，f *** g と書けるから，関数を並列にならべて，多値 → 多値 が表現できるんじゃない？
#→ f →
#→ g →
#左から2入力，右へ2出力
#ああなるほど、言いたいことはわかった気がする。が、それが多値よりも使いやすくなる気がしない
#てな感じ．
#それに、3 in 2 out な場合は例えばどうなるんだろう
#いや多値よりつかいやすいといわけじゃなく，これで多値なみにならんかね．ということ．
#それは単に合流関数があればいいでね．
#つまりuncurryかな．
#ふむ
#あれ逆curry？
#多値なみになるかどうかはわからないけど、Cascadingのモデルはたぶんそれなんじゃないかという気がしてきた
#使いにくいと言うより、まだるっこしいんだよね
#どう書かなきゃいかんものを，どう書きたいの．よく見えてないかも儂．
#入力と出力のある処理をパイプライン状につなげていくというのがCascadingの基本なのね
#ふむ．
#で、各処理は1個以上の「フィールド」に分けられた値を入力として受け、何らかの処理をしてから1個以上のフィールドからなる出力を行う
#で、Cascadingは、Javaがプログラミング言語だっていうせいもあるんだろうけど
#これを1タプルin、1タプルoutというメソッドをもつクラスとして表現しているわけだ
#ふむ．
#実際には引数に渡って来るクラスのインスタンスから入力値のタプルを取り出し、そのインスタンスの出力用のインスタンス変数に出力値のタプルを破壊的にセットするというげろげろなAPIなのだけど
#まぁ、本質的には1タプルin、1タプルoutなわけね
#ふむふむ．
#だから、処理を行うメソッドのシグネチャを見ても、いったいいくつの値の入力を想定し、いくつの値を出力するのかにわかにはわからんのよ
#くわえて、処理ごとにタプルの分解、組み立てを行うわけで、これが面倒くさい
#(a,b) -> (p,q,r) とかいうシグネチャじゃないちゅうこと？
#ちがうね
#あら．
#void operator(FlowProcess fproc, FunctionCall fcall)みたいなシグネチャに統一されている
#どう読むのこれ↑
#で、operatorの内部で、fcallから渡された引数をえっちらおっちら取り出し、出力値の組をタプルに仕立ててfcallにセットする
#どう読むっつーか
#そういう宣言になっているだけだよ
#入力も出力も表現されてないのか？
#うん
#スマソ．わしインタラプディッド．
#core吐かなくて何より(笑)
#でも考えてみると、入力のシグネチャは仮引数を見ればわかるとしても、出力のシグネチャは表現する術がないんだよな(少なくともLisp/Schemeでは)
#返り値をタプルに詰めるのではなく、そのタプルをカリー化した形で返せないかなーと思ったが、それってジェネレーターか？
#てことは返り値と新たなジェネレーターのタプルを返すようにして結局モナドで包むことになるか。
#あー、でもそれだと順序が意味を持つな。
callerがその受け取った返り値を使わないなら、その値は計算されないのがいいな。
タプルでいいけど返り値(多値)のカリー化とかどーなんだ？
flip出来ればいいのか？
#Wikipediaによると、関数が返す値の数って co-arity というそうです。
##「多値を返すのは関数とは言いたくないなぁ．数学としては．」って、複素関数論とかやると多価関数がばしばし出てくるじゃないですか。
#まあ、定義によりけりだけど、数学じゃないといわれるとちょっと悲しい。
#うーん、調べてみると関数って多価関数を除いて考えるのか。
#何となく宗教戦争の臭いがする
Gauche > Archives > 2010/08/03