遠州弁で書いてみるに

VIPPERな俺 : まさか方言だとは思わなかった言葉

このスレ読んで、ちょっと遠州弁を書き下してみたくなったんだに。遠州弁と言っても、俺が使ってるのは、旧浅羽町で話されてた言葉だに。今、市町村合併のあおりを受けて、もう隣の袋井市と合併してしまったので、浅羽町という町はなくなってしまったんだに。浅羽町は、田んぼとメロンハウス（メロン栽培のための温室のことだに）しかないド田舎だに。まあ、基本的には、静岡県西部で使われている一般的な方言と、あまり代わりはないと思うに。

まず特徴的なのは、語尾につく助詞だに。よく、ダニ、ダラと言われるけど、これ実は違うと思うに。ダは余計で、本当はニとラだと思うに。というのも、ダニ、ダラというのは、ニやラをとったら、普通にダで終わる日本語になるら？　もちろん、ニとラの意味はなくなってしまうけど、言葉としては問題はないら？　ダで終われない言葉の場合、ラやニが直接つくことになるに。ただし、それ単体で、「ダニ！（そうだ！）」、「ダラ？（そうでしょう？）」と使うことはあるに。

さて、ニというのは、強意断定という意味だに。意味としては、！をつけるような意味だに。ラというのは、強意疑問だに。なんでもラをつければ、疑問文になるに。これは単純に？ではなくて、強い念押しの、相手に同意を求めるような意味合いを持つ疑問だに。基本的に、この二つさえ覚えておけば、遠州弁は完璧にしゃべれるに。というのも、今の遠州弁話者の間では、もう遠州弁特有の言葉というのは、ほとんど死語になってるからだに。ラジオやテレビ（まだ当時はインターネットなんて主流じゃなかったに）の影響だと思うに。

もうひとつは、間投詞としてのハァだに。これは、「まあ」のような意味を持つに。子供はあんまり使う言葉じゃなかったに。じいさんばあさんが家にいるような子は別だけど。

あと気をつけることとしては、基本的に遠州弁ネイティブは敬語なんて話さないに。まあ、ド田舎だから敬語なんて必要なかったんだら、きっと。俺は、幼稚園の頃関西から引っ越してきたんだけど、母親が電話口に出るときは、必ず「はい、○○でございます」というので、友達から、「お前んちのおばさん、サザエさんだら、バカだら」ってバカにされてたに。今から思えば、どっちがバカかは、明白だら？　片や敬語を使える人間と、敬語の使えない辺土の土人だに。

まあ、それはともかく、せっかくだから、まだ少々は生き残っていた方言特有の単語を紹介するに。といっても、これがおかしな話で、今から紹介する二語は、小学生しか使ってなかった言葉だに。なぜか、中学生になると、みんな、全然使わなくなってたに。

ひとつは、ジーコン。これは、自転車という意味だに。なんでジーコンというのかは、よくわからないに。多分、自転車のチェーンがジーコジーコと鳴るから、ジーコンなんじゃないかと、その当時は考えてたに。

もうひとつは、ズッパ。これは、「すぐに」、という意味だに。ただ、「すぐに」、じゃ、ズッパの速さには足りないと思うに。だから、ここはソッコーと訳すほうがいいと思うに。ソッコーは全国的に知られてる言葉だら？　用例は、以下のような感じだに。

「おい、今日（学校から）帰ったら、俺んち遊びに来いよ」
「おう、ズッパで行くに」

ズッパで行くときは、たいていジーコンを使うに。ド田舎で家離れてるし。

ズッパの語源も不明なんだけど、素早く移動することを、「つっぱしる」というから、そこから来ているんじゃないかとは思うに。だとすると、ヅッパと書いた方がいいんだろうか（ここでは、あまり自身がないから、ラは使えないに）。もっとも、ヅはあまり一般的ではないから、ハァ、ズの方が自然だら。

なんで中学生になると、ズッパとジーコンを使わなくなるのかは、よく分からないに。日本全国に、子供しか使わない方言は、もっとたくさんあるんじゃないかと思うに。そういう言葉は、方言研究からも、漏れているんじゃないかと思うに。そういう言葉が消えてしまう前に、何とかして採集をするべきだと思うに。

ほんで、今京都に住んでるわけやけど、ほんま京都の言葉はわからへんねん。引っ越してきてから一年ぐらいは、ほんま苦労したわ。皆何言うてるか、さっぱり分からへんねやから。しかも、京都と大阪では言葉が違ういいよるねん。何が違うねん、何が。そんなん全然分からんわ。まあ、今はラジオ、テレビ、インターネットなどの普及で、明確な違いはどんどん薄れてきてるんやろうけど。いま書いてるこれも、ほんまの京都弁やないと思うんや。まだ京都に住んでからそんなにたってへんもん。

でもな、京都に住んでからおもたんやけど、古典って、やっぱり当時の都である、京都の発音で読まれてたんやろか。たとえば、今昔物語集には、「早ゥ」ってな言葉が頻出するんや。今の京都弁でも、「はよぅ」とかいうやろ。今の発音は、当時の発音をどのくらい残してるんやろか。

もっとも、この早ゥは、はやくしろという意味では、あまり用いられてへんねやけどな。大抵は、以前に知られていない事実が判明したときに、「早ゥ、○○ナリケル」なんて使ってるんやけど。まあでも、今の一般的な用例がないわけやない。例えば、今昔物語集の巻第二十八　金峰山別當、食毒茸不酔語第十八では、今の別當がなかなか死なないので、役職が空かず、「此ノ別當早ゥ死ネカシ」といって毒キノコを食わせる話があるんや。なかなか人間的な発想で面白いやろ。他にも、弘法大師が栗を煮るのを邪魔した修円僧都と、「互ヒニ死ネ死ネト呪詛シケリ」とあったり、古典にしては珍しく、人間味あふれる本や。読んどかな損やで。

chrome extensionのXMLHttpRequestが改良された

Chromium Blog: Chrome Extensions: Now with more powerful scripts and improved proxy management.

なんと、content scriptからクロスドメインなXMLHttpRequestができるようになった。これで、いちいちマヌケにもbackground pageを介してメッセージのやり取りをする必要はない。パフォーマンスも向上する。

この仕様は常々疑問だったのだ。background pageといえども、manifesto.jsonに指定したpermissionを無視したXMLHttpRequestはできない。それならば、content script内で、permissionを考慮したクロスドメインなXMLHttpRequestができてもしかるべきだ。何しろ、こちとらはエクステンションなのだ。

さっそく、個人的に作って使っているエクステンションを書き換えたところ、体感できるほどパフォーマンスが向上した。

ちなみに、ユーザー側の利点としては、Greasemonky用のスクリプトで、GM_xmlhttpRequestを使っているという理由で今までは動かなかったスクリプトが、chromeでも動くようになる。

Boost 1.47.0にはratioとchronoがある

Boost 1.47.0がリリースされた。

Boost Version 1.47.0

このリリースには、新たにratioとchronoが含まれている。これは、C++0xに追加された、時間と単位のライブラリである。

ドキュメントを流し読みしてみたところ、Boostのratioには、MPLのメタ関数を適用できる拡張が施されている。chronoには、プロセスやスレッドのCPU時間を得られるクロッククラスが追加されている。

面白そうな語学サイト

Verblingという、始まったばかりのWebサイトがある。これは、Chatrouletteに似ている。今現在、チャットをしたいと考えている人同士のマッチングを行うサービスだ。

Chatrouletteと違うのは、語学を目的としていることだ。つまり、英語を知っていてスペイン語を学びたい人間と、スペイン語を知っていて英語を学びたい人を結びつけるサービスである。このような学習方法を、英語では言語交換（Language exchange）という。

インターネットのおかげで、言語を学ぶのは便利になった。例えば、リーディングを学ぶのはたやすい。有名な古典で、著作権の切れているテキストは多く出回っているし、現代文ならば、どのサイトでも豊富にある。リスニングも容易い。YouTubeを始めとした、動画サイトは世にあふれている。ライティングもたやすい。チャットサービスは山ほどあるし、lang-8のような、ユーザーによる添削サイトもある。

ところが、スピーキングとなると、これがなかなかうまくいかない。確かに、Skypeを始めとした、ボイスチャットサービスは山ほどある。しかし、相手を探す方法が、今ひとつ洗練されていない。

確かに、言語交換の相手を見つけることを目的としたWebサイトはある。実際に相手は見つかる。ただし、練習をするのは難しい。というのも、相手の住んでいるタイムゾーンは様々であり、仕事なども様々であるので、お互いに都合のつく時間は、なかなか存在しない。およそ勉強というものは、勉強をしたいと思うときにするのが、一番効率がいい。ところが、その肝心の勉強ができる時間に、相手がいるとは限らない。そのため、無駄にskypeのコンタクトだけ増えていくのである。

そのため、今からすぐに、会話を開始できる人間と自動的にマッチングしてくれるサービスというのは、都合がいい。

とはいっても、Chatrouletteのようになってもらっては困る。つまり、チンコやマンコを見せつける人間はお呼びではない。はたしてこのサービスが、健全に本来の目的のみに使われてくれるのか、その辺は大いに不安である。

また、どうも今現在、英語とスペイン語のマッチングしか行っていないらしい。残念。一応、将来的にはもっと多くの言語をサポートする意志はあるようなので、覚えておこうと思う。

WebGLにおけるクロスドメイン問題

Chromium Blog: Using Cross-domain images in WebGL and Chrome 13

クロスドメインを禁止することは重要である。もしクロスドメインが完全に許されているのならば、任意のドメインのWebサイトから、閲覧者のログイン済みのGMailやTwitterなどの他のサービスにアクセスできてしまう。

これは、画像や動画といったリソースでも同様である。例えば、あるサイトは、ユーザーに応じて画像や動画を生成するかもしれない。その場合、Javascriptから画像の内容を取得できてしまうのは、セキュリティ上危険である。img要素は、クロスドメインの画像を表示できる。しかし、Javascriptから画像の内容を取得する方法はない。

img要素なら問題はないし、2Dのcanvasは、他のドメイン下の画像や動画が描画されたときは、ピクセルが得られないようになっている。

ところが、WebGLの場合は、単にピクセルを得られないようにするというのでは、不十分である。なぜならば、WebGLはシェーダーが使えるからだ。シェーダーを使って、ピクセルごとに処理時間を変えるなどすれば、リソースの内容をほぼ正確に推測できてしまう。これはまずい。

そこで、WebGLのテクスチャーとして使うリソースを、他のドメインでホストする場合は、その他のドメインのサーバーが、Cross-Origin Resource Sharingを実装しなければならない。クロスドメインは問題ないということを証明できるのは、自分ではないのだ。

IE10が条件コメントを廃止ケテーイ

HTML5 Parsing in IE10 - IEBlog - Site Home - MSDN Blogs

とうとうIE10では、Conditional Commentを廃止するようだ。よくぞ決断した。MSにとっては非常に難しいことだったに違いない。しかし、これは重要なことである。同じHTMLがすべてのブラウザーで同じように解釈されるのは当然である。条件コメントは廃止されるべきである。

しかし、IE10のためにOSをアップグレードしたいのだが、カネがない。PCもいい加減に買い換えないとまずいのだが、カネがない。C++本をさっさと書き終えて、真面目な仕事を探さなければ。

水と空気とコンテンツが無料の時代が来た

私はこれからの時代、コンテンツは無料(ただ)になると確信している。いや、これは誤解を招く言い方である。本当は、コンテンツが売れなくなるのだ。

例えば漫画だ。私は常々、最近はロクな漫画がないことを嘆いていた（ただしジョジョを除く）。しかし、今気がついてみると、私は実際には、漫画をたくさん読んでいるのである。読むべき漫画がないというのは、商業漫画の話なのだ。

pixivというWebサイトがある。これは、絵の投稿サイトである。投稿されている絵の品質は様々であるが、非常に素晴らしい絵が、毎日大量に投稿されている。絵には、漫画も含まれる。

Pixivに投稿されている漫画には、非常に面白いものもあるのだが、商業漫画たりえない理由がある。例えば絵があまりうまくなかったり、内容があまりに偏っていて、万人受けしないということである。

商業漫画は、非常にコストの掛かる商売である。漫画を印刷して全国に流通させるのは、決して安くない。そのため、出版される漫画は、売れる見込みのある漫画ばかりとなる。これには、絵のうまさという要素もあるが、もっと重要なことには、老若男女すべてに受け入れられるかという要素がある。万人受けを狙うとすれば、共通して楽しめる内容にするしかない。このため、同じ年代の漫画は、似たり寄ったりな絵になり、ストーリーも似通ったものになる。つまり、いずれも似たような凡作ばかりで、平均からかけ離れた逸作がでてこないのである。

これは、漫画というものが市民権を獲得した近年、とみにみられる傾向である。漫画の黎明期は、実験的な漫画が多かった。昔の漫画が面白いのは、このためである。今の漫画は、売るために当たり障りのない内容ばかりである。昔と比べて、絵の質は上がっているものの、内容はむしろ劣化している。

これは、東京都の表現規制を待つまでもない。赤字にならないこと、売れることを追求した、大衆迎合の結果である。これでは芸術品の生まれるわけがない。

一方、Pixivのような投稿サイトは、もともと利益にならないのだから、好きなように描く。だから、飛び抜けた作品も多い。決して万人受けはしないものの、飛び抜けた作品が生まれる可能性がある。

動画に関しても同じだ。YouTubeというWebサイトがある。これは、動画の投稿サイトである。もちろん、YouTubeには他人の著作物が違法にアップロードさされているという批判もある。しかし、大部分の動画は、オリジナルである。私のよく見る動画は、完全に合法である。特に、私の大好きな猫の動画に関しては、一日に24時間以上もの動画がアップロードされている。これは、YouTubeだけで生涯に渡る猫動画の需要を観たせることを意味する。また、オリジナルの猫のアニメーションなども多数アップロードされている。わざわざ違法にアップロードされた昨今の糞アニメなどをみる必要はないのである。

では、文章はどうか。私に言わせれば、読むべき価値のある文章は、すでに書き尽くされてしまった。例えば、私は今日、古事記を読んだ。本居宣長が古訓の復元に努めてくれたおかげで、高等教育を受けていないこの私でも、スラスラと読むことができる。また、有名所の古文は、大抵インターネット上にテキストがあるので、金はかからない。

これは、英文学でも同じである。私の最も好きな英文は、Lord Dunsanyの文章であるが、彼の著作は、すべて著作権が切れている。 好きなだけ読むが良い。

追記:今、気がついたのだが、戦時加算を考慮すると、Lord Dunsanyのほとんどの著作物は、まだ著作権が切れていないということになるのだが・・・・・・。

つまり、娯楽作品に限れば、もはやコンテンツにカネを払う価値はないと言える。何故ならば、商業作品はつまらないし、合法的に無料で楽しめる作品は、世にあふれているからだ。いい時代になったものだ。

では、娯楽以外のコンテンツはどうなのか。例えば、プログラミングの参考書はどうかというと、これもやはり、商業的なコンテンツは廃れていくのではないかと思っている。個人がやっているWebサイト上の解説では、まとまった内容とはなりにくいことは確かだ。しかしこれも、複数のサイトを横断した縦横無尽な検索によって駆逐されてしまうだろう。それに、今後プログラミングの初期学習は、comp.std.c++やStack Overflowのようなプラットフォームが主流になるはずだ。

gccのiostreamがクラッシュする件、解決

少し前から、gccのiostreamを使うとクラッシュしてしまう問題に悩まされていたが、どうやら問題が解決した。

私はgccを自前でコンパイルするのが面倒なので、コンパイル済みのバイナリを落として使っている。使っているのは、このサイトのビルドだ。

簡易なインストーラーが付属しているが、これは、単に指定したパス下にファイルを展開し、そこへのパスが、まだ環境変数に書かれていなければ、付け加えるだけである。アンインストーラーはないので、取り除くのは手動である。私は面倒なので、毎回、同じディレクトリを上書きしていた。

ところが、どうもこれがまずかったらしい。何故ダメだったかという理由はいくつか思い浮かぶが、それはもうどうでもいいことだ。とにかく、上書きしないことで問題を解決できた。

松本龍が小物すぎる

なるほど、大臣は客なのだな。

県にそれ、コンセンサス得ろよ。そうしないと我々、何もしないぞ。ん、ちゃんとやれよ。

今、後から自分は入ってきたけど、お客さんが来るときは、自分が入ってからお客さんを呼べ。いいかぁ。長幼の序が分かってる自衛隊なら、そんなことやるぞ。分かったぁ。はい。しっかりやれよぉ。

今の最後の言葉はオフレコです。いいですか、皆さん。いいですか？はい。

書いたらもう、その社は終わりだから。

潔すぎるb-mobile

koutarou666: b-mobile 980円SIMをNexus Sで使ってみた。テストしたら驚愕の事実が！

Q.下りのRTPが流れてこないが？
A.仕様で御座います。大量にパケットを使う方がいると他の方が迷惑しますので。
Q.いや、大量もなにもいきなり流れてこないんだけど。
A.未然に防いでおります。
Q.VoIPだけ選別している？
A.しておりません。下りのストリーム（RTP）全て遮断しています。
Q.そんなご無体な。
A.契約時の規約にも記載御座います。
Q.いや規約には制限する場合がございますと。
A.はい。今がその場合で御座います。
Q.ひょっとしてU300とかU400とかも全部遮断している？
A.b-mobile Fair以外は全て遮断しております。

下りのRTPはすべてブロックとは、潔すぎる。実に効果的にskypeとかYouTubeの利用を禁止しているわけだ。しかし、ちゃんと話の通るサポセン要員を用意している点は、評価できるのかもしれない。

複数のmutexが欲しい状況

複数のmutexが必要な状況を考えてみた。

// 排他的にアクセスするリソース
class exclusive_resource
{
public :
    std::vector<int> v ;
private :
    std::mutex m ;
public :
    void lock() { m.lock() ; }
    void try_lock() { m.try_lock() ; }
    void unlock() { m.unlock() ; }
} ;

exclusive_resource res1, res2 ;

void thread1()
{// res1のみを操作
    std::lock_guard< exclusive_resource > guard( res1 ) ;
    res1.v.push_back(0) ;
}

void thread2()
{// res2のみを操作
    std::lock_guard< exclusive_resource > guard( res2 ) ;
    res2.v.push_back(0) ;
}

void thread3()
{// res1, res2両方を操作
    std::lock( res1, res2 ) ; // デッドロックを回避するためstd::lockを使用すること
    // res1, res2両方を操作、実際には途中のreturnや例外に気をつけること
    res1.unlock() ; res2.unlock() ;
}

void thread4()
{// thread3と同じく、res1, res2の両方を操作、thread3とは異なる処理
    std::lock( res1, res2 ) ; // デッドロックを回避するためstd::lockを使用すること
    // res1, res2両方を操作、実際には途中のreturnや例外に気をつけること
    res1.unlock() ; res2.unlock() ;
}

今、異なるスレッド間で操作したいオブジェクトが複数あるとする。しかし、常に全オブジェクトを操作する必要はないものとする。とすれば、この複数のオブジェクトを、単一のmutexで排他的にアクセスするのは、非効率的である。したがって、アクセスしたい単位ごとに、別々のmutexを用意するのは当然である。

しかしまた、ある状況では、複数の単位に、同時にアクセスしたい場合もあるとする。この場合、複数のmutexをlockしなければならない。しかし、普通に一つづつlockしたのでは、デッドロックに陥る可能性がある。このため、デッドロックを避けるように気をつけつつロックしなければならない。

std::lockは、lock(), try_lock(), unlock()を組み合わせた一連の呼び出しにより、デッドロックに陥らない方法で、すべてのLockable要求を満たす型のオブジェクトをロックしてくれる。

まとめとしては、複数のmutexを同時にlockする際には、デッドロックを避けるために、std::lockを使うべきである。

Monty Pythonの元メンバー、Chapmanの映画を作るために再結成

BBC News - Monty Python members reunite for Graham Chapman film

そうめんと豆腐

この数日、そうめんと豆腐とネギで生きている。あまりにも暑くて食欲がわかないのだ。腹は減っているのに物が食べられない。

multiple_lock_guardとか欲しいよね

複数のmutexに対するlock_guardが欲しいと思ったので書いてみた。動くかどうかテストしていない。

template < int I >
struct unlock
{
    template < typename T >
    void apply( T & t )
    {
        unlock< I - 1 >::apply( t ) ;
        std::get<I>(t)->unlock() ;
    }
} ;

template <>
struct unlock<0>
{
    template < typename T >
    void apply( T & t )
    {
        std::get<0>(t)->unlock() ;
    }    
} ;

template < typename ... Types >
class multiple_lock_guard
{
public :
    typedef std::tuple< Types *... > type ;
    
    multiple_lock_guard( Types & ... args )
        : m( &args... )
    {
        std::lock( args... ) ;
    }

    ~multiple_lock_guard()
    {
        unlock< sizeof...(Types) - 1 >::apply( m ) ;
    }

    multiple_lock_guard( multiple_lock_guard const & ) = delete ;
    multiple_lock_guard & operator = ( multiple_lock_guard const & ) = delete ;

private :
    type m ;
} ;

こういうふうに使う。

std::mutex m1, m2, m3 ;

int main()
{
    multiple_lock_guard< std::mutex, std::mutex, std::mutex >
        guard( m1, m2, m3 ) ;
} 

追記、コピーコンストラクタ―と代入演算子のdeleteを忘れていた。

C++0xのマルチスレッドとデータ競合が非常に難しい

「バリアー！」
「デュクシ！」
「ちょっ、お前、オレ、バリアー張ってんだから攻撃するなよなー」
「うるせー、オレのはバリアー貫通できる攻撃だっつーの」
「貫通できないバリアー！」
「貫通できないバリアーを貫通できる攻撃！」
「絶対貫通できないバリアー！」
「絶対貫通できる攻撃！」
「そんな攻撃ねーよ」
「そんなバリアーこそねーよ」
「お前、矛盾って言葉、知ってるか？」
「ああ、昔の中国人はオレの矛を持ってなかったんだな」
「ちげーし。オレのバリアーを持ってなかったんだぜ」
「真似すんなよ」
「マネスンナヨー」
「あ、きったね」
「ア、キッタネ」
「飽きたね・・・」
「そうだね・・・」

フェンスといい、メモリバリアーともいう。名前はかっこいいが、やっていることは、あるスレッドにおけるあるメモリ場所に対する変更操作を、他のスレッドから見えるようにしたり、あるいは逆に、他のスレッドでの変更操作を、このスレッドから見えるようにすることである。

これは、多くのコンパイラーで、独自にサポートされている。基本的にWindowsでプログラミングを学んできた私としては、メモリバリアーという名称の方がしっくりくるのだが、C++の規格としては、フェンスという名称になっている。

C++0xの規格を眺めていたところ、どうもC++0x規格には、非アトミック操作に対するフェンスというものが、存在しないようである。

しかし、mutexはどうなるのだろう。例えば、以下のコードが、意図通りに動くことが、規格でどのように保証されているのだろうか。

std::mutex m ;
int x ; 

void thread()
{
    std::lock_guard<std::mutex> guard(m) ;
    ++x ; // 非アトミック操作
}

int main()
{
    x = 0 ; // 初期値0

    std::thread A( thread ) ;
    std::thread B( thread ) ;

    A.join() ; B.join() ;

    std::cout << x << std::endl ; // 2であるべき
}

色々と考えたあげく、以下のように考えた。

AとBのインクリメントは、1.10 [intro.multithread] p4に書かれているように、conflictする。
AとBで行われる非アトミック操作であるインクリメントは、mutexで囲まれており、同時には起こらないし、どちらかが先に起こることは確実である。とすれば、1.10 [intro.multithread] p13に書かれている通り、先に起こった方の操作は、後続の操作に対して、visible side effectである。
AとBのインクリメントはconflictするものの、どちらかが先に起こることが保証できるため、1.10 [intro.multithread] p21のdata raceの条件には引っかからない。

LISTER: Hey, it hasn't happened, has it? It has "will have going to have happened" happened, but it hasn't actually "happened" happened yet, actually.
RIMMER: Poppycock! It will be happened; it shall be going to be happening; it will be was an event that could will have been taken place in the future. Simple as that. Your bucket's been kicked, baby.

YouTube - Red Dwarf I - Future Echoes - Part 3 of 3

復活

体調が戻ってきた。まだ少々下痢気味だが、とりあえず起きていても体が極端に疲れたりはしない。

風邪をひいたらしい

どうも体が疲れる。熱がある気がする。恐らく、明日あたり、本格的に体調を崩してしまうはずだ。

どうも昔から、季節の変わり目には、風邪をひきやすい。いつもきまって、何の予兆もなく、いきなり疲労感を感じ、数時間後に熱。仕方が無いのでそのまま寝るも、翌朝、さらに体調が悪くなっているのだ。

明日はさぞ、薄いおかゆが美味しく感じられることだろう。思うに、一番うまい食べ物は、風邪を引いた時に食べる薄い粥であると思う。

LinuxのARMサポートがカオス

Linux ARM support: A hot mess, an ugly clean-up | ITworld

LinuxのARMコードは、各メーカーが、手っ取り早く安く上げるために、やっつけ仕事で場当たり的に対応させるため、悲惨なことになっているとのこと。Linusが最近、ようやく様子をみて、「こんな調子だったら、もうこれ以上pullしねーよ」と突っぱねた。

まるで日本の携帯業界のようだ。

偽音5つ

Humans Invent | Innovation, Craftsmanship & Design

車のドアを閉めた時に発生するバタンとかガチャンという音、電気自動車の走行音、スタジアムの歓声、Skypeのボイスチャットで、無音時のかすかなノイズ、ATMがお札を出すときの音。これらは皆、偽音である。

ユーザーが車のドアを閉めた時、期待するような音がならないと、本当に閉まったのかどうか疑念が生ずる。そのため、車メーカー各社は、ドアがありそうな音を発するように、精密な設計をしている。ドアが閉まった時の音を鳴らす機構の特許も多数あるそうだ。

電気自動車は静かすぎるので逆に危険であるという観点から、それらしい走行音を発するよう義務付ける法整備が進められている。

スタジアムの歓声というのは、もちろん実際の歓声も含まれているが、実はスピーカーから流しているらしい。スピーカーから流すことによって、実際の見物客にも、歓声を出しやすくしているのだとか。

スカイプなどのボイスチャットでは、ノイズリダクションの技術を活用しているが、この技術は優れすぎていて、何も喋らない時は、完全に無音になってしまう。すると、ユーザーは、実は切断してしまったのではないかと疑念を抱く。そこで、まだつながっていることを示すために、かすかなノイズを流している。

最後は色々と議論があるようだが、ATMがお札を出すときの音は、実は偽物であるらしい。技術的に、ATMは紙幣を一瞬で出すことができるが、あたかも中でお札を動かしているような偽音をだすことによって、ユーザーをして、ATMがちゃんと仕事をしているのだという錯覚を生ぜしめるのだとか。

ナナオが4Kディスプレイを発売するそうだ

DuraVision FDH3601 | EIZO 株式会社ナナオ

大きさは36.4型で、解像度は4096x2160。画素サイズから計算すると、PPIは127、dpcmなら50ぐらいだと思われる。ちなみに肝心のお値段は288万円。とてもではないが手が出せる値段ではない。

ナナオはあの悪名高いS2411Wの定点ドット欠けを仕様だと言いはった企業だから、もう全く信用していないが、4Kパネルの製品が出てきたのは興味深い。しかし、4kとなると、120PPI程度ではもうディスプレイが巨大すぎて、一般用途にはつらい。

生きているうちに、24インチで600PPI程度のディスプレイが安く手に入るようになるといいのだが。

C++0x仕様のfriend

C++0xでは、friendに細かい変更があった。gcc 4.7では、このC++0x仕様のfriendに対応したらしい。早速確かめてみたところ、仕様通りだった。

typename-specifierが使えるようになったり、名前探索のチェックの省略のルールが変わったりしている。

詳しくは、n1791を参照。

最近の漫画

久々に、いくつかの漫画を読んでみたので、その感想を書く。

「角刈りすずめ」の連載が終わってしまったようだ。角刈りすずめとは、近代麻雀で連載されていた漫画である。毎回毎回、麻雀に死地を求める孤独な角刈り男が、期せずしてエクストリームな麻雀に出くわしてしまうギャグマンガである。

しかし、麻雀漫画がこれほど多いのは解せない。「ムダヅモ無き改革」だとか、「咲-Saki-」だとか、はては、「ひぐらしのなく頃に」から派生した、「ひぐらしの哭く頃に 雀」まである。麻雀を題材にしたギャグマンガはいくつかあれど、麻雀漫画のほとんどは、かなり真面目に麻雀を打っている作品である。登場人物が全員、テレパシーを疑うほどの通しと待ち読み能力を持っているということを除けば、至って普通のシリアスな話である。

麻雀専門の漫画雑誌があり、単行本も出版されている以上、麻雀漫画には一定の需要があるのだろう。

麻雀を考えるに、技能と運とイカサマとハッタリがモノを言うゲームである。登場人物が試行錯誤する心理描写を延々と続けていても構わないし、ド素人が名人に天和で勝ちましたという話も、ありうる話である。とすれば、お話の題材としては、悪くないのかもしれない。

しかし、最近の若者は、麻雀のルールなど知らない。実際、私も麻雀のルールは覚えられなかった。

さて、麻雀以外の漫画では、魔法陣グルグルを読んだ。この漫画は、理不尽なRPGをネタにした漫画である。連載当時はバラバラに読んでいて、通して読んだことはなかった。それも、終わりの方は全く読んでいなかった。果たして、今読んでも楽しめるものだろうかと疑問だったが、これがどうして、実に面白い。

グルグルは、キタキタおやじとかギップルを登場させたのが優れていると思う。これによって、話がシリアスにならないし、またクサくもならない。

ついでに、ドラクエ4コママンガ劇場が懐かしくなり、ブックオフで探してみたが、一冊もなかった。残念。あの伝説の、「ふんどし　お前が一番混乱しとるわ」を読みたかったのに。

古本屋の未来

C++の参考書を延々と執筆していて、ここのところ、古本屋巡回もしていなかった。ふと、一年ぶりに古本屋でもめぐろうと思い立ったので、今日は久しぶりに古本屋に行ってみた。

が、またひとつ、古本屋が潰れていた。早いもので、京都に来てからもう7年になるが、知っている古本屋が、すでに二軒も潰れている。もう、ブックオフ以外の古本屋に未来はないのだろうか。

それはともかく、8月11日から、下鴨納涼古本まつりがある。古事談や古今著聞集などが安く売っていたら購入を考えよう。

CPUの未来

ここ数カ月のBulldozer関連のニュースを読んでいて、やはり将来的に、CPUとGPUは、物理的にひとつのチップ上に実装されるのが当然になるのだろうと考えた。PC用のビデオカードというものは、今のサウンドカード程度の位置にまで落ちるだろう。つまり、確かに、組み込みのものと比べて高品質な部分もあるが、大多数のユーザーは、違いを気にしないのだ。

また、私はかつてから、GPUの使うメモリーは、CPUの使うメモリーと統一されるべきであると考えていた。そこまでいかなくても、GPU側から通常のメモリーにアクセスでき、また、仮想メモリという形で双方から同様にアクセスできるのであれば、それで十分なのかもしれない。

いずれにしても、C++の未来は明るい。

【後藤弘茂のWeekly海外ニュース】 AMDが革新的な次世代GPUアーキテクチャの概要を発表
【後藤弘茂のWeekly海外ニュース】 GPUをCPUのように扱えるFusion System ArchitectureをAMDが発表
Introducing C++ Accelerated Massive Parallelism (C++ AMP) - Visual C++ Team Blog - Site Home - MSDN Blogs

John Carmack、E3で語る

E3 2011: John Carmack talks Wii U, PlayStation Vita, and next-gen Rage - News

• Rageは正直いって開発期間が長すぎた。
• 一年前に発売日を発表したのは、納期を明確にして追い込むため。
• コンソールは十分にパワフルなので、特に制限を感じなかった。
• むしろPCは、コンソールよりはるかにスペックが高いにもかかわらず、60FPSを保証するのが難しかった。色々とオーバーヘッドが高い。IntelやnVidiaに相談したけど、フラストレーションたまるわ
• Wii Uは、ハード性能が他のプラットフォームに追いついてきたので、まあ、よさそうだね。
• Vitaはダメだろ。現時点ではスペック高いかもしれんが、発売される頃には、ひょっとしたらスマートフォンとかタブレットとかにスペックが抜かれてるかもしれんし、発売後一年や二年もたてば、やはり見劣りしてしまう。よほど移植を簡単にできるようにしないと、成功しないだろうね。

The Old New Thing: PEリソースは4バイトアラインにせよ。まあ、守らない奴もいるけど

PE resources must be 4-byte aligned, but that doesn't stop people from trying other alignments - The Old New Thing - Site Home - MSDN Blogs

PEヘッダー内のリソースは4の倍数のオフセットに格納されていなければならない。これは、アライメントに厳しい環境のためである。

まあ、どうせ守らない奴は守らないのだがね。第一、気を付けていれば、一応は動くしね。つまり、まあそりゃ、誰かx86じゃないWindows使ってる奴がリソース読み込んだら、クラッシュするだろうよ。でも、x86じゃないWindowsなんて誰が使ってんのさ？　だろ？

Windows Vista SP1では、セキュリティ上の理由のため、リソースをパースするコードに、いくつかのチェックが加えられた。ここで重要なのは、リソースにアクセスする前に、正しくアラインされているかどうかを確かめるようになったのだ。これにより、アラインの正しくないリソースを読み込んだ場合のクラッシュを防げるようになった。プログラムが任意のバージョン情報のリソースを読み込むというのは、よくあることだ。例えば、エクスプローラーはファイルプロパティを見るときや、バージョン情報のコラムを有効にした時に、バージョン情報を読み込む。したがって、正しいリソースのアライメントを保証することは、リモートDoSアタックを防ぐことになるのだ。

そしたら、バグリポートがやってきた。「プログラムXYZがインストールできなくなった」。何故ならば、そのプログラムは自分自身のバージョン情報のリソースを読み込もうとして、失敗しているからだ。その理由は、プログラムをビルドするのに使ったツールが、4の倍数ではないオフセットにリソースを配置しているからである。「おいおい、マジかよ。よしてくれよ。そんな事すりゃ、3バイト無駄になっちまうだろうがよ。以前は、リソースアライメントしなくても動いたじゃん。だからそのまま出荷したんだよ」

別の例としては、あるゲームの追加パックがインストールできなくなった。何故ならば、ゲームのバージョン情報リソースを読み込むコードが動かなくなったからだ。

いくつかのプログラムが、「アプリ名は有効なWin32アプリケーションではありません」というエラーメッセージを表示して、実行をやめるようになった。これは、初期化の途中で、自分自身のバージョン情報リソースを読み込もうとして、ERROR_BAD_EXE_FORMATで失敗しているからだ。このエラーに対応するエラーメッセージをユーザーに表示しているのである。

修正としては、アライメントのチェックを以前と同じように緩くした。厳しいチェックは、アライメント要求が厳しいアーキテクチャのみで行うようにしたのだ。これは、あるマシンではリソースが読み込めるが、他のマシンでは読み込めないというプログラムの存在を許してしまう。しかし、アライメントが正しくないデータでも問題なく読み込めるという前提で書かれたプログラムをぶち壊すよりマシだ。

珍走団と遭遇

先日、絶滅危惧種の珍走団と遭遇したので、そのことでも書こうと思う。

あの日、私は予備自衛官の射撃訓練を終えて、射場から駐屯地へ帰る途中であった。我々は、迷彩服を着用し、あの数ある自衛隊車両のうちでも有名な、三トン半のトラックの荷台の簡易なベンチに座って、ガタガタと揺られながら、道路を走っていた。

その時突然、特徴的な騒音が聞こえてきた。荷台の後ろから外を見やると、5,6台ぐらいのバイクの集団がいた。そのバイクは非常に特徴的で、エアロダイナミクスのよく効きそうな外装、無駄にでかい背もたれのようなもの、非常に変わった形のくねくねと曲がったマフラーなどを装着していた。

人も変わっていて、サングラスやマスクなどを着用していた。しかし、どう見ても年齢が若くない。中には、少なくとも四十代ではないかと思われるような人物もいた。皆、小刻みに右手を動かし、一定のリズムで騒音を発生させるという、非常に燃費によろしくない運転をしていた。

もうこんな人間は絶滅したかと思っていた。彼らは40年前からタイムスリップしてきたのだろうか。

我々は言葉を失いつつ珍走団を眺めた。珍走団の方も、我々を凝視しながら、トラックの両脇をすり抜けていった。確かに、我々は迷彩服を着用して、自衛隊車両の荷台に乗っているのだ。まあ、人目をひく姿ではある。

珍走団が過ぎ去った後で、ある曰く、「アイツら、ワシらのこと珍しそうにガン見しとったけどな。ハッキリいって、お前らの方がよっぽど珍しいやろ」

真理である。

なお、一部ノーヘルがいたものの、信号はちゃんと守っているようであった。

帰還

予備自の訓練から帰還した。

今回は、初めてⅠ型のレーションを食べた。缶に入っているものだ。感想としては、あまり食べたくない代物である。聞けば、東北に派遣されている自衛官も、当初は自衛官まで普通の食事が回らず、この缶飯ばかり食べていたらしい。ただ、数カ月そのままの体制を続けていたら、口内炎になったので、急遽、自衛官の分まで食事が回る体制を整えたらしい。我が国の、兵站をおろそかにするところは、いつまでたっても変わらないのだな。

聞説、自衛隊の災害派遣が報道されたことにより、この缶飯の知名度が上がっているそうだ。ただ、缶の見た目はともかく、中身はあまりよろしくない。

ちなみに、Ⅱ型の方は、まだ多少はおいしい。食べたければ、業務用スーパーで、もち米を使った味付け飯のレトルト品でも探すといいだろう。中身は同じだ。ただパッケージがOD色になっているだけである。

もちろん、普通に炊いた飯のほうが美味いのは、言うまでもない。

留守

5日間留守にします。

Bulldozerの情報

【後藤弘茂のWeekly海外ニュース】 AMDがBulldozerベースの次期メインストリームCPU「Trinity」を公開

Trinityでは、Bulldozerのモジュールを2個、4CPUコアに相当するコアを搭載していると見られる。それにRadeon HD 6970(Cayman)世代のGPUコアを統合したものがTrinityだと推定される。

本当に2012年にリリースされるTrinityの内蔵GPUは、Radeon HD 6970相当のパフォーマンスを持つのだろうか。そうなったら、もうGPUはvideophile（画質ヲタ）とでもなづくべき一部のヲタしか使わないマニア向けの商品に成り下がるだろう。そのような世界では、画質を上げると称して、様々な怪しげな商品が蔓延することだろう。例えば、画質を上げるDisplayPortケーブルだとか。

まあ、それは冗談にしても、GPU統合APUとビデオカードとの違いが、アンチエイリアスやテクスチャーフィルタリングの質程度のものであれば、PC用のビデオカードというものは斜陽になっていくだろう。