平成17年3月1日(火曜日)
☆昨日
|
．「 |
☆ぐる
|
．エスケープシーケンス 。 いうまでもなく VT100 以外でうまくゆく保証がないので注意。 ．本当ならば termcap の cl アトリビュートを引っ張ってきて 以下略とかするのが良いのですが、めんどいので
system("clear");
とかどうですかね。
|
|
．「 |
|
．エスケープシーケンス 。 いうまでもなく VT100 以外でうまくゆく保証がないので注意。 ．本当ならば termcap の cl アトリビュートを引っ張ってきて 以下略とかするのが良いのですが、めんどいので
system("clear");
とかどうですかね。
|
|
．「 |
|
．Ajaxつーのが流行ってるらしい(ここで 1 面の BGM が脳内再生)。 ．JavaScript プログラミングでいつも悩みの種になるのは、 表のページとは独立に裏でサーバと通信する良い方法がないってことだったんだが (Image クラスを使うと GET リクエストを送ることだけはできる)、 MS の MSXML ActiveX モジュールの XMLHttpRequest インターフェースを 使うと自由自在にそれができるっつーのがキモ。 ．コンセプト自体はそんなに真新しくはなく、 みんなこういうことを考えるんだけど それを実装するいい方法が思い浮かばなかったところに、 そのためのうまい方法が確立されたという話であるような気はする。 ．オープンソース・イニシアティブ、ライセンス急増への対策を提案 。 「明確に書かれた簡素で理解できるものでなくてはならない」って、 それは GPL をオープンソース非準拠にするってことですかね。 Bruce Perens のいうとおり、OSD に追加するべき条項じゃないよな。 ．まあ、フリーソフトウェアのライセンスなんて GPL と MPL と BSD ライセンスがあればほとんどのケースをカバーできるんだけどな。 ．この三つのライセンスは、 ソース参照自由の保証に関して、 その伝搬性の有無と伝搬性の縦横という二つの相で見たときに プリミティブな 3 つの状態をそれぞれ代表しているライセンスになる。 ．これら 3 つのライセンスはどれもソース参照の自由を保証しているのだけれど、 派生品に対する保証に関してその適用範囲が違うわけね。 BSD ライセンスはその保証を伝搬させなければならないという一切の義務が無い。 GPL と MPL は両方とも伝搬させる義務が付加されているのだけれども、 その責任範囲が違う。 ．MPL はそれぞれのソースファイルに対する変更を参照する自由を 保証しなければならないのだけれども、 これを時系列的な観点から「縦の伝搬」と呼ぶ。 GPL はこれに加えて時系列的に横に同時に存在する別のソースファイルにも その義務が伝搬するから、「縦横の伝搬」と呼べる。 ちなみに、横の伝搬だけを保証するようなライセンスには あまり存在価値が無いので考えない。 ．まとめると、
．某所より 堀江社長 証取法不備認める 。 それ全然おもしろくないよホリエモン。 これじゃ後ろめたいことをしたときの自己弁護だ。 「法の範囲内のことをやって何が悪い?」って開き直らなきゃ。 ．堀江くんのことはもういい 。 わはは。 この後あまり面白い展開があるようには思えないので、 「もういい」「フジの醜態を他山の石とする」というのは妥当な見識といえよう。 ちょっとだけ「 |
|
．「 |
|
．DSEmu で TetrisDS が動くようになってたので、 チェックアウトしてコンパイルして動かしてみた: ．見つけた NDS 開発情報を記録してゆくページ もよろすく。 |
|
．論争をまとめてみた。まとまってない 。 しかし Web 日記の初期からこの手の論争って進歩ないな。 まあ例の「己の声の大きさを知れ」という一文に集約されるわけだけれども。 ．それにしても、こういう文脈で書き手が発する「嫌なら見なくて結構」 というたぐいの言葉はいつ見ても下品だなぁと思う。 そんなことはありえないんだけれどもし仮に、 読者の全員が「嫌だから見ない」と表明したとしても、 それでもこの言葉を(単なる意地ではなくて冷静に)発せられるとしたら それはそれで本物だけれども、多くの場合どこかで(多分無自覚的に) 「誰にも読まれないことなんてありえない」という思い上がりを持ってる 人間しかこういう言葉は発しない。 そしてそれ(=「誰にも読まれないことなんてありえない」)は多分正しい。 むしろ「それでも一定数は読む」ケースのほうが多かろう。 これも、ある一面で極端に正しい言葉だからこそ下品なんだろうな。 結局、裏にあるのは「読まれたもの勝ち」という考え方だよなぁ。 それが悪いとは言わないんだけど、私の感覚としては下品だなぁと思う。 ．なおこれは「最初から読み手を想定して書く」ということとは違うので注意。 どんな文章も多かれ少なかれ自ずから 読み手を選ぶという性質があることを考えれば、 確かに書き手として最初から読み手を想定して書くこともあるかもしれないし、 「あーこれはあまり読まれないだろうなぁ」 と思うこともあるかもしれない。 で、 そういう場合に己の無力(まあ書くということが内在してる無力なんだけれど) の言い訳として「嫌なら見ないでいいですよ」 と表明するのはしょうがないことだとは思う。 ま、そんな分かり切ったことを書くのはそれはそれでみっともないけど。 そんなこと言われんでも読まんわい。 ．結局のところ、 読者が人間であるということに無自覚ではいかんと思うんだよなぁ。 「そんな当たり前のことを」と思うかもしれないけど、いや、 これがなかなか難しい。人間であるということが頭でわかっていても、 目に見えない読者というものを人間として尊重するということが難しい。 まあ私自身がそれをできてるかどうかはともかくとして、 いい文章というものはそういうもんだと私は思う。 対して、たとえば「読まれたもの勝ち」という極端な姿勢は読み手側の人間を 単なる頭数としてしか見てないわけで、 これは人間を尊重しようとしてるんじゃなくて 文章で人間を操ろうとしているに過ぎない。 でも、読み手は人間なのでそういうのを遅かれ早かれ察知するもんだと思うぞ。 ．ご乱心 。 カナロック切ってないんじゃないカナ切ってないんじゃないカナ。 ．電球形蛍光灯について 。 高いほうを売ったほうが利ざやが大きいはずなのに、 正直に蛍光燈のほうが不利なこともあると言っている 東芝ライテックに好感が持てますな。 リンク 。 |
|
．「 |
|
．「 |
|
．「 |
|
．C++ テンプレートライブラリに LGPL を適用するのは無用な混乱を生むよ、という話。 ．LGPL はヘッダファイルのインクルードについて、 work that uses the Library (ライブラリを利用する成果物)と derivative work of the Library (ライブラリから派生した成果物)という 微妙な区別を与えている。LGPL の第 5 条は、 コンパイル時に LGPL なヘッダファイルをインクルードした場合、 その結果できあがったオブジェクトファイルが derivative work of the Library になるかどうかの判断を 基本的に法の判断に委ねているのだが、 しかしながら以下の条件を満たしていれば そのオブジェクトファイルは法の判断にかかわらず derivative work of the Library ではないと見なされる: such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length)いうまでもなく、これにあてはまらないオブジェクトファイルで、 なおかつ法的な判断によって「派生である」と見なされるようなケースでは、 コンパイル結果のオブジェクトファイルそのものが derivative work of the Library の扱いになる。 ．派生物とは見なされていないオブジェクトファイルを LGPL なライブラリの 本体とリンクした場合、その結果の実行ファイルは work that uses the Library と見なされるので、 LGPL の第 6 条の例外が適用できるため、割とゆるい配布条件になる。 しかし、derivative work of the Library と見なされるようなケースでは第 6 条の例外を 適用することができないので、 実行ファイルに対してほとんど GPL と変わらないような配布条件を適用しないといけなくなる。 ．で、テンプレートライブラリというのは「small でない inline 関数の塊を実装したヘッダファイルのみの集まり」 として実装されてることが多い。 そのようなテンプレートライブラリを使おうとすれば、 LGPL が明記する第 5 条の条件は満たさなくなると考えるのが自然であろう。 したがって work that uses the Library と derivative work of the Library のどちらになるのかという点に関しては 法の判断に委ねるってことになる。 しかし、少なくとも LGPL を書いた人間は、こういうケースでは derivative work of the Library になる可能性もあると判断したからこそ わざわざ small な inline 関数について除外することを明記しているわけだし、 そのテンプレートライブラリに LGPL を適用することを判断した 著作者も同じ判断を持っているからこそ(その条項を持ったままの) LGPL を適用しているはずである。small な inline 関数ですら法的に derivative work of the Library になる可能性があるという 判断をしてるはずなのに、テンプレートライブラリの主構成要素であるはずの small でない inline 関数について著作者が言及しないというのは 全くもって不可解だが、 いずれにしろ単なる利用者にとって論理的に導き出せる結論は 「どっちにころんでもおかしくない」以上でも以下でもない。 ．しかしながら、実際には利用者のリスクは低いとは思う。 テンプレートライブラリにわざわざ LGPL を適用してるのに、 それをインクルードして使っただけでオブジェクトファイルが derivative work of the Library となってしまうようなことが 作者の本意であるとは考えにくい。 これは上の「derivative work of the Library になる可能性」について 「著作者も同じ判断を持っている」という記述と矛盾するわけだけれども、 これはきっと「著作者も同じ判断を持っているから LGPL を適用した」 という前提が成り立ってないんだろう。 まあ、著作者が法的にも derivative work of the Library とはならないという判断をしていて、 なおかつあえて LGPL を適用したという可能性もないではないが、 一番ありうるシナリオとしては、よーするに LGPL をちゃんと読んでないか 読んでても何も考えてないかのどっちかだろうな。 ．で、テンプレートライブラリに LGPL を適用しようとしている人が 本当に望んでいることが何かというのを推測してみると、 きっと次のようなことだろう:
．上のような意図をライセンス上明示したいのならば、 LGPL の代わりとして私がお薦めするのは MPL ですな。 MPL には例の縦伝搬性があるので、 オリジナルソースコードおよびそのソースコードへの改変に 対するアクセスの永続的自由を保証できる。 MPL は最初から「(それぞれの)ソースファイル」という単位で そのあたりの適用範囲を規定しているのだけれども、 テンプレートライブラリはヘッダファイルが単体で存在する場合や、 機能的に見て独立したヘッダファイルがいくつも集まっているような 場合がほとんどなので特に都合が良い。 一方の LGPL というのはもともと、 GPL が無制限に持っていた縦横伝搬性のうちの横方向の伝搬に制限を 設けるという考え方だけれども、各ヘッダファイルの独立性が高いのだから 最初から横伝搬性を必要とするような対象が存在しないので、 そもそも LGPL を適用する必然性がない。 MPL の欠点は GPL と混ぜられないことなのだが、 これは GPL と MPL のデュアルライセンスにすると良い。 ．それ以外の選択肢としては GPL に例外を付けたライセンスを 適用するという手もあるけれど、 私自身は自分の好みとして GPL およびその派生物をお薦めしてないので ここであえて述べようとは思わない。 ．ま、私の個人的な意見としては、 BSD ライセンスにしとくのが一番何も考える必要がなくて楽だと思うわけですが、 GPL よりはまだ MPL のほうが好みに合う。 あるいは私の好みはさておいても、実は MPL のほうが目的にフィットするのに MPL というものを知らないばっかりに何となく GPL/LGPL を付けてるケースというのも少なくないのではないかという気がする。 テンプレートライブラリに限らず、 自作のライブラリになんにも考えずに LGPL とかくっつけてるような人は、 代わりに GPL と MPL のデュアルライセンス(場合によっては LGPL とのトリプルライセンス)を検討してみる価値はあると思う。 |
'cat'や'less'ではUTF8エンコードされたファイルを正しく表示できません(; д ) ゜゜ ．まあ好意的に見れば、「コンソール環境などでは」と限定してるから、 現象としては正しいかもしれないけれど。 基本的には、X上のVT-220対応端末であれば、UTF-8が表示できるはずなんですけどね。(; д ) ゜゜ |
|
．全面禁煙化、ＪＲ応じず 。 まあ分煙さえちゃんとしてくれれば別に全面禁煙する必要はなかろうな。 JR は長距離列車が多いのでしょうがない部分もあろう。 でも分煙すらちゃんとできてないのが困ったもんだし、 旧国電のホームくらいは私鉄に倣って禁煙でもいいと思うのだが。 ．ま、以前にも何度か書いてるが、 JR が全面禁煙に踏み切れないのはそれだけではなくて、 旧国鉄債務償還の財源がたばこ特別税だからってのもあるんだろう。 |
|
．神保町。 ．買い物をすませて三田線ホームで電車を待っている時、 いつも目につくのがホームドアに貼ってある広告である。 「四角い余白を見たらそこに広告を出せ」というのが広告代理店に勤めるものの 基本的な心構えらしいのだが、ホームドアのドアのない部分に延々と 続く横長の四角形もそんな広告代理店の営業マンの琴線に触れたらしく、 薄いビニールシートのようなものに印刷された広告が貼ってある。 ．さて、 もうすぐ春休みになるこの季節の恒例といえば小学館の学年誌「小学一年生」。 最近テレビを見ていないのでわからないが、 お茶の間では例の CM がパワープレイされていることは想像に難くない。 神保町といえば一ツ橋派は小学館の本拠地なわけで、 お膝元にあるそんな格好の広告スペースを見逃すはずもなく、 遺漏なく小学一年生の広告が張り出されていた。 ．この広告、大書きされた「小学一年生」のロゴの前に 数人の女の子と男の子がいろんな姿で左右対称に並んでる図なのだが、 その「いろんな姿」ってのが 「パパとママの夢」という趣旨でみんないろんな職業のコスプレをしてる。 スポーツ選手だったりギタリストだったり客室乗務員だったりそんな感じなのだが ．で、わたくし、暇なときはついついつまらないことを考えてしまう癖があるので、 このときもその例にもれず彼ら彼女らの将来の姿を想像してみたわけ。 ．立派に成長し、一流の選手としてセリエ A で活躍する彼。 ．国際線の客室乗務員として英語バリバリで世界中を飛び回る彼女。 ．いいなあ若者は。 ．……さて、こうやって順番に想像していったところ、やはり まん中の二人についても同様の想像をせざるを得ないわけなのよん。 身なりをそのままに、体だけ大きくなった男女。 そう、 真新しい紺のブレザーに黒いランドセルと半ズボンを身につけた二十過ぎの男と、 真新しい紺のブレザーに赤いランドセルと紺スカートを身につけた二十過ぎの女が 並んでる姿を。AV か何かですかね。 ．内心苦笑していたわたくしであったが、 次の瞬間電撃的な神(妹神)の啓示により一つの真理に到達した。 ．「そうか、これが『パパとママの夢(のプレイ)』なのか!」と。 ．……真理に到達した時に得られるはずの、あの充実感ではなく、 何故かは分からぬがえもいわれぬ疲労感に襲われ項垂れていたわたくし。 そんなわたくしを鼻で笑いつつ三田線西高島平行きの電車が横スクロールで入線。 けたたましい電子ベル音とともに扉が開いたので乗り込む。 ．乗り込んでしまえばやっぱり暇だ。 ここで余計な思考の関心は少し別の方向に向かう。 槍玉に上がったのは入学式ルックそのものだ。 女の子はいい。紺のブレザーに紺のスカート。 実に整った身なりだ。 ちょっとデザインを何とかすれば別に大人が着ても違和感はない。 ランドセルを除けば。 ．問題は男の子だ。 ．紺のブレザー。これはいい。 実にフォーマルだ(厳密にはブレザーは軽装だけど)。 わたくしがここで世に問いたいのは……そう、上はそこまでフォーマルなのに、 何故この期に及んでもまだ下が半ズボンなのか、ということだ。 だってそうでしょう。 大の大人が同じ格好をしてごらんなさい。みんなのいい笑い者だよもん。 せっかくのハレの舞台なのだから、 この日ぐらいは男の子も紺のスラックスを履いたっていいじゃないかッ! ．ここでわたくし、またもや神(巫女神)の啓示を受ける。 半ズボンといえばハリーポッター、ハリーポッターといえばハーマイオニー。 いや、三段論法の到達先がちとずれた。 半ズボンといえばショタ、ショタといえば腐女子である。 考えてみれば一昨日は世界腐人デーだし、無関係とも思えない。 ……そうか、そうだったのか。これはきっと腐女子の陰謀に違いない。 わたくしはそう結論づけた。 ．いつの間にか目の前に春日駅の文字が。 けたたましい電子音が響き、扉が開く。 押し出されるままにホームに降り立ち、改札へと向かうわたくし。 「腐女子最強、か……」そうつぶやいてホームを後にした。 |
|
．中西一善衆議院議員を強制わいせつ容疑で逮捕 。 最近の脳生理学の研究によれば、 長い間国会議員をやっていると脳波が痴漢と一致するようになることが 知られています。 |
