2010/12/05

git rebase

gitのワークフローやgitメモを書いた頃はgit rebaseの使い方がいまいちわからなかったのだが、最近はupstreamからの取り込みにmergeではなく専らrebaseを使うようになった。

ひとつの理由は、パッチ統合のスピードアップのために、テストが完全に済んでいないけれど取り込み予定のパッチを先行して含んだunstableブランチがupstreamに作られたこと。パッチの正式取り込みは機能テストだけでなく性能テストを通る必要があり、それには日単位の時間がかかる。masterのHEADで通るパッチを提出しても、その時点でテストキューにあったパッチがmasterにマージされた後に自分のパッチが処理されるので、そこでconflictを起こしてrejectされる、ということが頻発した。なので基本的な機能テストを通ったものが先行してunstableブランチにマージされ、特にリリース近くなってキューが詰まりがちな時はunstableに対してパッチを作って提出する、という流れになった。

ところが、unstableのパッチはその後のテスト結果によってrejectされることがある。unstableから手元にmergeしてしまうと、rejectされたものを後で取り除くのがかなり面倒になる。というわけで、masterとのsyncにはrebase、ってことになった。

rebaseの動作はgitのマニュアルに図入りで説明されているとおりで、この原理はすぐにわかる。でも原理がわかっても実際の応用がうまく掴めなかった。特に、conflictが起きた時にどう解消すべきか、というところ。

手元のtopic branchは細かくコミットしているので、同じ箇所をいくつものコミットでいじってる場合がある。そういう場所でnon trivialなconflictが起きた場合、topic branchの最終形に引きずられて直してしまうと、rebaseを続行した時に同じところで何度もconflictを起こしてわけわからなくなることがあった。

  --o--o--O--o--o--X        <- master
           \
            a--b--c--d--e   <- topic branch

こんな形からtopic branchでgit rebase masterしたとする。c, d, eは同じ箇所をいじってるコミット。で、rebase中にcでconflictが起きたとする。

この時考えるべきは、「もし自分がXから作業を開始していたとしたら、cでどのような変更をしただろうか」ということ。これを頭に置いておくと間違えない。元々のcでの変更は実はbuggyで、それをdやeで直したかもしれないけれど、この時点でのconflict解決には、cで持ち込んだバグをそのまま残す。一旦過去の自分に戻って自分の作業をトレースする感じ。

rebaseは履歴が書き換わるから安全ではない、というけれど、自分の過去の作業を、出発点を変えてやり直す作業だと思えば、その性質も納得できる。

Tags: Programming, git

2010/12/01

近頃のらむ太

らむ太の発想1

• ら:「よるはどうしてくらくなるの?」
• 私:「地球が回ってるからだよ。ほら、(地球儀を出して説明) らむ太はここにいるだろ、こっちを向いてる時は明るいけど、こっちになったら暗くなっちゃう。」
• ら:「ちきゅうはどうしてまわってるの?」
• 私: 「それは… (慣性をどう説明しよう)」
• ピコーン、らむ太の頭上に電球が灯った!
• ら:「あ、うちゅうじんがろけっとでひっぱってるんじゃない」

らむ太の発想2

• ら:「ひげはどこからでてくるの?」
• 私:「皮膚の中にひげの根っこがあって、そこで作ってるんだよ。髪の毛もおんなじ。」
• ら:「かみのけはどうしてあるの?」
• 私:「それはね…」
• ピコーン、らむ太の頭上に電球が灯った!
• ら:「あ、かみのけがないと、あたまが『はずかしー』ってなるからだ」

いやいやらむ太、父さんの友達に頭剃ってる人いるでしょうが。格好良いでしょうが。

らむ太の時制

以前は、過去の出来事を話す時何でも「らむ太が赤ちゃんの時」だったのだが、 最近さすがに近い過去について「赤ちゃんの時」はおかしいと気づいたようで、 「きのう」という言葉を使い始めた。

だけど、近い過去はすべて「きのう」なので話が通じないことがよくある。

未来についてもまだ「あした」「あさって」などは理解していない様子。 ただ、数日なら「よるなって、あさなって、またよるなって、またあさなったらいく〜」 という具合に数えることが出来る。

Tag: 生活

2010/11/28

applyの引数リストの長さの制限

http://twitter.com/cddddr/status/8982330207117312

タイプ数削減が目的で (fold-left f acc xs) を (apply f xs) と書くとリストが長すぎる場合怒られる事があるので xargs みたいな要領の xapply を書こうかなと思ったけど面倒なので fold-left で良いやという結論に落ち着いた

処理系の制限で短く書けないというのは癪に障る。 昔はGaucheでもapplyの引数リストに長いリストを渡せなくていらついたものだった。 十分いらついたので、今はこの通り。

gosh> (apply + (make-list 10000000 1))
10000000

引数の長さの制限は依然として存在するんだけど、 それが問題になることがほぼ無くなった。

VMの引数渡しは原則スタック経由、つまりcallerが引数を順にスタックに積んで、 caller側はスタックポインタ相対で引数にアクセスするようになってる。 Gauche VMはスタックが溢れるとヒープに移すようになってるけど、 スタックフレーム単位の処理なので、ひとつのスタックフレームの大きさが VMのスタックエリアを越えるような事態は想定してない。

以前のapplyは引数リストを分解してスタックに積んでた。 なので上のような式だとスタックが足りなくなる。

けれど、長大な引数リストを取るような関数ってのは、まず確実に、 不定長引数を取るような関数なんだよね。で、不定長の残余引数は calleeからはリストに見える。 つまり以前のapplyでは、わざわざリストで渡ってきた引数を 一回ばらしてスタックに積んで、それをcallee側でまたリストに直してた。

今は、callerが不定長の引数リストをリストのままスタックに 積めるようになってて、callee側の必須引数の数に合わせて VMが必要な分だけスタックに展開するようにしてる。 + は必須引数が0なので、上の式だとリストは一切展開されない。

ただ、Schemeの規格上、残余引数リストはfreshなリストでなければならない (calleeが残余引数リストを破壊することが許されている)ので、 リストをコピーして渡さないとならない。CLだとコピーはcallee側の責任なんだけど。 このへんはまだ工夫の余地あり。

今のVMで引数の数の制限に引っかかるのは、 caller側が実際に10000個くらいの引数を列挙するか、 callee側が10000個くらいの仮引数を持っている場合。

前者はまあ、マクロ展開の結果として生じる可能性はあるけれど、 後者のケースでない限りはapply使えば回避できるんで、 実用上は問題ないかと。

今書いてて思いついたんだが、後者のケースでも処理系がコンパイル時に 一定数以上の仮引数は残余引数リストで受け取るようにしてlist-refで 参照する、とか変換かけちゃえばいいんだな。

Tags: Gauche, Lisp, Scheme, Programming

2010/11/26

S式の呪縛

• http://www.dwheeler.com/readable/sweet-expressions.html やっぱS式suck! 頭の固いロートルLisperどもよ、俺がLispの美しい代替構文を考えてやったぜ。完全S式コンパチだが中置式もインデントも使えるぜ。ヨロシク。
• http://chrisdone.com/posts/2010-11-25-lisk-lisp-haskell.html Haskellクール! だけど構文がsuck! インデントセンシティブで綺麗になるのはサンプルコードだけさ。実世界のコードはどうせぐちゃぐちゃになるんだし。S式にすれば曖昧さ無くなるしマクロも使えるし良いことずくめだね! 中身はHaskell、構文はS式、これ最強!

Tags: Programming, Lisp, Haskell

2010/11/19

映画レンタルの黄昏

コンベンションセンターの向かいにあるDVDレンタルの Diamond Head Videoがクローズするそうな。 まだ店がKapahuluにあって、扱うメディアの多くがVHSだった頃から ちょくちょく利用してた。かなりマイナーなタイトルまで置いてあって、 品揃えは島一番だったと思う。Film Actingのクラスでの課題探しに重宝した。

まあ今や映画はネットで買えるし、うちみたいに居間にPCが無くても Netflixとか使えばいいわけだから、店構えてレンタルっていうのは 成り立たないのかもな。

Tag: 生活