日々の流転

λ. LLTVのチケットを購入

今更ながら、LLTVのチケットを購入。

セブンイレブンで発見すれば、たまったQUOカードを消費できるかと思ったら、チケットの支払いは現金でないと出来ないらしい。しょぼーん。

λ. Shibuya.lisp テクニカルトーク#3

Shibuya.lisp テクニカルトーク#3に参加してきた。

今回参加するのにあたって、yad-ELさんの「参加者がやっぱり物見遊山的に見えてしまうんだよね」には、耳が痛かった。 というのも、私はLisp周りでアクティブに活動できているわけではないので、自分が参加することによって、Lisp周りでアクティブに活動されている方や、将来そうなる可能性のある人の席を奪ってしまっていたら申し訳ないので。 まあ、前回と違って、今回は翌日になっても席が埋まってなかったので、まあいっかと思って参加登録しちゃったけど。

(後で書く)

• 世界一短いコードでwebアプリ作成ができるフレームワーク開発 (松本 智行 さん)
• R5RS 完全準拠 JVM 日本語 Scheme インタプリタ 「Gino(仮)」(ilma さん)
• teepeedee2: fast IO in Lisp (John Fremlinさん / MSI)
• Inside c-wrapper (小黒 直樹 さん)
• (現場のScheme)と(Gaucheの進化) (川合 史朗 さん / Scheme Arts, LLC)
• Scheme on Ruby on Rails (Yuumi3さん / Gaucheファンクラブ)
• WebブラウザをインターネットOSのシェルにしてGaucheと対話する (源馬 照明 さん / 名古屋大学大学院多元数理科学研究科)
• 失敗したら会社終わるようなプロジェクトで本当にlispを使ってみた (mitamexさん)
• Emacs上での携帯絵文字の表示と入力補完 (IMAKADOさん / 面白法人KAYAC)

λ. “Referential transparency, definiteness and unfoldability” by Harald Søndergaard and Peter Sestoft

Chatonのhaskell-jpルームで2009-07-03と2009-07-04にあった、参照透明性と副作用の定義に関わる話で出てきた論文。積読論文の中にあったので読んでみた。

参照透明性(referential transparency)はQuineによって考えられた概念で、LandinとStracheyによってプログラミング言語の性質として使われるようになった。が、その定義・使われ方は変化しており、それらは同値ではないという話。

それらを、この論文での呼び方で呼ぶと以下のような感じ。

確定性 (definiteness)

変数がそのスコープの中で単一の値を持つこと。xを変数とすると、x-xは常に0になる。

副作用がないこと (absence of side-effects)

副作用がないこと。この論文では取り上げていない。

決定性 (determinacy)

関数の値が引数の値だけから決まること。この論文では取り上げていない。

展開可能性 (unfoldability)

(λx. e1) e2 = e1[e2/x] が成り立つこと。

外延性 (extensionality)

“means that if we wish to find the value of an expression which contains a sub-expression, the only thing we need to know about the sub-expression it its value” [18, page 16] この論文では取り上げていない。 「フレーゲの原理(Frege's Principle)」とか、Principle of compositionality とか言ったほうが馴染み深い人も多いかも。

ライプニッツ則の適用可能性 (applicability of Leibniz's law)

“any subexpression can be replaced by any other equal in value” この論文では取り上げていない。

参照透明性 (referential transparency)

式eの位置pが参照透明なのは ∀e1,e2. e1=e2 ⇒ e[e1/p]=e[e2/p] が成り立つとき。すべての位置が参照透明なとき、その言語は参照透明という。外延性とライプニッツ則の適用可能性に相当。

これらを非決定的な作用的評価順序の言語からはじめて、セマンティクスを変えながら比較している。

• 最初の言語Q0は、非決定的かつ作用的評価順序で、かつ部分式の値ではなく部分式の形によって値が決まる演算子を持つ。Q0は definiteness, unfoldability, 参照透明性のすべてを満たさない。
• Q0を参照透明になるよう少し変更したQ1は、参照透明だが、definiteness, unfoldabilityは満たさない。
• Q1の評価順序を正規順序風にしたQ2は、unfoldabilityは満たすが、definitenessは相変わらず満たさない。
• Q2をdefinitenessを満たすように変更したQ3は、definitenessは満たすが、unfoldabilityは満たさない。
• 非決定性を諦めたQ4はすべてを満たす。

非決定的な言語ではunfoldabilityとdefinitenessが両立出来ないというのには気付いておらず、なるほどと思った。

λ. “Types are calling convensions” by Max Bolingbroke and Simon Peyton Jones

Types are Calling Conventions | Lambda the Ultimate より。 積読中だったんだけど、Chatonの haskell-ja > Archives > 2009/07/06 で出てきたので読んでみた。

Haskell の関数はカリー化されているとはいえ、実際に実行時に一引数渡して関数を返してまた一引数渡して……なんてやっていたら遅くて仕方がないので、実際には引数を出来るだけまとめて渡している。 一方で、複数の値を返すときにはタプルで返すように書くけれど、実際にタプルをヒープ上に確保してなんてやっていたら遅くて仕方がないので、これも出来る限り複数の値を直接返すようにしている*1。 それに出来るだけ非ボックス化して渡したり、他にも色々あるのだけど、こうした呼び出し規約の最適化をGHCは非常にアドホックな形で行っている。

これはあまりよろしくないので、これらの呼び出し規約の違いを型で自然に表現出来るような中間言語 Strict Core を導入し、そうした最適化を安全かつシステマティックに出来るようにしようという話。

Strict Core は名前が示すように正格な言語で、また関数が多引数・多出力になっている。 Strict Core では、評価済みのIntとBoolを一度に受け取って、評価済みのIntを二つ返すような関数の型は 〈Int, Bool〉→〈Int, Int〉 になるし、引数を一つずつ受けとるような関数の場合には 〈Int〉→〈〈Bool〉 → 〈Int, Int〉〉 といった感じの型になる。また、サンクは{Int, Bool}のような型になる*2。 以下では表記をわかりやすくするため、引数・返り値が一つの場合には山括弧は省略することにする。

そうすると、例えば以下のように呼び出し規約を型で書き分けることが出来る。 ただし、丸括弧で囲まれているのはヒープ上に確保されたタプルを表す単一の値の型。

• f1 : Int → Bool → (Int, Bool)
• f2 : 〈Int, Bool〉 → (Int, Bool)
• f3 : 〈(Int, Bool)〉 → 〈Int, Bool〉
• f4 : 〈{Int}, Bool〉 → (Int, Bool)

それで、Haskell(のサブセット言語)を Strict Core に変換して、その上で各種の最適化を行うのだけど、型として違いがわかると確かにわかりやすい。

示されている最適化は基本的に現在のGHCでも(アドホックながら)実装されているものなのだけど、6.2の Use-site arity raising だけは現在のGHCでは行っていない。 これは例えば zipWith : 〈{a} → {b} → c, List a, List b〉 → List c という関数の worker-wrapper 変換で、〈〈{a}, {b}〉→c, List a, List b〉 → List c という型の worker と、関数引数のarityの変換するようなwrapperへと変換するもの。 これは従来の動的なarityの検査*3の代替になりうる。

関連

• Making a fast curry: push/enter vs. eval/apply for higher-order languages - ヒビルテ(2004-11-16)

λ. ω人の小人のパズル

小人のパズルを100人からω人にしたらどうなるかという話を、PPL2009の懇親会で聞いた。 すなわち、各小人の前に可算無限人の小人がいる場合。

ω人の小人が怪獣に捕まってしまいました。 小人たちが怪獣に命乞いをしたところ、条件を出されました。

怪獣が小人たちを縦に一列に並べ、それぞれの小人の頭に 赤か黄色か青のうちのどれか一色の帽子を被せます。 小人たちは自分より前に並んでいる小人の帽子の色はすべてわかりますが、 自分を含め、後ろに並んでいる小人の帽子の色は全くわかりません。 （各小人は、自分の前に並んでいるω人分の帽子の色がすべてわかる）

小人たちはひとりずつ赤か青か黄色の色を一回だけ答えることができ、 それが自分の帽子の色と同じだった場合は命が助かるというものです。 答える順番はどの小人からでも構いません。

このような条件が与えられ、小人たちには作戦タイムが与えられました。 小人たちは少しでも数多く生き残れるような戦術をとるものとします。 たとえば、一番後ろの小人が目の前の小人の帽子の色を答え、 その小人は食べられてしまうとしても、次に後ろから二番目の小人が 今と同じ答えを言えば、その小人は助かります。 これを繰り返していけば、最低でも半分の小人は助かることなります。

さて、小人たちは何人助かるでしょうか？ また、そのときの戦略は？

なお、被らされる帽子の順番に特徴的なもの （赤、青、黄色が順番にならんでいるとか） はないものとします。

λ. “100 years of Zermelo's axiom of choice: what was the problem with it?” by Per Martin-Löf

2004年にワークショップ「Types for Verification」で聴いたとき には断片的にしか理解できなかったので、ちゃんと読んでみた。

• 10.1093/comjnl/bxh162
• KTH/SU Mathematics Colloquium でのレクチャーノート版

選択公理は非構成的だと非難されることがあったが、Brouwer-Heyting-Kolmogorov解釈(BHK解釈)的な観点からは
(∀i : I)(∃x : S_i)A(i,x) → (∃f : Π_{i : I}S_i)(∀i : I)A(i,f(x))
という形の選択公理は完全に構成的*1(参考: Agda による選択公理の証明)。その一方で、(ある種の直観主義的集合論であるところの)トポスの理論では選択公理から排中律を導くことが出来る。その違いは何でどこに問題があるのか、という話。

ここではZermeloの選択公理の形式化のうち「集合Sの分割が与えられたときに、Sの部分集合S1で、分割の各部分A,B,C,…との共通部分が1要素になるようなものが存在する」を、集合を型理論での extentional set *2 とする解釈で解釈したものを考え、分析している。

前述の構成的な選択公理からZermeloの選択公理を証明することはできないが、これを拡張した外延的な選択公理
ExtAC = (∀i : I)(∃x : S_i)A(i,x) → (∃f : Π_{i : I}S_i)(Ext(f) ∧ (∀i : I)A(i,f(x)))
where Ext(f) = (∀i,j : I)(i =_I j → f(i) =_S f(j))
からは証明可能で、さらに同値になる。

ただし、当然ながらExtACのうちの選択関数fがExt(f)を満たすという部分は実際には導くことが出来ない部分なわけで、こうして構成的な世界で考えてみると、Zermeloの選択公理の構成的でない部分というのは、「選択関数の存在」ではなく「選択関数の外延性」だったということがわかる。

関連

• Sets in types, types in sets - ヒビルテ(2008-09-21)

λ. 第五十四回圏論勉強会

今日は圏論勉強会。

P. Selinger, “A survey of graphical languages for monoidal categories”の 5 Traced categories 付近かららしかったのだけど、前回欠席していたのと、前々回やったことをだいぶ忘れてしまっていたので、4.2 (Planar) pivotal categories を、4.1 (Planar) autonomous categories を読み返しながらやった。

Pivotal category の定義中で使われている (A⊗B)** ≅ A**⊗B** をどうやって導くのか分からず困った。 (A⊗B)* ≅ B*⊗A* を証明して、(A⊗B)** ≅ (B*⊗A*)* ≅ A**⊗B** とすれば良い。 (A⊗B)* ≅ B*⊗A* は

• η_B;(B*⊗η_A⊗B) : I → B*⊗A*⊗A⊗B と
• (A⊗ε_B⊗A*);ε_A : A⊗B⊗B*⊗A* → I

とが、exact pairing になっているので、right dual の一意性から言える。

一意性の話は、4.1 (Planar) autonomous categories の Remark 4.1 にある。 (B, h : I→B⊗A, e : A⊗B→I) と (C, h' : I→C⊗A, e' : A⊗C→I) が共にAの right dual の条件を満たすとすると、 と が逆になっているので、BとCは同型になる。 逆になっていることを証明するには、まず片方は

を

に変形して、h'とe'、hとeをキャンセルすればよい。もう片方も同じ。

λ. 『奇跡のリンゴ—「絶対不可能」を覆した農家・木村秋則の記録』

リンゴの無農薬栽培を実現した話。 リンゴの場合に無農薬栽培がこれほど難しいのだとは知らなかったし、それを実現した木村さんの苦闘の物語も面白かった。

ただ、話としては面白いのだけど、こういうのってどうしても素直に受け取れないんだよな。 「死ぬくらいなら、その前に一回はバカになってみたらいい」というけれど、バカになって失敗した人は取り上げられないだけで数多いるはずで、その差が何だったのかが明らかにされずに、単純に感動を前面に出されると、「単に、たまたまうまくいっただけじゃないの?」と思ってしまう。*1 「プロフェッショナル仕事の流儀」という番組はあまり見たことないのだけど、「プロフェッショナル」という言葉を掲げるのなら、そこに切り込まないとと思った。

Quotation

p.126-127 より。

自分は農薬のかわりに、虫や病気を殺してくれる物質を探していただけのことなのだ。堆肥を施し、雑草を刈って、りんごの木を周囲の自然から切り離して栽培しようとしていた。りんごの木の命とは何かということを考えなかった。農薬を使わなくても、農薬を使っていたのと同じことだ。

病気や虫のせいで、りんごの木が弱ってしまったのだとばかり思っていた。それさえ排除できれば、りんごの木は健康を取り戻すのだと。

そうではない。虫や病気は、むしろ結果なのだ。

りんごの木が弱っていたから、虫や病気が大発生したのだ。

λ. 推移閉包が一階述語論理では表現できないことをAlloyで確認する

Alloy - 言語ゲーム(2009-05-27) にコメントした話から。

以前「推移閉包は一階述語論理では表現できないのね」と書いたが、 Alloyは一階述語論理に推移閉包を加えて拡張した論理なので、推移閉包の機能を使わずに書いた関係と、推移閉包の機能を使って書いた関係が等しいかをAlloy上で検査すれば、イメージしやすくなるのではないかと思った。

まず、集合UとU上の二項関係R1,R2を定義。

sig U {
  R1 : set U,
  R2 : set U
}

次に、R2がR1の推移閉包であることを、推移閉包の機能を使わずに記述してみようとする。

fact {
  all x, y : U {
    y in x.R2 <=> (y in x.R1 || (some z : U | z in x.R2 && y in z.R2))
  }
  //// 関係演算を直接使った書き方
  // R2 = R1 + R2.R2
}

そして、Alloyの推移閉包の機能を使うと、R1 の推移閉包は ^R1 と書けるので、R2 が ^R1 と一致するかを検査してみる。 ただし、あまりに trivialな例でも面白くないので、R1が空でないという制約を追加しておく。

fact { some R1 }

assert R2_is_TC_of_R1 {
  R2 = ^R1
}

check R2_is_TC_of_R1

で、検査してみると、例えば以下の図が反例として出てくる。

R2はR1を含む推移的関係になっているけど、推移閉包すなわち「R1を含む最小の推移的関係」にはなっていない。 こういった最小性や最大性は一般に一階述語論理では表現できない。

λ. “Observational equality, now!” by Thorsten Altenkirch, Conor Mcbride, Wouter Swierstra

Thorsten Altenkirch らの Observational equality シリーズ最新作、といっても2007年のだけど。

• DOI
• 著者版
• 発表スライド

通常の内包的型理論で何かやろうとすると、propositional equality が関数の外延性 (∀x. f x = g x) ⇒ f = g を満たさないために、いろいろ面倒なことになる。一方で、外延性を単純に公理として追加すると、canonical form に簡約出来ない閉項が出てきてしまう。 また、propositional equality から definitional equality を導くことを許す外延的型理論では、関数の外延性は成り立つが、definitional equality の判定が決定不能になるので、型検査が決定不能になってしまう。 まとめると、以下の三つの性質を同時に満たす型理論はこれまでなかった。

1. propositional equality が関数の外延性 (∀x. f x = g x) ⇒ f = g を満たす
2. 閉項はその型の canonical form に簡約出来る (canonicity)
3. definitional equality (≡) と型検査が決定可能

この問題を解決しようとする著者らのアプローチが observational equality を用いる observational type theory (OTT)。基本的には等号をすべての型に対して一様に定義するのではなく、値の振る舞いに着目した等号を型の構造に応じて定義していく。 例えば、関数型A→Bだったらすべての引数に対する値が等しいことによって定義するとか。

ただ、それだけではうまくいかなくて…… (省略)

著者らの前の論文 Towards Observational Equality からの大きな変化としては以下の二つ。

1. 通常の型の世界(set)と命題の世界(prop)の明確な分離
2. Type-directed quotation による definitional equality の拡張

通常の型の世界(set)と命題の世界(prop)を明確に分離し、setでの計算にpropから影響を与えられるのは矛盾を導けたときだけであることを示している。それによって、矛盾しない限りpropには幾らでも規則を追加出来るようになる。それによって、これまでのややこしかった構成が非常に簡単になっているように思える。

また、型主導で canonical form (やボックス)への置き換えを行う Type-directed quotation を用いて definitional equality を拡張し、命題を proof irrelevant にしている。 これにより、S≡T implies (s[Q:S=T〉 : T) ≡ (s : T) が成り立つようになり、definitional equality が成り立つ型の間での型変換が無視できるようになる。 それによって、これまで懸念だった、帰納的データ型をW-Typesにエンコードする場合の問題が解決する。

Agda2上への実装が示されていて、分かりやすかった。

関連

• Extensional Equality in Intensional Type Theory - ヒビルテ(2005-05-29)
• Towards Observational Type Theory - ヒビルテ(2006-05-16)

λ. 日本Ruby会議2009 1日目

これから出発。

メモ

Using Git and GitHub to Develop One Million Times Faster / Scott Chacon

gitはよく知らなかったけど、gitの内部の概念は面白そうだ。 あと、githubでのforkがマージされた比率とかのデータも面白かった。

Rubyの数 / 後藤 謙太郎

Rubyの数クラスがどうしてこうなっているとか、1.9でRationalとComplexが組み込みになったとか。背景としてMatzがあるのに笑った。

Ruby の標準乱数生成器とその改良案 / 村田賢太

Array#shuffle が Kernel.rand に固定されているのは確かに困るか。 モンテカルロには乱数よりもLDS(Low-Discrepancy Sequences)が良いが、間違った使い方をしたときは、乱数を使ったときよりも酷いとか。 rubyのバージョンによってアルゴリズムが変わったら、シリアライズは困るとか。まあ、やってやれないことはないだろうけど。

Rubyで楽しむBDD,ZDD / 倉井 龍太郎

BDD(Binary Decision Diagram)とZDD(Zero-Suppressed BDD)のライブラリの話。BDDといえば Binary Decision Diagram しか知らなかったけど、同じ略語の Behaivior なんとかというのもあるらしい。ZDDは知らなかったけど、Cuddパッケージにもちゃんとあった……

静的型付けを持ったRubyっぽい言語の設計と実装 / 橋本和典

静的型付けを持つRubyっぽい言語TRuby。パーサはほとんどMRIのparse.yを再利用。コア言語tiby(ちびー)へ変換してコンパイル。関連研究に Diamondback Ruby (DRuby) と truby。 多相レコードのようなものは導入しなくていいの?　というのと、多相レコードのような振る舞いベースの型と、最適化に使えるようなオブジェクトの構造に基づいた型とをどうやって橋渡しするのか、みたいなことを質問してみた。空気読んでない質問だったかも。他の人のコメントとしては、型よりも特殊化とかの方が良さそうではという話が。

Ruby VMの高速化の展望 / 笹田 耕一

色々情報をとれるように。たとえばTDATAにメモリサイズを返す関数を登録可能に。あと、参照しているオブジェクトの一覧を返す関数とかも考えているとか。 インスタンス変数アクセスの高速化のために、インラインキャッシュで、クラスとインデックスの組をキャッシュ。 NODEを非GC対象化。 論文を書こうとすると新しいことをやらないと、というジレンマ。 「Ricsin: Ruby にCを埋め込むシステム」面白そう。 組み込みRubyは怖すぎる。 TDATAにメモリサイズ取得用関数が登録できるようになったとかで、実際のメモリ使用量を踏まえたGCをするような構想はあるのか、と質問してみた。

懇親会の色紙は最初は「えーっ」と思ったけど、やってみるととても楽しかった。

λ. “Equality and hashing for (almost) free: Generating implementations from abstraction functions” by Derek Rayside, Zev Benjamin, Rishabh Singh, Joseph P. Near, Aleksandar Milicevic, Daniel Jackson

• 10.1109/ICSE.2009.5070534
• 著者版

akrさん(2009-07-18, 2009-07-19)とku-ma-meさんが、巡回構造のhashメソッドの実装法で盛り上がっていたので、そういえばこの論文でも巡回についても取り上げてたなと思って紹介してみた。 が、読んでみたら、equalityは今のRubyと同じような方法で、hashについては巡回がある場合には単純に定数を返しているというオチだった。 しょぼーん。

まあ、それはともかく、この論文は「equalityやhashの実装には落とし穴が色々あるので、手で実装する代わりにクラスに付与したアノテーションから自動生成しよう」という話。 使われているアノテーションは以下の通りで、abstraction function がイテレータを返すメソッドになっているのが、シンプルで面白かった。

λ. 日本Ruby会議2009 2日目

後で書く

Ruby 1.8 のゆくえ / 卜部 昌平

クリスマスリリースの制約がなくなったため(?)、1.8系のリリース間隔は伸びている。 Joe Damato の提案している インラインアセンブラを使ったパッチ(Fixing Threads in Ruby 1.8: A 2-10x performance boost)があって、自前でスタック確保して切り替えをするので2-10倍くらい早くなる。1.8.9 は多分無い。 質問を受けるだけで、答えるのはircとかまつもとさんとかという素敵なシステム。

Ruby 1.9.2ロードマップ / Yugui - 園田 裕貴

バージョン番号をけちる文化。拡張ライブラリの互換性。RSTRING_PTR / RSTRING_LEN などを使う必要がある。rb_str_newで文字列をつくるとバイト列としての文字列になるので、ちゃんとエンコーディング情報を指定して作る必要がある(rb_usascii_str_newなど)。 はやくパッチをマージしてください。 1.9にしたくて、ライブラリに片っ端からパッチを送ってる。Rubyは正論の通るコミュニティなので、不満はパッチに。

静的コード解析統合環境の試作 / 勝間 友久

静的コード解析ということで coverity 的なものを期待して行ったら、古典的なメトリクスの測定とlint的なソースコードの検査の話だったのでちょっとがっかり。 利用しているエンジンについてはranhaさんが書いているInfoQ: 静的解析ツールの総まとめ：Roodi、Rufus、Reek、Flayに簡単な紹介がある。 Ruby固有の問題や知見について質問してみたが、それはまだまだこれからのようだった。

基調講演 / まつもとゆきひろ

席にいくつかnilがはいってるのでArray#compactしてください(by 角谷さん)。lvar_propagateとか面白そう。

Lightning Talks

斉藤ただしさんのDecimalの話が面白かった。

分散並列処理フレームワークfairyと分散オブジェクトシステムDeepConnect / 石塚 圭樹、増田 創

.

偉大なBigTableとぼくのおもちゃ / 関 将俊

.

concov: 時系列に注目したテストカバレッジビューア / 遠藤 侑介

遠藤さんの発表はconconvの話も面白かったが、後半のあまった時間で関係ないことをしゃべりまくるフリーダムな感じが面白かった。

RubyのGC改善による私のエコライフ 〜レジ袋は結構ですよ(2009夏)〜 / nari

NODEを長寿命オブジェクトとして世代別GCをするとう話だったが、RubyKaigi直前にささださんがNODEをGC対象でなくてしてしまって涙目という話。 私が「GCはよくわかってないんですが」といって世代別GCの基本的なことについて質問したら、その後の質問者がみんな同じような聞き方をしていてうけた。 それから、去年のRubyKaigiで発表していたLazySweepの話はどうなったのか質問してみた。Rejectされたと思っていたら、自分でRejectしてたらしいw　 それにしても、nariさんは愛されてるなぁ。

お昼はranhaさん、soutaroさんと、ろしあ亭というところに。

λ. 日本Ruby会議2009 3日目

後で書く

ソケットライブラリの改善 / 田中 哲

寝坊してakrさんの最初の発表はだいぶ聞き逃してしまったが、あまった時間でやっていた、design decision を中心に説明する発表を聞くことが出来たので満足。 ソケット自体の話はあまりよくわかっていないのだけど、design decision の話はとても面白かった。 「inspect可能 = 意味がオブジェクト内で決まる」で何をオブジェクトにすべきかというのに関係している、という観点や、「Ruby が知らないオプションがあるかもしれないので、オプション毎のサブクラスは作らない」という話、それから「Best name should be best behavior」など。あと、「It is wrong if Ruby is harder than C」とか「知らないところにきいても仕方ない。Rubyのことはまつもとさんに」に笑った。

• 天泣記(2009-07-19)

スクリプト言語Ruby / arton

.

あらためて仕事で使うRuby / 後藤 謙太郎

.

Ruby製アプリケーションを配布するn個の方法 / 原 悠

今Rubyの仕様を書いているそうで。多重代入のカンマとか、よくわかんなかったら隣の人(matz)に聞くとか。Rubyを実行ファイル化する方法は、RubyScript2Exe, Exerb, Ocra, Crate と結構色々あったんだねぇ。Crateのスクリプトをsqliteのデータベースにしてそれも実行ファイルにくっつけるというのは、けっこうきもいと思った。

tDiary の Ruby 1.9 対応の過程と今後のロードマップ / 柴田 博志

.

Haml and Sass: Solution for you who get tired of ugly markup / 浦嶌 啓太

.

Take the Red Pill / 角谷 信太郎

角谷さんは運営委員長。実行委員長は高橋さんで、よくないことがあったら謝る人は高橋さん。青いピルを選べば、何もかも今までどおり。「会社に戻ってXMLエンタープライズ」　赤いピルを選べば「welcome to real world」。Rubyは無名の質を備えたプログラミング言語。

基調講演: Rubyと私、そして日本Rubyの会 / 高橋 征義

.

夕食はアボカフェというところで、アボガド丼などを。 アボガドとSPAMはよく合うなぁ。

λ. Real World Haskell読書会 2009-07

今回は5章「ライブラリを書こう：JSONデータの操作」で、昔書いたコードを思い出してちょっと懐かしい。 手抜き実装になってるんじゃないかと思ったら、エスケープする際にちゃんとサロゲートペアにしてからエスケープしていたりして、ちょっと関心。 あと、後半は簡単なプリティプリンタのライブラリを実装しているのだけど、プリティプリンタの仕組みはよく知らなかったので、面白かった。

• Chapter 5. Writing a library: working with JSON data (原文オンライン版)
• The Design of a Pretty-printing Library (著者版)
• A prettier printer

λ. Unicodeでの繁体字と簡体字

RWH読書会の二次会で、「Unicodeは意味が同じ繁体字と簡体字を統合してるから、中国と台湾では相手のメールとかをそのまま自分たちの文字で読める」というような話を聞いた。

そういう話は初耳だったので驚いたのだけど、「中国語版ウィキペディアでは自前で変換してる」という話を知っていたので、それはおかしいのではと思った。 また、Simplified Chinese characters - Wikipedia, the free encyclopedia にも以下のようにあった。そうだよなぁ。

Unicode deals with the issue of simplified and traditional characters as part of the project of Han unification by including code points for each. This was rendered necessary by the fact that the linkage between simplified characters and traditional characters is not one-to-one. While this means that a Unicode system can display both simplified and traditional characters, it also means that different localization files are needed for each type.

λ. 『化粧する脳』 茂木健一郎, 恩蔵絢子

を読んだ。 発想は面白いものの、なぜそういう結論になるのか良く分からない部分多し。

とりあえず、Onzo, A, Okazaki, S, Satuwatari K, Tanaka, Y, Sasaki, A and Mogi, K. Facial perception of self and others with or without makeup. (2008) Society for Neuroscience, Washington D.C., U.S.A. をちょっと読んでみたくなったのだけど、北米神経科学学会(Society for Neuroscience, SfN)って予稿集とかオンラインにないのかな……

λ. トンボ

セミの鳴き声が結構するのでセミを探すも見つからず。 代わりにトンボを発見。

λ. 携帯の番号が変わります

最近、携帯を変えました。MNPを使わなかったので番号が変わります。新しい番号は前の番号(090〜)から、電卓で1003227378をマイナスしたものです。また、メールアドレスはgmailのものを使っています。

λ. セミ発見

「鳴き声はすれど、姿は見えず」と思っていたら、網戸にとまっているのを発見。 今年初めて見た。 夏だなぁ。

λ. 阿里郎(ありらん)

今日は泳ぎに行く予定だったけど、食べにいこうという話があったので、そっちに行くことに。 食べたのは、羊肉串(?)、マッコリ、カイコ(!)など。 カイコをゲテモノだと思っていたら案外普通で、中はクリーミーな感じだった。ただ、ちょっと殻がうっとうしいけど。

λ. “Ricsin: Ruby にCを埋め込むシステム”笹田 耕一

を読んだ。

• 笹田耕一/笹田研の研究業績リスト