>
>http://pcweb.mycom.co.jp/news/2006/02/17/341.html
>。なるほど確かにサンプルはパッと見には C とか Java によく似ているような気がしたのだが、よく見てみればその印象は(たぶん)セミコロンによってもたらされるものであって、ほかは $ もあるし where もあるし演算子をカッコで囲むと関数化するみたいだしまあこんなもんじゃないですか。サンプルはいろいろやろうとして難読化の道を歩んでいるだけなのではないでしょうか。
>
>個人的な趣味からすると end とかセミコロンはないのが Haskell のいいところだと思うし、文字列の連結が + なのかよ、と思うけど(型はどうなるんだ？)、さて、どうだろうか。
>Jaskell のページ
>
をつらつら見ていると、いかにも Java と Haskell の折衷的な感じがしてなかなかキモいです。きっとこれはお互いにキモいなあと思いあう中途半端さなのではないだろうか。引数の add (x, y) と add x y が同等とかさ。
>
>ところで、パターンマッチングとかはないのかな。パターンマッチがないなんて意味あるのかなあ。
>
>ところで、関数型言語が動的な言語だという意見はあまり見かけない気がするので新鮮だった。これも LL* の影響だろうか。 Haskell について言うと、ほとんどあらゆる意味で動的でないと思う。静的型言語だというのもそうなのだが、 Haskell をスクリプト言語っぽく使う人というのはまずいないように思う(Cabal の Setup.hs は数少ない例外)。なにせコンパイルが笑っちゃうくらい遅いので、スクリプト言語としては実用にならないんじゃないかと思うが、 Jaskell はどうクリアしているのだろうか……ってかたぶん評価順序とかその辺を難しく考えていないからなのかな。OCaml の方がスクリプト言語としてはよっぽど優秀。
>
>
>http://homepage3.nifty.com/iromono/diary/200602A.html#10
>。朝永振一郎の言らしい。ううむノーベル賞を取るほどの人はなるほど違うなあと思ったわけですが、ふと、
>
>
>「一仕事終わったところだし、じゃあハックするか」
>
>
>と置き換えると、ああなんだ、そんなに変じゃないかも。
>
>ところで上で「ブランチはレポジトリを分けてしまえばよい」という過激な発言をしましたが、ふつうの分散バージョン管理システム(GNU arch とか svk とか)はそういうことはしないようです。あまりよく知らないのですが、ふつうの分散バージョン管理システムではユーザごとにレポジトリがあるようなので。一方、私が最近よく使っている darcs という分散バージョン管理システムでは、そうではありません。
>
>darcs には「変更ベース」とか「パッチの理論」とか、いろいろ謎なワードが存在して他人を煙にまくことができるわけですが、それ以外の非常に大きな特徴として、ソースツリーごとにレポジトリが存在するという特徴があります。たとえばレポジトリを cp -a すればそのまんま新しいレポジトリができます。極めて単純なので極めて強力なモデルだと思います。
>
>でもそれって、同じようなメタデータがたくさん出来るから、ディスク容量的にはあんまり便利じゃないんじゃないか、という気もします。確かにそうなんですが、 darcs get で同一ディスク上のレポジトリをコピーするときは、変更データなどの共有可能なデータはハードリンクして無駄を省く、とかいったことをしてくれます。つまり、やりようによってはさほど無駄はありません。まあ最近はディスクも安いですしね。
>
>darcs は、あんまり自分で何もかもやるというシステムではなくて、細かいツールをいろいろ使う必要があります。面倒だしきちんとセットアップするにはdarcs ではないツールが必要です。たとえばパッチが送られてきたときに自動的にそのパッチをレポジトリに反映させるための procmail のレシピ、とかがマニュアルに載っていたりとかして正直「面倒くせえよ！」と思います。けれども、おかげさまで非常にシンプルなモデルになっているのは長所ではないかと思います。
>
>そういえば git ってどうなんかな。
>
>svk は使ったことがありません。 subversion はむかしは個人的に使っていましたが、 Berkeley-DB のバックエンドがいまひとついけていない感でした。fsfs がメインになったころには subversion をメインでは使っていなくて、いまは darcs をちまちま使っています。いや、まあ、 sourceforge.jp のレポジトリは CVS ですが。どうせ趣味なんで何を使っても可。
>
>話が逸れたけど、それで、掲題の話です。「分散バージョン管理？ 何だか知らんけどそんな大規模開発っぽい話なんて関係ないじゃん？」という人(昔のおれとか)は案外多いんじゃないかと思うわけです。でもそうじゃなくて、分散バージョン管理というのは個人レベルでも案外と嬉しいのじゃぜ、という話をここでは展開しようかと思います。
>
>「バージョン管理」というのは、プログラムのソースコードとか、あと個人的には自分のドキュメントを管理したりとかしていますが、そういうことをするツールです。バージョン管理は、チェックイン・チェックアウトモデルというモデルが使われています。これは、どこかにバージョンを管理してくれる保管庫(レポジトリという)が存在しているという前提があります。使うときには保管庫からまず取り出して(チェックアウト)、たとえば変更を行い、変更後のデータをレポジトリに書き戻す(チェックイン)という流れになります。レポジトリではファイルの変更履歴などが保存されており、最新版の変更がまずかったから少し前のものをチェックアウトしてチェックインする、といったことができるわけです。
>
>非常に古典的なバージョン管理システムが RCS で、これは作業ディレクトリの下の RCS ディレクトリがレポジトリになっています。 RCS はファイル単位のバージョン管理を支援するので、設定ファイルとかの管理ならともかくふつうのプロジェクトは使いづらい。そこで RCS をラップしていろいろな機能を追加し、複数ファイルをまとめて扱うシステムが登場します。これが CVS でした。
>
>CVS にはいろいろ問題があったので、その後継としていろいろなシステムが登場していますが、そのうちひとつが subversion です。 subversion は非常にシンプルなモデルを提供しています。 CVS の問題のひとつとして、 RCS をラップしているためディレクトリを扱えない、という問題がありました。subversion はディレクトリを扱うことができます。おそらくそのため、 subversion のレポジトリは擬似的なバージョン管理機構つきのファイルシステムのような体裁になっています。そこで「ブランチ」という処理も、バージョン管理システム上にディレクトリを分けることで実現しています。
>
>ちょっと話が逸れましたが、分散バージョン管理でした。そもそも何が分散しているのかというと、レポジトリが分散しています。もともとのバージョン管理システムでは、レポジトリからデータをチェックアウトして、チェックインするというモデルでしたから、レポジトリは本質的には1つしかありません。仮に同じようなデータを保持するレポジトリが2つあったとしても、両者を関連づける機能がありませんでした。逆に言えば、複数のレポジトリを関連づけ、まとめるのが分散バージョン管理というわけです。
>
>複数のレポジトリを関連づけるというのはどういうことかというと、特定の変更と同じものをほかのレポジトリに渡したり、あるいは受け取ったり、というやりとりが可能だということです。たとえばブランチを作りたいとします。上でも述べたように subversion では、あるレポジトリの上でディレクトリを分けることでブランチを表現していました。分散バージョン管理では、レポジトリそのものを2つに分けてしまえばブランチになります。どちらもふつうにバージョン管理でき、もし一方の変更(バグフィクスとか)をもう一方に伝えたければ、レポジトリ間で変更を送ればよろしい。モデルとして、非常にシンプルではないでしょうか。
>
>もっとしょーもない例を考えましょう。私はよくあるのですが、手元のノートPCで、数日以上にわたる大改造を行います。作業途中でコミットするわけにはいきません。ぜんぜんコンパイルが通らないコードがレポジトリの最新版になってしまいます。で、作業の途中で往々にして「今の3時間の作業は失敗だったからやっぱその前に戻したい」と思ったりするわけですが、コミットしていないわけですからもう無理ですね。こういうとき、手元のちょっとした変更用のレポジトリを、全体用と別に持ってると気が楽です。つまり、レポジトリを分散させたいわけです。
>
>分散バージョン管理では、手元でどんどんコミットしていって、ある程度ちゃんとした改造が完了したところで、みんながダウンロードするときに使うレポジトリにそこまでの変更を丸投げすればオッケーなわけです。これは、けっこうキラクな世界ではないかと思います。
>
>criternext がなぜかすべてのキーを手繰る前に終了してしまうという謎の不具合に遭遇。どうも調べてみるに、 0001/depot のキーしか取り出さないようだ。ところが crmgr list するときちんとぜんぶ取得できている。理由不明かつ詳細不明なので ML に投げて相談するべきか、と思い、自前のビルドしたプログラムと crmgr の違いを見ていて、どうやら pthread をリンクするかどうかの違いだということに気付いた。で -pthread つきでコンパイルしてみたところ、自前のプログラムはちゃんとキーを列挙できた。
>
>つまり、pthread をオンにして構築している環境で、 -pthread せずにビルドしたプログラムは挙動がおかしくなるという、考えてみれば当り前のことだった。それでもなぜそうなるかはよくわからないが、ひとまず動いたので良しとする。けっこう時間を食ってしまったよ。
>
>Ordering ってモノイドだったのか。→
>http://article.gmane.org/gmane.comp.lang.haskell.general/13269
>
>
>昨日の時点でwktkしていた通学途中のケーキ屋さんだが、今朝通りがかりにチラ見したら、すでに「ハッピーホワイトデー」とかなんとかいう張り紙に切り替わっていた。
>
>絶望した！
>
>464.jp とかいうサイトがあって漫画の「立読み」ができる、ってなことはネットで話題になったときに知っていて、しかしどう考えても真っ黒なことは明白(っていうのも奇妙な表現ではある)だよなと思っていたものの、いきなり
>逮捕
>という展開には驚いた。
>
>ただとにかくよくわからないのは、わかっててやっていたのか、わかっていない素人だったのか、ということ。いかにも素人臭いデザインとか、えらく使いづらく肝心の「立ち読み」もしづらい設計とか(話題になったころにちょっと見てみてあまりの面倒くささに驚いた)、著作権とかのことをまったくわかっていないアホの仕業らしきことがほの見えていたのだけど、出版社からの警告を無視したりとかいう話を読むと、わかってて何かの狙いのもとにやっていたということが示唆される。にしては何が狙いだったのかがよくわからない。
>
>というところで、スラドで知ったのが
>この記事
>(2つめのトピック)。
>
>
>しかしこのサイトを運営していた村元寅次さん、どうもキナ臭い匂いのする人のようで…。
>
>
>漫画サロン板の「464.jp」スレによると、読売新聞90年4月3日付けの読売夕
>
>
>刊の社会面にて、紙おむつ会社の運営を巡り会員制を敷いた所、倒産してしまい結果として入会金詐欺のような形になっているらしい。
>
>
>(中略)またその1年後、市販のブランド米を無農薬の「特別栽培米」と偽って通信
>
>
>販売、未返還の入会金約3千万円を手に雲隠れしたとの事。名簿も流失したらしい。
>
>
>とのこと。 464.jp も会員を募っていたようだし、同じようなことをしようとしたが失敗、という流れなのかな。
>
>通学途中にケーキ屋さんがあるのですが、少し前のあるときに「バレンタインフェア」とかいう張り紙があるのに気付きました。きっといろいろ売られていたのだろうと思います。ま、関係ないですが。
>
>しかし明日に行ったら売れ残りが投げ売りされているのではないか、と今から密かに期待しているのでした。
>
>ところで風野さんによれば韓国ではホワイトデーに加えてさらにいろいろあるようで(
>http://psychodoc.eek.jp/diary/?date=20060214#p01
>)、いやはやすごいですね。べつにどんな記念日があっても良いかもしれませんが、個人的にスゲエなーと思うのは、バレンタインデーにもホワイトデーにも縁のない人のためのブラックデー、とかいう日でしょうか。その定義はまあさておくとしても、そんな風習が広まっているというのが凄いなあと。日本で提唱した人がいても反感を買うだけで絶対定着しないだろうな。
>
>
>http://suntory.jp/BOMBE/
>。意外にもそんなに不味くなかった。明らかに不健康飲料ですが、まあそれはどうでも良いとする。
>
>ところでボンベって何語？ というのが気になったので軽くぐぐってみたところ、
>すごくきちんと調べている人がいた
>
(2つめの項目)。なるほどなあ。
>
