2009-06-09

using declarationとusing directiveの違い

今まで文法的な違いしか理解していなかったので、詳しく学ぶことにした。

using directiveは、名前空間を、あるスコープの中に持ち込む。

namespace A
{
    typedef int foo ;
    typedef int bar ;
}

// Using directiveはグローバルに書ける。
using namespace A ;

// 関数の中に書ける。
void f()
{
    using namespace A ;
    foo a ; bar b ;
}

// ローカルスコープの中に書ける。
void g()
{

    {
        using namespace A ;
     //範囲、ここまで。  
    }
}

//名前が衝突すると曖昧、どちらの名前も対等に扱われるから。
typedef int foo ;
void h()
{
    using namespace A ;
    foo a ;// Error
}

一方、using declarationはというと、名前を宣言する

namespace A
{
    typedef int foo ;
    typedef int bar ;
}

// 宣言できる所ならどこでも。
using A::foo ;

// クラスの中でも
struct S
{
    using A::foo ;
}

// 関数の中もよし
void f()
{
    using A::foo ;
}


// 名前が衝突した場合、優先される。
typedef char foo ;

void g()
{
    using A::foo ;
   foo a ; // int 
}

そんなわけで、using directiveをユーザー定義オペレーターに使うと問題があるかもしれない。

たとえば、ある処理系が、グローバル名前空間に、_a という独自のリテラルオペレーターを持っていたとする。これは、あり得る話であり、規格準拠でもある。(アンダースコアひとつで始まる名前は、グローバル名前空間において、処理系の実装のために予約されている。)

// 処理系によってあらかじめ用意されているユーザー定義リテラル、_a
int operator "" _a(char *) ;


namespace A
{
    int operator "" _a (char *) ;
}

void f()
{
   // このコード自体はwell-formedであるが、
    using namespace A ;

    int x = "hello,world!"_a ; // Error! どちらの_aなのか曖昧。
}

using directiveで導入される名前は、対等に扱われるので、using directive自体を使うことは問題がないのだが、実際にその衝突している名前を使う際に、曖昧になってしまう。

一方、using declarationならば、問題がない。

// 処理系によってあらかじめ用意されているユーザー定義リテラル、_a
int operator "" _a(char *) ;


namespace A
{
    int operator "" _a (char *) ;
}

void f()
{
    using A::operator "" _a ;

    int x = "hello,world!"_a ; // OK. A::operator "" _aが優先される。
}

なるほど、そうなると、安全を期すためには、using declarationを使うしかない。ユーザーの負担を和らげ、また単純なミスを防ぐためには、ライブラリ側でプリプロセッサのマクロを提供するしかない。已んぬる哉。

果たして、ユーザー定義リテラルは必要なのだろうか。現在、メジャーなコンパイラはどれも、アンダースコアから始まる一連の予約語をユーザーが使用したとしても、エラーを出さない。なぜならば、已に書かれたコードをぶち壊してしまう可能性があるからだ。ユーザー定義リテラルには、互換性の問題はないから、ユーザー定義リテラルの場合だけエラーにする事もできるが、果たしてすべてのコンパイラが、それほど順法意識が高いだろうかというと、疑問である。

最悪なのは、まず初めにユーザー定義リテラルを正式にサポートしたC++0xコンパイラが、この辺の予約語やアンダースコアに関する問題を一切無視してコンパイルを通す実装にしてしまった結果、アンダースコアを用いないリテラルオペレーターのコードが、世に広まり、後の規格改定で、組み込みのリテラルを増やす際に、影響を及ぼすと言うことだ。

奇妙な夢

三時間ほど昼寝をしてしまった。とても奇妙でリアルな夢を見たので、明惠には及ばないが、書いておくことにする

私は、どこかの動画サイトで、動画を見ていた。その動画では、どこかの家々が映されていた。Monty PythonのJohn Cleeseにそっくりの声が聞こえた。

"In this picture, there is one lady who will perform Full Frontal Nudity."
"We can not see where she is. Where are you?"
ある家の窓から、一人の夫人が裸で上半身をだす。(大勢の笑い声)
(場面が変わり、多くのマンションを屋上から移しているような映像になる)
"Here, another couple who will perform Full Frontal Nudity. we can not see where they are, but we can soon find out"
(全裸の人間が二人、マンションの窓から落下、大勢の笑い声)
女性の叫び声:"John! John! Full Frontal Nudity is over! Do you hear me. It's over!"
Johnそっくりの声:"Here... We have..."

よく分からないが、面白い動画だ。落としておこうと、そのサイトのソースを表示させたところで、こんどは私の方の場面が変わった。なぜか、私はどこかの古本屋にいて、薄汚れた本の表紙を眺めている所だった。いかにもインチキ臭い店主が、隣で何か独り言を言っていた。その古本屋に団体客がいて、「本を買うために、我々はラクダを売るべきだ」ということの是非を議論していた。

また場面が変わった。私は廃墟の屋上から屋上へと、ゲームの主人公のように飛び移っていた。私は、あきらかに非現実的な跳躍力を持っていたが、何故かとてもリアルに感じられた。

ここで、目が覚めた。一体何故こんな夢を見たのか分からない。この夢を精神分析に使っても、ろくな結果は得られないだろうと思われる。

ただ、覚えがないわけでもない。なぜなら、私はMonty Pythonが好きで、毎日のように観ているし、上記の夢の中の動画は、How not to be seen という有名なスケッチに似ている。また、Full Frontal Nudityといえば、Monty Pythonのスケッチの中でも、いくつかネタにされている。

また、古本屋については、私はしょっちゅう行っては、何か掘り出し物を探しているので、夢に出てきてもおかしくはない。

最後のゲームのようなアクションについては、たぶん、今朝これを観たからだろう。
西川善司の3Dゲームファンのための「E3 2009」グラフィックス講座 今期注目の3Dゲームグラフィックスはこれだ! -GAME Watch

漢文の複雑さ

どうも、宋代、唐代の漢文となると、やたらと技巧にこり出して、複雑で理解しにくくなっているような気がする。また複雑であるが故に、矛盾や非論理的な記述が目に付きやすい。複雑化させたあげくに、肝心の中身まで粗末になっているとあれば、救いようがないと思うのだが、いいのだろうか。

2009-06-07

ジャイロスコープの効果が実際に見れる動画

こいつはすばらしい。

ユーザー定義リテラルの問題に対するふたつの解決案

ユーザー定義リテラルの問題点

ひとつ、グローバル名前空間に定義できないこと。
ひとつ、識別子はかならずアンダースコアひとつから始まらなければならないこと。
ひとつ、リテラルオペレーターを使うローカルなスコープの中で、using declarationをしなければ、本来の意図通りの文法で使えないこと。

およそ物事を設計するにあたって重要なのは、「ユーザーはどうしようもないバカである」という前提に立つ事だ。単なるユーザーに専門知識を期待してはいけないのはもちろんのこと、ユーザーはマヌケなことでも、それが出来るならば、する可能性がある。

だから、グローバル名前空間にユーザー定義リテラルを書くプログラマもいるだろうし、識別子をアンダースコアで始めないプログラマもいるはずだ。現に、C++03において、名前の衝突を防ぐためと称して、グローバル名前空間で、識別子をアンダースコアひとつで始めたり、さらにはアンダースコアふたつで始めたりするプログラマがいる。たとえ規格は未定義としていたとしても、そういうマヌケはいる。そこでどうするか。

ユーザー定義リテラルを規格から取り除く

これは最も簡単な解決方法。最初からユーザー定義リテラルなど存在しなければ、そんなマヌケなコードなど書かれることはない。

ill-formedにする

グローバル名前空間でのユーザー定義リテラルの定義と、アンダースコアひとつから始めない識別子のユーザー定義リテラルを、明確にill-formedにして、コンパイルエラーにする。コンパイルが通らなければ、いかにアホなプログラマでも、間違ったコードを書くことはない。ユーザー定義リテラルに関しては、コンパイルエラーにしても、互換性の問題はない。問題は、コンパイラベンダーが規格を正しく実装することは思えないことだが。

私としては、ユーザー定義リテラルを規格から取り除くほうが簡単だと思うのだが。

ユーザー定義リテラルのRaison d'êtreがますます分からなくなってきた

リテラルオペレーターは、必ず名前空間の中で定義しなければならない。さらに、使う場合は、using declarationするのが一般となるだろう。なぜなら、誰も以下のように書きたくはないからだ。

namespace foo
{
    int operator "" _bar (char *) ;
}

void f()
{
    auto x = foo::operator "" _bar("hello,world!") ;
}

もはや、ユーザー定義リテラルである必然性がない。普通の関数でいい。そこで、以下のようにする。

void f()
{
    using foo::operator "" _bar ;

    auto x = "hello,world!"_bar ;
}

実際には、複数のリテラルオペレーターを使いたいだろうし、ライブラリ側で、一度にすべてのusing declarationをしてくれる、プリプロセッサのマクロを提供するのが一般的となるだろう。しかし、そこまでして使いたいだろうか。ユーザー定義リテラルの本来の面目は、わかりやすいシンタックスシュガーとなることではなかったのか。関数ではなく、リテラルとして自前のクラスの値が記述できれば、分かりやすいコードになるというものではなかったのか。それが、ユーザー定義リテラルを使うには、そのまさに使わんとするローカルスコープ内で、おまじないのようなusing declarationが必要とあっては、一体誰が能く使うというのだろう。

偉い人の考えることは分からない。

ユーザー定義オペレーターの正しい使用方法

ユーザ定義リテラルまとめ - xyuyuxの日記

よくみたら、ちゃんと規格に明言してあったらしい。

A declaration whose declarator-id is a literal-operator-id shall be a declaration of a namespace-scope function or function template (it could be a friend function (11.4)), an explicit instantiation or specialization of a function template, or a using-declaration (7.3.3). A function declared with a literal-operator-id is a literal operator. A function template declared with a literal-operator-id is a literal operator template.

13.5.8, p2

よって、グローバル名前空間に定義されているリテラルオペレーターは規格に違反している。何らかの名前空間の中で定義しなければならない。

しかも、using directiveは使えず、using declarationを使わなければならない。

namespace foo 
{
int operator "" _bar( const char*, std::size_t ) ;
}

void f()
{
    using foo::operator "" _bar ;

    auto x = "hello,world!"_bar ;
}

using declarationしか使えないというのは、少々問題がある。例えば、あるライブラリが100個のリテラルオペレーターを提供している場合、一体ライブラリのユーザーはどうやって、それを使えばいいのか。合法的で、しかも間違いを起こさない簡単な方法は、プリプロセッサを使うというものしか思いつかない。

// UsingLiteralOperator.h

#define LIBRARY_USING_LITERAL_OPERATOR() \
using lib::operator "" _hoge ;\
using lib::operator "" _hage ;\
//以下98個の同様な宣言


// user.cpp

#include < UsingLiteralOperatorHelper.h >

void f()
{
// 使いたいスコープの中でこのマクロを使う
LIBRARY_USING_LITERAL_OPERATOR()

//あとはご自由に。

}

あるいは

// UsingLiteralOperator.h

using lib::operator "" _hoge ;
using lib::operator "" _hage ;
//以下98個の同様な宣言


// user.cpp

void f()
{
// 使いたいスコープの中で#includeする
#include < UsingLiteralOperator.h >

// あとはご自由に。
}

どっちにしろ、あまり使いたくない。それに、いまさら使用に当たってプリプロセッサが事実上必須な言語仕様というのは、どうなんだろう。

2009-06-06

来週のWindowsアップデートパッチは全部で十件

Microsoft Security Bulletin Advance Notification for June 2009

ただし、Vistaのアップデートは四件。具体的な日付は、いつもの如く、日本時間では第二週の水曜日

なんでも、これほど大量のパッチが一度にでるのは、2008年10月以来らしい。

2009-06-05

chromeのvideo要素の実装が不安定すぎる

とにかく不安定すぎる。すぐにChromeのプロセスがフリーズする。

君子遠庖厨

齊宣王問曰、齊桓晉文之事可得聞乎、孟子對曰、仲尼之徒、無道桓文之事者、是以後世無傳焉、臣未之聞也、無以則王乎、曰、德何如則可以王矣、曰、保民而王、莫之能禦也、曰、若寡人者、可以保民乎哉、曰、可、曰、何由知吾可也、曰、臣聞之胡齕、曰、王坐於堂上、有牽牛而過堂下者、王見之、曰、牛何之、對曰、將以釁鐘、王曰、舍之、吾不忍其觳觫若無罪而就死地、對曰、然則廢釁鐘與、曰、何可廢也、以羊易之、不識有諸、曰、有之、曰、是心足以王矣、百姓皆以王為愛也、臣固知王之不忍也、王曰、然、誠有百姓者、齊國雖褊小、吾何愛一牛、即不忍其觳觫若無罪而就死地、故以羊易之也、曰、王無異於百姓之以王為愛也、以小易大、彼惡知之、王若隱其無罪而就死地、則牛羊何擇焉、王笑曰、是誠何心哉、我非愛其財而易之以羊也、宜乎百姓之謂我愛也、曰、無傷也、是乃仁術也、見牛未見羊也、君子之於禽獸也、見其生、不忍見其死、聞其聲、不忍食其肉、是以君子遠庖廚也

孟子、梁惠王上

ここからとってきて、整形したのだが、どうも中国人の解釈は間違っているんじゃないかと思う。変な所で区切ったりしている。

だいぶ難しかったので、わかりにくい所を解説する。

齊桓晉文之事:齊の桓公と晉の文公の事
この両君主は、いずれも武力で国を支配した者として名が高い。齊の宣王は、武力に関心があったので、この二人のことを聞いた。

仲尼之徒云々
儒学者は、武力による支配を好まず、仁徳、王道による支配を良しとしているので、孟子は知らずと答えた。

無以則王乎:やむなくんば則ち王か
以は已と同じ音なので、代わりに使われている。この王は、人としての王ではなく、国を治める道としての王道のこと。孟子は武力について答えることができないので、代わりに王道についてこたえましょうか、と言っている。

莫之能禦也:これを能くとどむる莫きなり
禦は止と同じ意味。述語と目的語が逆転しているのは、目的語が代名詞で、しかも否定文であるから。

將以釁鐘:将に以て鐘を釁せんとす
新しい鐘には、牛を殺して、その血を塗るという儀式がある。

舍之:これをおけ
舍は捨を簡略化したものらしい。それをするな、程度の意味か。

觳觫:こくそくとして
これは二字の母音の発音を重ねる畳韻。意味は、こそこそ、おろおろ、など、恐れる様。

百姓皆以王為愛也:百姓皆以て王は愛しむと為すなり
ここで、愛は惜という意味である。則ち、「臣民は、王は吝嗇で牛を殺すのがもったいないから羊に変えさせたと思っている」という意味である。

隱:いたむ、あわれむ

中島端は正しかった

CNN, BBC and AFP reporters accosted by umbrella-wielding "undercover" police at Beijing's Tiananmen Square [UPDATED] - Shanghaiist

未だにこんなことやっている国だ。中島端は正しかったといわざるを得ない。

足利事件の元県警刑事部長のブログ

http://blog.goo.ne.jp/moririn317
魚拓

炎上中。

「君子は危うきに近寄らず」というから、栃木には行きたくないなぁ。まあ、この言葉の本来の意味は、誤解されるようなことを避けるという意味なのだけれど、礼状もなしで部屋に踏み込まれて、エロビデオがあったために疑われて逮捕なんてことが行われている栃木のことだからなぁ。

ところで、「君子は危うきに近寄らず」の原文が、いまいち思いつかない。「君子近寄危」というのは、どうも変な気がする。出典を探したが、どうも出展と呼べるものは無いらしい。

Chromeのvideoサポートのまとめ 付audioの解説

まず、HTML5のvideoから説明する。これは、単純にvideoなるelementを使う。説明するよりも、サンプルコードをみせた方が早い。

<video width="640" height="480" controls="controls" poster="poster.png" src="video.mp4" />

例えば、上のようになる。説明が必要ないぐらい簡単だと思う。widthやheightは言わずもがなだし、controls属性を指定した場合は、動画を再生を制御するコントロールを表示することをブラウザに指示する。posterは、動画を再生を始めていない時に、まず表示しておく画像へのURLだ。srcが実際の動画へのURLになる。

Chromeは、デコーダーとして、ffmpegを利用しているので、ほとんどの動画のコンテナ、コーデックが再生できる。現在、すこしstabilityに問題があるが、これはDev版だからで、すぐにまともになるはずだと信じている。

ところで、Chromeはまだサポートしていないが、HTML5には、audioもある。これはvideoとほとんど変わらないが、widthやheightなどの属性がなくなっている。どうしても指定したい場合は、style属性で指定することになるだろう。

video要素のまともに使えるブラウザが、ついにでたわけだが。

現在、このブログに貼ってあるほとんどの動画は、JW FLV Media Playerを用いている。しかも、以前互換性をぶちこわすというふざけた変更があったので、用心のために、SWFObjectの外にも、さらに自前のJavascriptを使って書き換えている。以下のコードを使っている。

    <script type='text/javascript'>
      function player(id, width, height, file, image)
      {
        swfobject.embedSWF("player.swf", id, String(width), String(height+20), "9.0.0", null, 
        {//flashvars
          volume: "100",
          showdownload : "true",
          type : "video",
          fullscreen : "true",
          image : image,
          file : file,
          link : file
        },
        {//params
          allowscriptaccess : "always",
          allowfullscreen : "true",
          quality: "best",
          wmode: "direct"
        } ) ;
      }
    </script>

このようにしておけば、将来の変更にも十分耐えることができる。実際、これを、以下のように変更すれば、HTML5のvideo elementに、今すぐ変更できる。しかも、実際の記事は書き換えなくて良い。

<script type='text/javascript'>
function player(id, width, height, file, image)
{

    var v = document.createElement("video");
    v.setAttribute("width", String(width));
    v.setAttribute("height", String(height));
    v.setAttribute("controls", "controls");
    v.setAttribute("poster", image);
    v.setAttribute("src", file);
        
    var n = document.getElementById(id);
    n.parentNode.replaceChild(v, n);

}
</script>

問題は、現在、Chromeしかまともにvideo要素をサポートしていないことだ。さてどうしよう。

Chromeのvideo elementが動いた!

追記:Chromeがあまりに不安定になるので、まともになるまでしばらくコメントアウトすることにする。

こいつはすばらしい。

デコーダーにはffmpegを利用しているので、大抵のコンテナ、コーデックは動くはずだ。ただ気になるのが、HE-AACをHE-AACとして、正しく再生できているのか気になる。

まだどうも不安定だ。それに描画にGPUを利用していないのも、Flashに劣る。

VC10のgs++

Get Microsoft Silverlight

2009-06-04

麻生は首相の器じゃないな

麻生首相、可視化で冤罪減るとは感じない(産経新聞) - Yahoo!ニュース

 麻生太郎首相は4日夜、DNA再鑑定で受刑者が釈放された足利事件に関連し、取り調べの可視化について「可視化すれば直ちに冤罪(えんざい)が減るという感じがありません」と述べた。首相官邸で記者団の質問に答えた。

 ぶら下がり取材の詳細は以下の通り。

【足利事件】

 --(平成2年の足利事件で殺人罪などで服役していた元幼稚園バス運転手の)菅家利和さん(62)が今日、(DNA再鑑定の結果)釈放されました。再審が始まる前の釈放というのは極めて異例だが、首相の受け止めを

 「再審請求に関する、いわゆる司法手続きってのは今から開始されるんだと思いますけれども、私の知ってる範囲でこれは極めて異例っていうけど、前例はないと思いますけどね。まあいずれにしても無実の罪で17年服役してたっていうのは、こういったようなことはあっちゃいかん。これはつくづくそう思いますね」

 --似たようなケースがないとも言い切れない状態の中で、日本では再審請求が認められるのは非常にレアケースだが

 「そうですね。今回の場合はDNAの鑑定っていうのが大きな決め手になったんだと思いますけども、昔のDNA鑑定の、いわゆる科学的なレベルと今のレベルとは全然、倍率がまったく違うことになってるんで、そういったケースもあるかと思いますが、これ一概に一般論として答えるのは難しいです」

 --この件を受けて、冤罪防止のために、さらなる取り調べの可視化を求める議論が強まると思うが、首相の考えは

 「可視化にしたからといって、途端にそれがよくなるという感じはありません」

 --そうは言っても、無実の人が捕まって刑に服することはあってはならない

 「それ、今、答えた通りです」

 --そういった国家のあり方を考える上で…

 「国家のあり方ってどういう意味ですか」

 --冤罪が起きない国にするために可視化は必要だと思わないか

 「ぼくは基本的には一概に可視化すれば直ちに冤罪が減るという感じがありません」

 --杉村太蔵衆院議員が…

 (秘書官「終わりま~す」)

こりゃダメだ。

中島敦はどうやってあんな美文を書くことが出来たのだろう

アペママの独裁者テムビノクは今、どうしているかと思う。王冠の代りにヘルメット帽をかぶり、スカアトの様な短袴を着け、欧羅巴式の脚絆を巻いた、この南海のグスターフ・アドルフは大変に珍しいもの好きで、赤道直下の彼の倉庫にはストーヴがしこたま買込まれていた。彼は白人を三通りに区別していた。「余を少しく欺した者」「余を相当に欺した者」「余を余りにも酷く欺した者」。私の帆船が彼の島を立去る時、豪毅朴直な此の独裁者は、殆ど涙を浮かべて、「彼を少しも欺さなかった」私の為に、訣別の歌をうたった。彼は其の島で唯一人の吟遊詩人でもあったのだから。

中島敦著、光と風と夢

私は告白する。私は中島敦の美文を、さらに引用しようとして、思いとどまった。中島敦の文章は、いうまでもなく、すべてすばらしいので、美文のみ引用するというのは、畢竟、中島敦の全著作を引用するのに他ならぬのだから。

荻生徂徠は偉かった

論語を述而まで読み終えた。読んで、理解して、書写してという学び方をしているので、かなり時間がかかる。

思うに、荻生徂徠は偉かったのだなぁ。朱子学的解釈のなんとアホくさいことか。金があったら、荻生徂徠全集を買いそろえたいものだ。

ところで、

子曰、若聖與仁、則吾豈敢、抑為之不厭、誨人不倦、則可謂云爾已矣、公西華曰、正唯弟子不能學也。

赤字の部分の意味が取りづらかったが、おそらくは、「謂云」や「爾已」は、同義語を重ねた言葉なのだろう。だから、「則可謂之已矣」という意味なのだろう。ここで、之とはその上の言葉を指す。

2009-06-03

中島敦著、光と風と夢

中島敦の「光と風と夢」を読んだ。いままで、読もう読もうとは思っていたが、印刷された本が手に入らないため、読む気になれなかったのだ。というのも、96DPIのディスプレイに、日本語は複雑すぎるからだ。

結局、印刷された光と風と夢は手に入りそうにないので、青空文庫のものを読んだ。

内容は、ジキルとハイドを書いた、ロバート・ルイス・スティーヴンソンの、サモアでの生活記である。実に興味深い。

さて、読み終わって、つくづく思った。どう考えても、これが芥川賞を逃したのは思えぬ。中島敦の文章は、どれも第一流に属するものであることは疑いがない。こんなすばらしい文章を評価できずして、一体芥川賞の審査員達は何を読んでいたというのだ。

芥川賞、なんと質の低い賞であることか。中島敦も太宰治も村上春樹も評価できずして、一体なんの面目があるというのか。塵芥川賞とでも改名したほうがいいだろう。

思うに、中島敦の作品は、常に死というものへの覚悟があるように思う。これは、中島敦自身、病弱であったことも、その理由のうちだろう。果たして、死への覚悟があれば、よい小説を書けるのだろうか。ニーチェが熱狂的な読者を持っていることから見ても、これは正しいように思われる。中江兆民の、続一年半も、たしかに優れた文章だった。

然るに、私はいささかの死ぬべき要因をも持ち合わせていない。この二ヶ月運動をしているので、かつて無いほどの健康を感じている。死の実感が無いものに、何で能く覚悟などできようか。

なんだか最近、いたるところでvideo要素の宣伝を見るけれど

Dailymotion Blog » Archive du blog » Watch Video…without Flash

はっきり言う。Ogg/Theoraは使えない。画質がH.264と比べて悪すぎるのだ。オープンとかフリーなのは確かにすばらしいが、実力が伴っていなければ、どうしようもない。(まあ、画質を上げたくても、馬鹿げた明白とすら思えるような特許のせいで、その技術が使えないというのもあるんだろうけどね)

しかし、いまだにH.264の恩恵に浴していない情報弱者は何を考えているんだろう。Xvidのほうがすばらしいとか、噴飯ものの思い込みで発言しているのを見ると、笑うしかない。

VS2010のsquiggleについて

Visual C++ Team Blog : C++ Gets Squiggles!

Visual Studio 2010のインテリセンスは、コンパイラレベルのsyntax上、及びsemantic上のエラーを、コードを編集している際にすら、表示できる。

エラーは、波打った下線として、その箇所に表示される。これをsquiggleと呼ぶ。squiggleの上にマウスカーソルを合わせると、エラーメッセージが表示される。また、エラーリストウインドウにも、表示される。squiggleは、編集中のコードのエラーを見るのに都合が良く、エラーリストウインドウは、現在の translation unit のエラーを見るのに最適である。これらはすべて、ビルドせずに見ることができる。

機能の設計

この機能を設計するにあたって、ふたつの事を考慮した。ひとつは、当然ながらプロダクティビティである。ビルドを待たずにエラーを直せるのは、実に便利で、時間の節約になる。また、インテリセンスが動かないという問題にも対処したかった。というのも、インテリセンスとは、ユーザーからしてみればブラックボックスなのだ。大抵うまく動いてくれる。しかし、動かない時、その問題が分からないと言うことだ。インテリセンスはその問題を表示できるようになったので、ユーザーはエラーを直すか、プロジェクトの設定項目を見直すかできる。

この機能を設計するにあたって、ひとつ決めなければならないことがあった。どのくらいの頻度で、編集中のコードのエラー表示を更新するかと言うことだ。仮に頻度が低ければ、大量のエラーで埋もれてしまい、悲惨なことになる。しかし、高頻度で更新を行えば、やはりそれも、悲惨なことになる。たとえば、、"vector"と入力している最中に、"vect"という部分にsquiggleを表示してしまうだろう。それに、バックグラウンドのパースにかまけて、CPUを浪費したくはない。

いいバランスとは、編集後やスクロール後のアイドル時に一秒間待つというものだという結論に達した。「アイドル」とは、キーをタイプせず、別の場所にスクロールもしない状態のことだ。

また、編集後に作られた新しいエラーと、既存のエラーをどうするかという問題に関して、いくつかの設計を試みた。例えば、ひとつの設計として、編集後は、すべてのsquiggleを、即座に消去して、新しいエラーが判明次第、再描画するというものがあった。また、この派生版として、編集しているコードの箇所から、下部のエラーだけ消去するという設計も試みた。(およそ、編集後のコードが及ぼす影響としては、まずそのコードから下であろうし)。この設計は、古いエラーを見ずに済むという利点があった。しかし、ユーザビリティのテストで、いらつく頻繁なちらつきが起こることが分かった。さらに、エラーが消えたのが、修正されたのか、それともアップデート中だから消えたのかということが分かりづらいという欠点もあった。採用された設計は、既存のsquiggleは、編集後もそのまま残しておき、新しいエラーが判明したら、差し替えるという手法になった。アップデートは非常に早いので、この方法はうまくいった。

技術的な問題

この機能の技術的な問題としては、高速でなければならないということだ。ご存じのように、巨大なC++のプロジェクトをビルドするには、何時間もかかる。この問題を解決するために、ひとつの translation unit のみに注目するという方法がとられた。translation unit とは、ひとつの .cppファイルと、そのファイルがinclude するヘッダー群である。しかしそれでも、squiggleのようなリアルタイム・コンパイルを実現するためには、遅すぎた。

パフォーマンスを上げるため、インクリメンタルなパース技法を用いて、パースするコードを最小に抑えるようにした。これによって、実際のビルドにかかる時間より、すばやくコードをパースできる。実際、ひとつの.cppファイルをコンパイルするよりも早くパースできる。アイディアとしては簡単だ。しかし、C++のような、context-sensitiveな言語で行うのは、じつに厄介だった。

ファイルを開くと、global symbol tableを構築するのに必要なだけのコードをパースし、local symbolしか付け加えることのない、多くのコードはスキップする(例えば、関数内のコードだとか)。symbol tableを構築したならば、スキップしたコードを、オンデマンドでlazilyにパースする。例えば、関数内は、実際に画面上で見た時にしかパースしない。もし、ある関数内のコードを変更したならば、その関数ひとつだけ再パースできる。もちろん、すでに言及したように、これらはすべて、アイドル時に行われる。このパースの技法は、高速で役立つエラーメッセージを、巨大で複雑なコードベースを編集していても提供できるだろう。

External build systemsは省略。原文を参照されたし。

この機能を実装するのは楽しい事であった。特に、ドッグフードを食す(訳注:自社製品を実際に自分で使うという意味のMS社内用語)のは格別だった。わざわざ毎回ビルドしなくてもいいというのは実にすばらしい。Beta 1で、この機能を試せる。

十年前のコンピューターには、ここまでの処理能力はなかった。それを考えると、数十年後は、ビルドなんて意識しないプログラミング環境になっているだろうか。アイドル時に常にフルビルドを試みても、全く差し支えないほどの処理能力になっていれば、できるはずだ。

Web上のすばらしい3Dコンテンツの例

http://ecodazoo.com/

GoogleのO3Dのニュースを見た時、そもそも、Webに3Dは必要かという根本的な疑問があったが、なるほど、これはすごいし面白い。これほどのクオリティならば、Webに3Dが必要だというのも頷ける話だ。

2009-06-02

Chromeのサンドボックス実装の移植

Chromium Blog: Google Chrome, Sandboxing, and Mac OS X

Chromeのサンドボックスを、他のプラットフォームに移植しようとしているが、Linuxについては、難航しているらしい。というのも、サンドボックスというのは、単にforkすればそれでいいというわけではない。ページを描画するプロセスが、ローカル上のファイルやネットワークなどの機能を使う権限がない、というのが重要だ。しかし、Linuxには、それを実現するためのAPIが複数あり、しかも、各ディストロごとに、どのAPIをサポートしているのか異なるという、実に面倒な現状がある。オープンソースの一つの弊害は、これだと思う。

参考:Coding Horror: Oh Yeah? Fork You!

一方、Mac OSは、ひとつしかないので、そういう問題は起こらないし、サンドボックス化のためのサポートも充実していているらしい。ただ、ドキュメント化されていない部分が多くてややこしいらしいが。

Operaを使用していると情報漏洩リスクのある人間と見なされるらしい

「私はWinny使ったことありません!」就職活動にも使える、検査証を発行するツールが登場:Enterprise:RBB TODAY (ブロードバンド情報サイト) 2009/06/02
P2Pファイル共有ソフト検査証発行 支援ツール:NetAgent Co., Ltd.

企業活動において情報漏えいは大きな問題となっており、人事採用においても、Winnyなど依存性の強い「P2Pファイル共有ソフト」(Winny・Share・Perfect Dark・LimeWire・Cabos・BitComet)を使っている人間は、情報漏えいリスクだと考える企業も増えている。

☆ P2Pファイル共有ソフトウェアの使用履歴チェック
  種類:Winny・Share・Perfect Dark・LimeWire・Cabos・BitComet(BitTorrent)

WinnyとShareは、使用そのものが限りなくグレーである。何故ならば、これらのソフトウェアは、ユーザーが意図せずに、著作権上問題のあるデータをダウンロード/アップロードしてしまう可能性がある。これらのソフトウェアの使用自体が罪に問われた判例はないが、極めてグレーと言わざるを得ない。

Perfect Darkについては詳しく知らないが、どうも調べた限りでは、Shareと同じような、分割してアップロードする機能があるように読める。すると、WinnyやShareと同じ問題をはらんでいるのだろうか。

LimeWireとCabosは、果たしてどうだろうか。この二つのソフトウェアについても、詳しくは知らないが、上記のような意図せずダウンロードアップロードという機能があるようには、少なくとも公式サイトの説明からでは、思われない。自分の意図するファイルのみをダウンロード、アップロードするソフトウェアの、使用だけを以て違法と決めつけられるだろうか。

さて、本題に入る。BitCometに至っては、理由が分からない。このソフトウェアは、BitTorrent/HTTP/FTPプロトコルを実装している、いわゆるダウンローダーと呼ばれる種類のソフトウェアであるはずだ。BitTorrentプロトコルには、上記の意図せずダウンロード、アップロードといった落とし穴は存在しないし、HTTPやFTPプロトコルに至っては、その違法性のないことは言うまでもないことだ。

実際、一時期乱立した感のある、数あるP2P技術を利用したソフトウェアの中で、もっともまともなのは、BitTorrentプロトコルであろう。BitTorrentプロトコルは、巨大なサイズのデータの配布において、じつに効率的だ。だからこそ、各種LinuxのディストリのISOイメージ配布にも、BitTorrentプロトコルが、よく使われている。

ところで、HTTP/FTPに加えて、BitTorrentプロトコルをサポートしているブラウザが、一つ存在する。Operaだ。ご存じの通り、Operaはブラウザなので、HTTPとFTPプロトコルを、当然サポートしている。さらに、BitTorrentプロトコルをサポートしているし、Opera自体が、BitTorrentプロトコルを使って配布されてもいる。

BitCometの使用が、情報漏洩リスクのある人間だと判断される理由になるとするならば、Operaユーザーもまた、情報漏洩リスクのある人間であろう。

果たしてそうであろうか。

MSは汝をコントローラーにする

Microsoft announces "Project Natal" motion controller for Xbox 360!

Diggのタイトルが、Microsoft Makes you the controller、だったので、はて、「MSが俺のためにコントローラーを作ってくれる」という意味だろうか、いやしかし、それならもっと他に言い方があるだろうし、どう考えても、「MSは俺をコントローラーにする」だよな、と思っていたところ、文字通り後者の意味だった。

E3で今日発表されたものらしい。この手の、動画から動きを検出して、それを入力にするというのは、何年も前にデモがでているが、はたして、ご家庭で遊べるぐらいにコンパクトにして、しかもゲームに適するほどの精度が出せるのだろうか。

2009-06-01

簡体字は最悪だ

簡体字は吐き気をもよおす。

どうも訓読は無意味としか思えない

図書館から孔子家語を借りてきたが、これが、書き下し文と現代語訳しか載っていないという最悪の本だった。原文を載せろ、原文を。

以下のように書いてある。

得て聞くべきか

まあ、おそらくは「可得聞乎」なのだろうが、一体どういう訓読の仕方だろう。この「得て」と読むのは、どうも解せない。外にも、有名な訓読として、以下のものがある。

子貢曰、夫子之文章、可得而聞也、夫子之言性與天道、不可得而聞也。

子貢曰く、夫子の文章は、得て聞くべきなり。夫子の性と天道とを言うは、得て聞くべからず。

論語、公冶長

どう考えても、この得てというのは、誤読だとしか思えない。もちろん、その解釈の意味としては間違ってはいないが、得て、と読んでは、日本語として通じない。せめて、「聞くことを得べきなり」と読めば、日本語的にもわかりやすいであろうに、どうも、而は、「しこうして」と読まなければならないというような固定観念があったように思われる。私の言語的直感では、而というのは、二つの後をつなぐ、非常に緩い意味の言葉であったように思われる。やはり、漢文は訓読するべきではない。現代中国人はどのように解釈しているかというと、

子貢說:“老師的文章,可以聽得到;老師有關本性和天道的理論,不是光靠聽就能理解的。”

やはり、この方が自然だ。

何で違和感があるかといって、可がかかっているのは、得であって、聞ではないと、私の言語的直感が告げている。得がかかっているのは、聞である。つまり、「聞くことを得ることが可能である」、という意味であって、「聞くことが可能ということを得る」、では、明らかに変だ。

少年易老学難成は朱熹の作ではなかった

少年易老学難成
一寸光陰不可軽
未覚池塘春草夢
階前梧葉已秋声

上の漢詩は、日本人なら誰でも知っている有名なものである。何故ならば、国語教科書に載っているからだ。さっき、ふとこの漢詩を目にする機会があった。そこでは、題を「偶成」とし、作者を朱熹としている。

朱熹だと。あのイデオロギーを振り回し、既存の文章とカルト的な思想をごっちゃ煮にしたアホくさい学問を作り出した、あのマヌケのことか。詩の巧拙は知らず、朱熹ならば、以下のように考えるはずである。

「少年老い易く、学成り難し、か。確かにそうだ。むしろ、学成る能はずと言った方がよい。従って、知った振りをして適当に口からでまかせを言うに限る。第一、だれもまともに理解していないのだから、バレる心配はないだろう」と。

日本の国語教育はクソであるとは、常々思っていたが、まさかここまでとは思いもよらなかった。そう思って、この詩をググると、なんと、この詩の作者は、朱熹ではないという説があるそうだ。

まず、そもそも朱熹の著作や詩集の中に、この詩は存在しない。では、この詩の初出はどこかというと、明治の国語教科書である。そこでは、作者は朱熹としている。それ以前はどうかというと、なにやらおかしなことになってくる。

まず、滑稽詩文と称するものに、「寄小人」という題、作者無表記で載せられている。これは禅僧のおかしな話をまとめたもので、文脈から解釈すると、

少年老い易く、学成り難し。たしかにそうだ。だから若いうちは、勉強なんてせずに、男色に耽るべきだ

などという、とんでもない内容になってしまう。まずい。これでは、学校で全校生徒を前にして講演する際に、
「エー、漢詩に、少年老い易く、学成り難しと言いますが」
などと、切り出した日には、
「ですから、どうせ学を極めることなど、もとより不可能なわけでして、最初から学ばざるにしくはないのであります。したがって、不純異性交遊、これを大いに行うべしというわけですな。いや、何も異性に限る必要はないわけでして、事に皆さん男色をたしなみますかな。皆さん方の多くはノンケでありましょうが、是非ともホモセックスの経験をお持ちになった方がよい。かの水戸光圀公も、少年のケツを掘ることに関しては、一流だったと聞いております。つきましては、やらないか?」
と、結ばなければならない。これは由々しき事態だ。

また、更に古い書物をひもとくと、さらにさかのぼることが出来、そこでは、一般的な解釈と同じだが、ただし作者は日本人らしい。つまり、初めこの詩が作られ、それが後に、転じて、滑稽詩として用いられたのだとか。

何にせよ、この詩が朱熹の作とされている理由は、明治になって国語教科書を作る際に、当時の教科書の作成者が、どこかからか、この詩を持ってきて、教訓臭い解釈にして、その詩の高尚ならしめるために、作者を、当時最も尊敬されていた、朱子に設定したらしい。

なんともまあ。

Wolfram|Alphaのイースターエッグ

まだまだたくさんあるが、とりあえず気に入ったものを。

Hello, World!
what is your name?
what is your quest?
who is your daddy
How to program?
What do men want?
Where's Waldo?
what are you?
are you a Mac?
Where are you?
are you skynet?
are you self-aware?
can you pass a Turing test?
can u pass a Turing test?

http://www33.wolframalpha.com/input/?i=Who+is+Clark+Kent%3F
What is brain?
what came first, the chicken or the egg
How long is a piece of string?
How much power does the Flux Capacitor use?
88mph
Where do babies come from?
Wolfram Alpha isn't sure what to do with your input.
What are your easter eggs?

"What is you quest?"(汝、何をか求む)は気がつかなかった。Monty Pythonファンとしては不覚だ。全体的に、映画ネタが多い気がする。

追記:これを書いていた時点では、youを省略してuを書くことを認識できなかったのだが、今試した所、できるようになっている。うーむ。