2011-12-30

最近のゲームのグラフィックに思う

グラフィックは、ゲームの面白さの本質ではない。しかし、やはりグラフィックは重要である。私が始めた遊んだPCゲームは、Mafiaであった。Mafiaは、当時としては素晴らしいグラフィックであり、私のGeForce 4 Ti4200で快適に動作した。

今から思うと、惜しいことをしたものだ。私はもっと早くからPCゲームに目覚めているべきだったのだ。DoomやWolfenstein 3DやDuke Nukem 3Dなどといった往年の名作ゲームが、今となっては楽しめない。もし当時、これらのゲームに触れていれば、楽しめたはずなのだ。しかし、私の最初のPCゲームはMafiaだったので、それより以前の時代のゲームを楽しめないのだ。これは実に残念なことだと思う。私はThe Elder Scrollsシリーズが好きだが、ArenaやDaggerfallは楽しめない。どちらも、今、公式に無料で提供されているゲームである。また、DOSBoxのようなx86上で動くMS-DOSエミュレーターを使えば、当時とほぼ変わらずに遊べるゲームである。それなのに楽しめない。実に惜しい。

ともかく、最近のゲームのグラフィックの流行は、スクリーンスペースのポストプロセスだろう。なにしろ、どんなシーンでも負荷が予測できる範囲なので、化石並の低スペックなコンソールでも使いやすいのだ。

SSAO(Screen Space Ambient Occlusion)

SSAOは最も有名であろうと思う。Crysis以降、多くのゲームはSSAOを採用した。nVidiaなどは、ドライバー側でSSAOを適用する機能までリリースしたのだ。また、DirectXのラッパーDLLをかませて、既存のゲームにSSAOをかける手法も開発されてきた。Depth Bufferの各ピクセルと、周囲のピクセルの差を比較して、それに応じてやや黒くするポストプロセスである。もちろん、いくらスクリーンスペースと入っても、大まじめに実装しようとするとパフォーマンス上厳しいので、大胆な手抜き方法を使う。見た目に分かりやすい結果としては、面と面が角度をつけて重なり合っているような部分が黒くなる。面白いことに、この効果は、実にうまく人間の脳を騙してくれる。SSAOを古いゲームに適用してみると、急にグラフィックの品質が大幅に向上したように感じる。

ただし、最近は、以前程SSAOが喧伝されなくなっている。代わりに、SSAOっぽい影をテクスチャに最初から書き込んでおく手法もみられる。

ポストプロセスによるアンチエリアス

具体的な名称としては、nVidiaの考案したFXAAが一番有名だが、Crysis 2で使われているSMAA: Enhanced Subpixel Morphological Antialiasingもなかなか面白い。基本的な考え方はどれも同じで、ジャギーをごまかすフィルターである。

そもそも、アンチエリアスの一番分かりやすい目的は、縁のギザギザ、つまりジャギーを目立たなくするというものである。最初に実装されたAAの手法は、目的の解像度より高い解像度で描画して、しかる後に目的の解像度までダウンスケールするというものである。これは原始的だが、最も効果的な方法である。問題は、パフォーマンスが最悪だということだ。今の最新のCPUをつかって、大昔のゲームがやっと動くというほど、パフォーマンス上の問題がある。近代的なゲームに使うことはできない。次に、MSAAというものが実装された。これは、頂点処理だけ高解像度で行い、ピクセルに落としこむ際には、目的の解像度で行うというものである。すくなくとも、ジャギーはだいぶ解消できる。問題は、これも最近のゲームに使うには、ややパフォーマンス上問題がある。

結局、やっていることはジャギーの低減なのだ。ジャギーは縁に発生する。静止画の縁を判定する方法は、大昔から研究されている。だったら、縁を判定して、その部分だけ賢くぼかせば、ジャギーはごまかせるではないか。ということで、FXAAなどのアンチエイリアスは、縁を判定して賢くぼかすピクセルシェーダーのコードで実装されている。

Screen Space Global Illumination、あるいはReal-time Local Reflection

Unreal Engine 3のSamaritanデモで、この技術が披露されている。

また、Crysis 2にDirectX 11パッチを当てると、Real-time Local Reflectionと称して、この技法が使われる。

これも、スクリーンスペースによる反射の実装である。水たまり、テーブル、壁などに、周囲の風景が写り込んでいる。

何にしても、化石スペックのコンソールが足を引っ張りすぎている。テッセレーションを活用したゲームはほとんどない。もっとも、テッセレーションは、その可能性あふれると裏腹に、普通に使っても、それほど見た目にはインパクトがない地味な機能なので、仕方がないのかもしれない。それに、ほとんどのゲームでまともに使っていないので、GPUベンダーもあまり力を入れていないのだと思う。ただし、将来に期待できる。個人的には、Normal MappingやBump Mappingには全然感動できないので、Parallax mappingやDisplacement mappingがもっと使われてほしいものだ。

変わり種としては、Rageが上げられる。伝説のプログラマーJohn Carmackは常に変わったことをする人である。ただし、常に主流の技法からは外れているのだ。今回、Carmackがこだわったのは、テクスチャーだ。Rageでは、使い回しのないテクスチャーを実現している。もちろん、テクスチャーの構築には、デカールを使い回しているが、テクスチャ自体はユニークである。Rageのグラフィックは、序盤の廃墟がすばらしい。ただし、ユニークなテクスチャーは、デザイナーにかなりの負担を強いるらしい。プレイ動画をみても、中盤以降はマップの構成が雑になっているし、ついには長いマップ作成を諦めて、狭い部屋に閉じ込めて、周囲から延々と沸く雑魚敵を相手に戦うような演出でごまかしている。残念なことだ。もう一つ残念なことに、テクスチャーを使いまわさなかったせいで、あんなに短いのに、DVD三枚ほどの容量を必要としている。もちろん、PCならばいまどき20GB程度のサイズは問題にならないが、博物館に陳列されるレベルの低スペックな現行コンソールではかなり問題になる。そして、今時Bump Mappingすらないのだ。まあ、個人的にBump Mappingは価値がわからないのでどうでもいいのだが、やはりないと寂しい物がある。Rageは色々と惜しいゲームであった。

2011-12-29

マリオカート7が劣化していた

たまたま、3DSのマリオカート7に触れる機会があったので、遊んでみたのだが、全然面白くなかった。レースゲームなのに疾走感がまるでなかった。

まずグラフィックが糞だ。加速時にFOVを狭めたり、ブラーをかけたりするなど、レースゲームならではの表現手法は、もう考案され尽くしているはずなのに、なぜこの2011年で、こんなにもしょぼい表現なのだろう。それに、マップが無駄に広い気がする。何故こんなに広いのだろうか。こんなに道が広くては、コースアウトして溝に落ちるとかダートに突っ込んで減速するといったスリルを味わえない。ただ惰性で操作しているだけで完走できるヌルい作りになってしまっている。こんなゲームのどこが面白いというのか。

結局、マリオカートというゲームは、スーパーマリオカートでその可能性を示し、マリオカート64で完成されたゲームなのだろう。これ以上何を付け足しても蛇足というものだ。マリオカート7をやるくらいなら、スーパーマリオカートやマリオカート64をやったほうが、よっぽど面白いはずだ。

なぜこうなってしまったのだろう。今や、ポータブルゲーム機ですら、ニンテンドー64をはるかに上回るスペックを持っているのだ。それなのに、なぜ当時よりつまらない劣化続編しか作れないのだろうか。そして不思議なことに、ゲーム市場は、当時よりはるかに大きく、売上本数も増えていることだ。これは一体どういうことだろう。世の中はクソゲーを望んでいるのだろうか。

2011-12-28

Intel、ネットワーク越しに電源を入れる特許を取得

Intel Receives Network-Power-On Patent

Intelが、ネットワーク越しに電源を入れる特許を取得したらしい。はて、そんなのは自明ではないのだろうか。すくなくとも、この特許が出願された2007年以前にも、そんな装置は山ほどあったと思うのだが。

2011-12-27

鬼を笑わせる

今年も残り少なくなってきたところで、鬼を笑わせるような未来予測をしてみたい。ところが、どうも今は、さっぱり希望がでてこない。というのも、PCの進化がどんどん遅くなっているようなきがするのだ。

たとえば、CPUの処理能力は、ここ数年、驚くほどの向上はない。少し向上はしているものの、その向上が目にみえて実感できないのだ。もはや、我々はMP3のエンコード速度を気にする必要はない。ゲームなど、もはやCPU依存ではなく、GPU依存になっている。動画のエンコードでは多少の実感ができるが、やはり一般的とは言いがたい。

GPUはCPUよりまだ希望がある。といっても、今のPCゲームは、低スペックなコンソールに足を引っ張られて、その性能はあまり意味がない。GPGPU(GPUによる汎用コンピューティング)は、あまりにも適用可能な範囲が限定的で、やはり一般人が直接その恩恵に与ることはない。

HDDの容量なんてもはや誰も気にしないし。SSDは値段が下がる程度の予測しかできない。

もうPCの世界からみると、ハードウェアの進化は止まっているも同然なのだ。

ただし、これがスマートフォンになると、かなり未来は明るい。スマートフォンのハードウェアは、年々進化している。もうしばらくすれば、グラフィック性能が現行コンソールに追いつくだろう。その時、果たしてゲームコンソール、すなわちゲーム専用機は、生き残れるだろうか。今より少しグラフィック性能を上げただけでは、果たして差別化出来るだろうか。十分なグラフィック性能をもったスマートフォンを誰もが持っている世界では、ゲーム専用機など無意味である。実はPCすら危うい。もし、ディスプレイとの接続がワイヤレスになれば、果たしてPCは生き残れるのか。

もちろん、無線によるディスプレイ接続は、帯域的にまだ現実的ではないが、いずれ実現されると考えている。鬼が一番笑いそうなのはここだろうか。

ただし、スマートフォンでひとつ気になるのは、自由が全くないということである。PCならば、どのハードウェアを使うか、どのOSを使うか、どのネットワークを使うか、ということは、自由である。ソフトウェアも、様々な配布形態がある。ところが、スマートフォンでは、こうは行かない。ハードウェアとOSは固定されており、ネットワーク提供者も、大抵固定されている。ソフトウェアは統一された唯一の中央マーケットから入手しなければならない。しかも、このマーケットでは、ソフトウェアには事前に検閲が行われているし、遠隔操作によるユーザー側のスマートフォンのソフトウェアの消去も可能なのだ。これはどういうことだ? 今年は1984年か?

PCならば、ハードウェアには様々な標準規格がある。しかし、スマートフォンにはそんなものはない。ハードウェアとOSがセットになったAppleはさておき、androidさえ、ハードウェアの仕様はころころ変わるので、昔のハードウェアに最新のandroid OSを入れるということが困難である。

さらに、特許の問題がある。スマートフォンの世界では、私のコモンセンスで考えるに、自明であるようなアイディアにまで、特許が与えられている。特許はアイディアに与えられるものだっただろうか。ユーザーの利便性と普及を考えれば、機能やデザインを統一するのは理にかなっている。キーボード配列やマウスは、信号は規格化されているし、レイアウトも規格化されている。スマートフォンにはこれがない。みなてんでバラバラに実装し、それぞれ独自発明であるとして特許を取得し、市場原理に則った競争をせずに、特許裁判に明け暮れている。

もし当時、キーボードのレイアウトやマウスの形状、またはその信号方式に、今のように激しく特許を主張し、各社ともてんでバラバラに実装していたとしたら、今日のPCの興隆はあっただろうか。

これをもってこれをおもうに、あと10年ほどは、PCのスマートフォンに対する優位性は揺るがないであろう。PCがはるかに優れているためではなく、スマートフォンが足の引っ張り合いで自爆しているためである。したがって、私は今、スマートフォンについて何か学ぶ必要は一切ないと結論できる。この不自由と特許の問題が解決されてから学んでも遅くはないだろう。

SOPAガキ

Lauren Weinstein's Blog: "SOPA Lad" (The SOPA Song) - With Apologies to Gilbert and Sullivan

またLauren Weinsteinさんか。この人、本当にGilbert and Sullivanが好きなんだな。

元ネタはこれ、When I was a Lad.

2011-12-22

ブログのデザインを変えた

そろそろ、昔のテンプレートでは管理画面がまともに機能しなくなってきたので、仕方なく新しいテンプレートを使うことにした。HTMLの修正による変更はしたものかどうか悩んでいる。

2011-12-21

Winny開発者の金子勇、無罪

著作権侵害を幇助したとの疑いをかけられていたWinny開発者の47氏(最初に2chに開発宣言をしたレス番が47であった)こと金子勇が、無罪になった。当然である。ソフトウェアを開発、公開しただけで犯罪になってはたまらない。

ただし、Winnyはその仕組みからして、問題がある。ネットワーク内にたった一人の著作権侵害ノードがあるだけで、全員が推定著作権侵害になってしまうのだ。

Winnyの機能に、中継というものがある。これは、ファイルをアップロードするノードとダウンロードするノードの間にたってデータを横から横へ流す、いわばプロキシとなる機能である。この中継機能は、ユーザー外としていないデータまで中継する可能性がある。さらに、Winnyはキャッシュという仕組みによって、中継されたデータを保持し、その後も送信可能な状態におく。これが問題となる。

もし、中継機能がなければ、すなわち自分が明示的にダウンロードを選択したデータのみ、アップロードすることになる。これは、取得と公衆送信に、著作権上問題のないデータであれば、全く問題ない。ただし、中継という機能によって、意図しない著作権侵害かもしれないデータをダウンロード、アップロードしてしまう。つまり、Winnyネットワーク上にひとつでも悪意あるノードがいて、その著作権上問題となるデータをダウンロードしようという別のノードがいれば、自分が中継する可能性がある。よって、Winnyネットワーク内にひとつでも悪意あるノードがあれば、全ノードが推定有罪になってしまう。Winnyネットワークへは誰でも参加できるので、当然問題となる。

当時取るべきだった方法は、この問題を認識して、修正するように働きかけることだったのだ。それを、著作権侵害幇助などというどう考えてもおかしい理由で逮捕、起訴して、無罪判決まで七年もかける。問題のソフトウェアは修正されないまま放置されている。Winnyネットワークは中央管理サーバーを持たないので、全世界に核による絨毯爆撃でもしないかぎり、止められはしないというのに。これだから日本からはイノベーションは生まれない。

とはいえ、もし当時逮捕がなかったとしても、Winnyプロトコルが標準規格になるのは無理だっただろう。本当に普及させたいならば、まず仕様を文章で公開し、リファレンス実装をオープンソースで公開すべきだったのだ。まあ、あの当時はまだこの分野の夜明けのようなものだったので、似たようなプロトコルが乱立した。今となっては、Winnyプロトコルは、古びた時代遅れのプロトコルと言わざるを得ない。そもそも、ファイル共有自体に、新鮮な面白みもない。あの当時と比べて、ハードウェアははるかに進化した。ファイル共有程度であれば、別にP2Pを用いなくたっていいのだ。Dropboxのようなサービスが、当時よりはるかに安価で提供されている。もっとも、日本ではオンラインストレージは違法だというトンデモ判決がでているのだが。

では、今注目すべき技術は何かというと、やはりNamecoinだろう。合衆国でSOPAが議論されている今、中央管理のDNSへの信頼性が揺らいでいる。本来、名前解決のサービスに検閲や規制などがあってはならないのだ。名前解決というのは、著作権侵害や犯罪とは何の関係もないからだ。Namecoinは、ドメイン名の名前解決を、Bitcoinと同じ方法で行うものである。すなわち、P2Pで中央管理サーバーを持たず、信頼性が計算力により保証されたシステムである。

2011-12-05

Safari for Windowsの日本語版の使用許諾書がひどい

Safari for Windowsをインストールしようとして、使用許諾書を読んだところ、ひどい誤訳だらけで、何の意味もなしていないことを発見した。

たとえば、以下のような文面がある。

重要な通知: このソフトウェアがマテリアルを複製するための範囲において、使用することができます。

これを素直に解釈すると、ユーザーである私は、このソフトウェアであるSafariを使って、自由にマテリアル(?)を複製して良い、と読める。

さっぱり理解出来ないので、英語版のライセンスを読んだところ、以下のようになっていた。

IMPORTANT NOTE: To the extent that this software may be used to reproduce materials, it is licensed to you only for reproduction of non-copyrighted materials, materials in which you own the copyright, or materials you are authorized or legally permitted to reproduce.

これは分かりやすい。この文章の意図は、「このソフトウェアは、著作物を複製する可能性がある」と警告しているのだ。翻訳では、文章の途中でぶった切ってしまっているので、訳のわからないものになっているのだ。一体どこの馬の骨が、materialをマテリアルと翻訳して、しかも具体的な定義を与えないことが、いいアイディアだと考えたのだろうか。英語におけるmaterialは改めて定義する必要がない法律用語であったとしても、日本語における「マテリアル」は、そうではない。

しかし、最も問題なのは、以下の文章だ。

2.許諾された使用方法およびその制限
A. 本契約の規定に従い、お客様は、一回につき一台のApple商標が付されたコンピュータにAppleソフトウェアを1部インストールし、使用するための限定的な非独占的ライセンスを付与されます。

Apple商標が付されたコンピュータ? それはつまり、Appleが販売しているコンピューターのことであろう。しかし、このAppleソフトウェアは、Safari for Windowsである。私のコンピューターは、Appleが販売しているコンピューターではない。とすると、私はSafariの使用許諾の条件を満たしていないことになる。この条件を満たすユーザーとは、Boot CampでWindowsを使っているユーザーに限定されてしまう。

ちなみに、原文では以下のようになっている。

2. Permitted License Uses and Restrictions.
A. Subject to the terms and conditions of this License you are granted a limited non-exclusive license to install and use one copy of the Apple Software on each computer owned or controlled by you.

Apple商標が付されたコンピューターなどという文面はない。

2011-11-26

JavaScriptの難読化におすすめのサービス

aaencode - Encode any JavaScript program to Japanese style emoticons (^_^)

alert("Hello, JavaScript")

という何の変哲もないJavaScriptのコードが、

゚ω゚ノ= /`m´)ノ ~┻━┻   //*´∇`*/ ['_']; o=(゚ー゚)  =_=3; c=(゚Θ゚) =(゚ー゚)-(゚ー゚); (゚Д゚) =(゚Θ゚)= (o^_^o)/ (o^_^o);(゚Д゚)={゚Θ゚: '_' ,゚ω゚ノ : ((゚ω゚ノ==3) +'_') [゚Θ゚] ,゚ー゚ノ :(゚ω゚ノ+ '_')[o^_^o -(゚Θ゚)] ,゚Д゚ノ:((゚ー゚==3) +'_')[゚ー゚] }; (゚Д゚) [゚Θ゚] =((゚ω゚ノ==3) +'_') [c^_^o];(゚Д゚) ['c'] = ((゚Д゚)+'_') [ (゚ー゚)+(゚ー゚)-(゚Θ゚) ];(゚Д゚) ['o'] = ((゚Д゚)+'_') [゚Θ゚];(゚o゚)=(゚Д゚) ['c']+(゚Д゚) ['o']+(゚ω゚ノ +'_')[゚Θ゚]+ ((゚ω゚ノ==3) +'_') [゚ー゚] + ((゚Д゚) +'_') [(゚ー゚)+(゚ー゚)]+ ((゚ー゚==3) +'_') [゚Θ゚]+((゚ー゚==3) +'_') [(゚ー゚) - (゚Θ゚)]+(゚Д゚) ['c']+((゚Д゚)+'_') [(゚ー゚)+(゚ー゚)]+ (゚Д゚) ['o']+((゚ー゚==3) +'_') [゚Θ゚];(゚Д゚) ['_'] =(o^_^o) [゚o゚] [゚o゚];(゚ε゚)=((゚ー゚==3) +'_') [゚Θ゚]+ (゚Д゚) .゚Д゚ノ+((゚Д゚)+'_') [(゚ー゚) + (゚ー゚)]+((゚ー゚==3) +'_') [o^_^o -゚Θ゚]+((゚ー゚==3) +'_') [゚Θ゚]+ (゚ω゚ノ +'_') [゚Θ゚]; (゚ー゚)+=(゚Θ゚); (゚Д゚)[゚ε゚]='\\'; (゚Д゚).゚Θ゚ノ=(゚Д゚+ ゚ー゚)[o^_^o -(゚Θ゚)];(o゚ー゚o)=(゚ω゚ノ +'_')[c^_^o];(゚Д゚) [゚o゚]='\"';(゚Д゚) ['_'] ( (゚Д゚) ['_'] (゚ε゚+(゚Д゚)[゚o゚]+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚Θ゚)+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ ((゚ー゚) + (o^_^o))+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚Θ゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) +(o^_^o))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) - (゚Θ゚))+ (o^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (o^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (゚Θ゚)+ (゚Д゚)[゚o゚]) (゚Θ゚)) ('_');

という、訳のわからないコードに変換される。

2011-11-22

2011-11-19

信じられん

この工作精度はすごい。

2011-11-17

Windowsに日本の歴史的な年号を追加する方法

Extending the Windows Japanese Calendar Era information. - I'm not a Klingon

Windows 7/8ならば、レジストリに追加することで、日本の歴史的な年号を追加することができる。

もっとも、年号などいいかげんに滅びるべきである。我々はある時間を起点として線形にインクリメントされていく年号を採用すべきなのだ。年号に対する個人的な反対運動として、私は今年が平成何年であるかを覚えるのをやめている。

しかし、英語の月は数字を使っていないので、日本語と英語に関して言えば、日本が致命傷で引き分けといえるだろう。

2011-11-10

Skyrimのデザインについて思う

Skyrimの発売まで、間近になっている。まだ発売されていないとはいえ、Skyrimの内容については、事前の発表でだいたい明らかになっている。それをまとめているWikiも存在する。

Skyrim:Skyrim - UESPWiki

この情報を元に、Skyrimについて考察しようと思う。

Skyrimは、明らかに複雑性を減らす努力をしている。たとえば、Oblivionでは、八つの基本能力、Strength, Endurance, Intelligence, Willpower, Agility, Speed, Personality, Luckがあった。Health, Magicka, Fatigueなどは、これらの能力とレベルアップによる加算によって計算される従属的な能力であった。さらに、剣の威力は、剣自体の強さが、基本能力StrengthとLuck、スキルBladeによって修正された値であった。だいぶ複雑である。

Skyrimでは、この仕組が、だいぶ単純化されている。Skyrimにおける基本能力は三つ、Health, Magicka, Staminaだけである。もうStrengthやLuckは存在しないので、剣の威力は、単にOne-Handedによって修正されるだけである。

私は、この複雑性を下げることが、快適なゲームプレイにつながると思っている。かつてのゲームは、もっと複雑だったのだ。たとえば、Daggerfallでは、走る、泳ぐ、壁を登る、ジャンプするなどといった動作にそれぞれ独立したスキルが存在したし、避けるだとかクリティカルだとかいうスキルもあったし、ある種の敵と友好的になれるスキルもあった。これは、当時はハードの制約で、複雑性を誇れるものが、結局これぐらいしかなかったのである。

今や、ハードは素晴らしく進化した。リアルタイムなシェーダーによる3Dレンダリング、プロシージャルアニメーション、フルボイスは、全く珍しくない。とすれば、複雑性は、このような数値で実現する必要はないのだ。もっと別方法でいくらでも実現できる。

たとえば、MorrowindにあったMark/RecallやLevitationは、存在しない。これはべつに、技術上の問題ではない、自由にワープできたり空を飛べたりすると、ゲーム制作が非常に制限される。あらゆるダンジョンやらクエストは、ワープや飛行の存在を前提に設計しなければならない。聞説、Morrowindでは多くのクエストのアイディアが、「オゥイェア、そんなのレビテーションで切り抜けりゃいいじゃんHAHAHA」などというスタッフのツッコミによって、断念せざるを得なかったらしい。

興味深い話

The assault on Los Alamos National Laboratory: A drama in three acts

まあ、一言で言うなら、お役所仕事。

2011-11-08

うおおおお!

Twitter / @Flast_RO: キターーーーーーー喜べ野郎ども!!!!
Bug 45114 – implement C++0x alias-declaration

キタ━━━━(゚∀゚)━━━━!!

どうやら、Template Aliasまで含んでいるらしい。

JoystickAPIが欲しい

JoystickAPI - MozillaWiki

これは是非とも欲しい機能だ。これさえあれば、もうゲームのプラットフォームはブラウザだけで完結できることになる。

TPPへの反対を表明する

The complete Feb 10, 2011 text of the US proposal for the TPP IPR chapter | Knowledge Ecology International

5. Each Party shall provide that, where the term of protection of a work (including a photographic work), performance, or phonogram is to be calculated:

  • (a) on the basis of the life of a natural person, the term shall be not less than the life of the author and 70 years after the author’s death; and

  • (b) on a basis other than the life of a natural person, the term shall be:

    • (i) not less than 95 years from the end of the calendar year of the first authorized publication of the work, performance, or phonogram, or

    • (ii) failing such authorized publication within 25 years from the creation of the work, performance, or phonogram, not less than 120 years from the end of the calendar year of the creation of the work, performance, or phonogram.

アメリカの壊れた著作権法を押し付けられるいわれはない。これ以上著作権の保護期間を延ばす必要はない。今保護期間が延びるということは、将来も延びる可能性があるということだ。つまりそれは、著作権は永続するも同義である。

結局、戦前の死後30年の保護期間は、妥当だったはずだ。

2011-11-03

Skyrimがやりたい

Skyrimがやりたいが、やれない。

Skyrimがそろそろ発売される。もっとも、日本では12月まで待たなければならない。Bethesda公式ブログで11.11.11ワールドワイドなどと宣っているが、真っ赤な嘘である。

Skyrimは是非ともプレイしたいゲームだ。しかし、残念ながら、今プレイするわけにはいかない。金がないのだ。Skyrim自体はSteamで$59.99だが、Skyrimをプレイするためには、新しいGPUが必要である。まあ、GTX560あたりを買うと考えても、やはりしめてニ万はかかるであろう。

金のないだけが問題ではない。Skyrimはキリのないゲームである。まともに遊ぼうとすると、恐らく一年ほど飽きがこないであろう。当然、C++本の執筆にも差し支える。他の凡ゲーならば、せいぜい十数時間もあれば飽きてしまうから、まあ、息抜きに遊んでも、特に問題はない。ただし、Skyrimだけは別物なのだ。疑うことなく約束された神ゲーである。

まあ、どうせBethesdaのことだから、見切り発車で発売してバグだらけ、パッチに半年は待たなければならないだろうし、DLCもいくつか出るだろうし、MODも揃ってから遊んだほうが便利だが、やはり神ゲーを遊べないのはつらい。

思えば、今年は大作が多かった。それにもかかわらず、去年と今年は、一切ゲームをしていない。もちろん、すべて遊ぶ価値のないクソゲーだったからだ。もっとも、実際にプレイしたわけではなく、レビューやプレイ動画を見ての感想だから、所詮は動画評論家のそしりを免れないが、それでも、みているだけでつまらなそうなゲームは、実際つまらないに違いない。

まずBulletstormだ。これは、Trailerを見ると、面白そうだった。それに、Duty Callsというパロディゲームをマーケティング用に出したのも興味深かった。

ただし、実際のゲームは振るわなかった。つまらない単調な一本道ゲームだった。しかも、最後は続編を匂わせるクリフハンガーで終わるという、真につまらないゲームだった。

お次はCrysis 2だ。いや、Crysis 2に限って言えば、クソゲーというほどひどかったわけではない。ただ、どこにでもあるような平凡なゲームだったのだ。グラフィックはそれなりによかったが、戦略のカケラもない一本道ゲームだった。まあ、戦略はあった。Cloakで殆どの敵はやり過ごせるのだから。これまた、クリフハンガー的な終わり方をするプロットだった。まあ、確かにブランドは大事だが、露骨にクリフハンガーにしても面白いわけがない。思うに、Crysis 2はゲームなどではなく、CryEngine 3の技術デモだったのではあるまいか。それぐらい、ゲームらしくないゲームだった。

さて、いよいよDuke Nukem Foreverだ。最も、最近の若いもんはDuke Nukemもしらんじゃろうが、かつては伝説のゲームだったのじゃて。DNFが発売されてしまったのは、真に残念なことだった。夢は夢として、いつまでも夢見ていたほうが幸せなのだ。現実は常に夢よりクソである。Duke Nukem Foreverは、5年前に発売したならば、まあ、そこそこなゲームだったに違いない。クソゲーなことには変わりないが、まあ当時の水準ならば、普通以下程度の評価は得られたに違いない。今となっては・・・いや、よそう。もう何も言うまい。

Rageである。Rageも長い間開発していたゲームだった。Doom 3は真っ暗なゲームだった。私が思うに、Doom 3は全ピクセルに黒をアルファブレンドすれば、もっとも効率よく実装できたのではあるまいか。それぐらい暗かった。それはさておき、伝説のゲーム開発会社idと、伝説のゲームプログラマーJohn Carmackの送る最新ゲームRageは、非常に期待されていた。思うに、我々はRageを過剰に期待しすぎていたのではないだろうか。それも無理はない。何しろ、2008年のE3におけるTrailerが、今から見ると詐欺臭いほどのクオリティだったからだ。

これをみれば、過剰に期待するのも当然である。結果は散々だった。メガテクスチャーは20GBもの容量を使い、しかも視点を動かすだけで貼り遅れるという散々な出来であった。しかもボケボケで見るに耐えない。オープンワールドでもないのに、無駄に車や移動といった要素がある。聞説、FPS部分はよくできていたらしい。もっとも、頻繁に移動しなければならないが苦痛だったらしいが。それでも、プレイ時間はたったの十数時間と聞く。プロットなどあってないようなもの。エンディングもエンディングのようには感じられない。何もかもが中途半端なのだ。クリフハンガーですらないのだ。ひょっとしたら、もうこれ以上収集がつかなくなり、とりあえず開発資金を回収しようと、無理やり出荷したのではあるまいか。実際、開発に相当の金がかかっているはずである。最後はBethesdaに身売りまでしたのだから。

こうしてみると、今年は遊ぶべきゲームが一切なかったのだ。Skyrimは約束された神ゲーなので大丈夫だろうとは思う。遊べないのが本当に残念だ。

実は、今年はまだ、もう一本、大作(?)が控えている。Postal 3である。Postal 3も、DNFやRageに引けを取らないほど長く開発されているゲームである。何しろ土台がSourceエンジンなのだ。前作のPostal 2が神ゲーであったことは、議論の余地がない。しかし、長年の延期の末に、ようやくだして、果たして面白いものかどうか。その辺は疑問である。

2011-10-30

Dartにおける代入可能について

まず最初に英語で書いてから日本に訳すという方法で書いてみた。何か違いが出るだろうか。

Dartはoptional typeを採用している。ある変数に代入できない型を代入しようとした場合、静的型警告が発せられる。ただし、プロダクションモードで実行された場合は、実行に何の影響も及ぼさない。

int x = "hello" ; // static type warning

では、代入可能とは一体何か。どのように定義されているのか。13.4 Interface Typesで定義されている。

型Tが型Sに代入可能である場合、すなわち、s = t でtの型がTでありsの型がSである場合というのは、

  • TはSである。

    int s = 0 ;
    

    これは当然だ。.

  • Tはnullである。

    int s1 = null ;
    

    nullは、⊥という特別な型を持っている。これは、どんな型にも代入可能である。

  • TかS、あるいはその両方がDynamicであるとき。

    void main()
    {
        var s1 = 0 ; 
        s1 = 0.0 ; 
        s1 = "hello" ;
    
        var d = 0 ;
        double s2 = d ;
    }
    

    動的型intを持つdを静的型doubleを持つs2に代入しているが、これは代入可能である。したがって、static type warningは発せられない。確かに、実行時には型の不一致を起こすが、それは実行時にしか分からないので、静的警告は発しようがない。

  • SとTがジェネリック型I<...>であり、Tの型パラメーターが、それぞれSの対応する型パラメーターに代入可能な時。

    void main()
    {
        List<int> = <int>[] ;
        List<num> = <int>[] ;
        List = [ ] ; // List<Dynamic>
    }
    

Assignable in Dart

Dart use the optional type. When you assigned to a variable and it isn't assignable, a static type warning is issued. If the code is executed under the production mode, it doesn't affect run time behavior.

int x = "hello" ; // static type warning

So, what exactly is assignable? How is it defined? It's defined in 13.4 Interface Types.

A type T may be assigned to a type S, that is s = t where the type of t is T and the type of s is S, if

  • T is S

    int s = 0 ;
    

    This is obvious.

  • T is null

    int s1 = null ;
    

    null has the special type ⊥. It can be assigned to any type.

  • T or S(or both) are Dynamic.

    void main()
    {
        var s1 = 0 ; 
        s1 = 0.0 ; 
        s1 = "hello" ;
    
        var d = 0 ;
        double s2 = d ;
    }
    

    Notice assigning d(dynamic type of int) to s2(static type of double) is not a static type warning although it is incorrect in run-time. This is because it's assignable. If either T or S are Dynamic, it can't be determined in compile time. So it makes sense.

  • if S and T is a generic type of I<...> and T's type parameters are assignable to S's corresponding type parameters.

    void main()
    {
        List<int> = <int>[] ;
        List<num> = <int>[] ;
        List = [ ] ; // List<Dynamic>
    }
    

2011-10-28

What is it like buying a PC game in Japan?

Today, I saw kotaku used an interesting metaphor to describe what is it like buying a PC game.
If Haruki Murakami's New Book Were Sold Like a Video Game

I think buying a PC game from Japan is also interesting to write about. Even without the metapher.

It started in January...

January
I've heard a famous game developer will release a new game in June. Wow that's too soon. I must pre-order it immediately. But I wonder where to buy it. And the most important thing is, is there a Japanese translation available?

February
It appears the game requires Steam activation. So the package means nothing. I don't need some junk toys they'll include in the package. I wonder who want that crap. I can't understand what Americans are thinking. Anyway, I pre-order it in so called Steam. It allows me to download a game. That's nice. The Japanese Steam listed it up and allows me to pre-order. So it should work. And I've heard they'll release console version of this game in Japan. So naturally, PC version must have Japanese translation.

March
They announced that Japanese translation will be released in August. Well, that's okay. I guess translation need some time. I've also heard they even translate the voice. That's fine. Perhaps I should try English version while waiting. It's completely incomprehensible for me. But who needs story in game anyway? This is not a dull linear JRPG. That's why I'll buy it. I'm so sick of crappy JRPG. Look at the world. Think globally. I can look up words from dictionary if I have to. I'll enjoy the combat in the English version. Then, I'll enjoy the story later in the Japanese version.

April
What Steam? What do you mean I can't buy it from the current location? I am Japanese and sure I live in Japan. Yes I know this is the English version. I want to play regardless and I'm willing to pay. Why don't you let me buy it? Don't you want my goddamn money? This is stupid. I can't understand it. I don't care how much you charge me. I've read from the online forum that we can bypass that check by using what they call it VPN or whatever. I don't know how that works. Also, there are pirates as usual. But I'm not one of them. Besides, I don't know how to pirate a game.

June
At last. The English version is released. I think some people who used VPN will write something in forum. I should better check it... What? Not only they play it today, But they play it in Japanese? How could that even be possible? Well, come to think of it, console game will be released in a few days. So technically, translation works must have been finished already. So what is the point of delay? Why do I have to wait two months!

July
Wow. This is hilarious. They said Steam deleted Japanese translation from their disks. Apparently, It wasn't supposed to be released. But why. Just release the Japanese version already. I don't want to wait any more. Also, why do they allowed to delete files in our disks? I don't understand.

August
What is this? What the FUCK is this? They said they'll delay the release until next year. No. Seriously. That can't be possible. I have enough of this Steam.

2011-10-22

Dartがダウンキャストに警告を出さない理由

Dartでは、ダウンキャストには警告を発しない。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = new S() ; // ダウンキャスト
}

この例では、静的型Tの変数tに対して、静的型Sで、実際の型もSのインスタンスを束縛させているが、これは警告を発しない。アップキャストに警告を発しないというのは自然だが、ダウンキャストに警告を発しないというのは、オブジェクト指向に馴染みのない人からすれば、不思議に思われるかも知れない。現にこの場合、実際の型はTではないのだから、この場合に限っていえば、エラーである。しかし、これは正しい挙動である。では、なぜ警告を発しないのか。

なぜならば、規格に明確に書かれている挙動だからである(13.4 Interface Types)。クラスは暗黙のインターフェースを持つので、この項目はクラスにも適用される。

規格で定義されているとしても、理由はなぜか。それは、Dartの型システムは、ほぼ確実に間違いであろうと思われるコードを見つけるためにあるからだ。間違いである可能性があっても、正当なコードである可能性もあるコードに対しては、警告を発しない。

ダウンキャストは、オブジェクト指向言語ならば、当然行うことである。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = s ; // ダウンキャスト
}

これは、正しいコードである。変数sに束縛されているインスタンスの型は、まぎれもなくTである。したがって、このダウンキャストは正しい。もしこのコードに警告が発せられるとするならば、それは誤りである。このコードに警告を発するようでは、プログラマーは警告というものを信用しなくなってしまう。警告というのは、ほぼ確実に誤りである場合にのみ発せられるべきなのだ。

SとかTなどのやや抽象的な話ではわかりにくい人もいるかも知れない。もっと具体的な話をしよう。Dartではすべてのクラスは暗黙にObjectのサブクラスである。以下のコードは当然動くべきである。

void main()
{
    Object obj = "hello" ;
    String str = obj ; 
}

明らかに、このコードは正しいコードである。

2011-10-21

Bitcoinについて

Coding Horror: Multiple Video Cardsが、Bitcoinのお陰で中古GPUを格安で手に入れられたと書いていたので、Bitcoinの歴史と現状をまとめて見ることにした。

そもそも、諸君はBitcoinを知っているだろうか。いや、知らなくても無理はない。日本では、あまり有名ではないように思う。だから、まずBitcoinとは何かという説明をしようと思う。

Bitcoinとは、演算保証によって信頼を得ている貨幣である。およそ、貨幣というものが広く一般に使われるには、貨幣に対する何らかの信頼が必要である。たとえば、貨幣が金と交換できる保証であるとか、国による保証などといった、信頼が必要である。そのような強い保証のない貨幣は、広く信頼を得ることができず、一般に普及することはない。

Bitcoinは、P2P技術によって実装されたオンライン上の仮想貨幣である。すべての貨幣のやり取りはP2Pによる演算で処理され、個々の貨幣のやり取りは匿名で行うことができる。と、こう書いただけでは、信用のカケラも存在しない貨幣のように思われる。金と交換できず、国家の保証もない貨幣が、どうして信頼できるというのか。だいたい、どうやって偽造を防ぐのだ。それは、演算力である。

Bitcoinを得るには、演算をする必要がある。それも、かなりの演算が必要である。Bitcoinの貨幣のやり取りをP2P上で信頼できるほどに処理するには、暗号を使わなければならない。この暗号処理には、かなりの演算力を必要とする。Bitcoinを得るには、オンライン上でのbitcoinのやり取りに必要な演算の一部を負担する必要がある。すると、Bitcoinを不正に入手するというのは、つまりは暗号を解読するということである。それには、Bitcoinを普通の方法で得るより、はるかに高い演算力を必要とする。このため、Bitcoinの偽造は割にあわないということになる。ただし、誰かがSHA256の画期的な脆弱性を発見した場合は、この限りではない。Bitcoinネットワークを攻撃するには、Bitcoinネットワーク全体の演算力を上回る演算力が必要である。その演算力は、現在のBitcoinネットワークの規模から考えて、現実的ではない。

つまり、Bitcoinの信頼は、演算力とSHA256の暗号強度に依存しているといえる。金銀に交換することはできず、国家の保証もないとはいえ、不正ができないという点で、信頼を得ているのである。

Bitcoinの他の利点としては、国家の影響を受けないということと、プライバシーを守れるということである。国家が貨幣を管理していると、意図的に貨幣の価値を上下させられる可能性がある。Bitcoinの価値は、ユーザーが決定する。そのような中央の権威の影響は受けない。プライバシーというのは、貨幣の動きを特定されないということである。これは、ともすれば麻薬取引などの違法な売買や、脱税などの金銭の動きにも使われがちであるが、それは、別にBitcoinに限った話ではなく、金銀や紙幣でも同じなので、Bitcoin特有の問題というわけでもない。

では、Bitcoinの作者は誰か。これが、どうも怪しいのだ。もちろん、記録は残っている。2008年にSatoshi Nakamotoと名乗る自称日本人によって、Bitcoinの理論と仕様を説明する論文が発表された。最初の実装も、彼によって書かれた。しかし、彼は一言も日本語を発していないし、実装にも日本語は一切使われていない。彼の2010年以降の消息は不明である。彼のメールアドレスは、無料のメールサービスを利用しており、すべての接続は、Tor経由で行われていた。つまり、彼はありとあらゆる方法を使って、匿名性を保つ努力をしていたのである。日本人を自称したのも、事によると、正体を隠すための方便だったのかもしれないとまで言われている。

なんにせよ、Bitcoinの仕組み自体には、未だに脆弱性が見つかっていないし、Bitcoinで使う有名な暗号、SHA256も、未だに画期的な脆弱性は見つかっていない。

さて、Bitcoinは不正が難しいので、最低限の信頼性を備えていることは分かった。Bitcoinの仕様はすべて公開されており、オリジナルの実装以外にも、いくつかの別の実装がでてきた。とくに興味深いのは、演算にGPUを利用した実装である。GPUはCPUほど汎用的ではないが、うまく使えば、CPU以上の演算力を発揮できる。このため、Bitcoin mining(Bitcoin炭鉱業)と呼ばれる、いわばゴールドラッシュのような現象が起きた。高価なGPUが、Bitcoinを稼ぐために多数売れたのである。

Bitcoinはその期待によって、現実の貨幣(例えば米ドル)と交換する所が現れた。その交換レートが高かったので、高価なGPUと電気代を差し引いても、利益が出せたのである。

しかし、ゴールドラッシュが長く続くわけがない。Bitcoinはその多大な期待によって、実価値以上に高い交換レートで、現実の貨幣と交換されてきた。今や、そのバブルがはじけて、Bitcoinの現実貨幣に対する交換レートは暴落し、Bitcoin炭鉱業は以前ほど儲からなくなってしまった。国家や中央銀行のように、貨幣の価値を一定に保つ権威が存在しないのだから、これは当然である。ゴールドラッシュで儲けたのは、シャベルとツルハシを売っていた者であるというのはよく言ったものだ。ハイエンドGPUが山ほど売れたのだ。

そのため、ハイエンドGPUが中古市場に溢れ、冒頭でも言ったように、Jeff Atwoodとかのゲーマーがその恩恵を受けている。

もちろん、これはBitcoinの為替が適正なレートに下がっただけであり、Bitcoinの暗号自体は、未だに破られていない。

Bitcoinの合法性であるが、独自通貨の発行が合法かどうかということにかかっている。これは、国ごとに違うので、なんとも言えない。ただし、オンラインでの売買の興隆をみれば、独自通貨の発行自体は、将来的には大抵の国で合法になる方向に動くだろう。さもなければ、ゲームやPaypalのようなサービスが成り立たない。

私自身はBitcoinには興味がなかったのだが、知り合いに、Bitcoinの仕組みに共感し、自分でも実装を書き、ハイエンドGPUでせっせと掘っている人物がいるので、近況を聞いてみた。彼は、単に技術的な好奇心のためにやっているのであって、小遣い程度の金には興味がなく、したがって、最近のBitcoinと現実貨幣の交換レートの暴落は気にしていないらしい。

私はふと、このBitcoinが、一時期のP2P技術を利用したファイル共有に対する期待に似ているのではないかと思った。あの当時、P2P技術を利用したファイル共有には、なにかゴールドラッシュのような期待があった。確かに、現時点では違法かもしれないが、それは法律が現実に追いついていないだけであって、将来的には素晴らしい可能性を秘めているのではないかという期待があった。

現実としては、法律は一向に変わらず、P2P技術は、Skypeを始めとする通信、ソフトウェアのアップデートの配布などの、裏方技術には使われているが、表立って存在を意識するほどではなくなってしまった。Bitcoinも同じような過剰の期待に押されていたのではないだろうか。

このような意見を、かの知り合いにぶつけてみたところ、彼はこれを認めた。曰く、「たしかに、そういう過剰な期待があるのかもしれない」と。「Bitcoinに触発された後発の仕様もいくつか出ている。Bitcoinは、実際の価値はさておき、コンセプトとして一定の価値があることは確かだろう」とも言っていた。

国家に左右されない貨幣が主流になる時代は来るのだろうか。

アイドック株式会社、紙書籍と電子書籍の抱き合わせ商法を発表

デジタル著作権管理(DRM)ならキーリング|愛読者カード運営代行サービス「i 読(あいどく)」提供開始!!
i読…愛読者カード運営代行サービス
via : これで自炊は不要? 愛読者カード返送者にのみ電子書籍を配信する「i読」 -INTERNET Watch

レコードをカセットテープに録音する? おいおい、何言ってやんでぇ。そんなのオイラの目の黒いうちゃぁ許しちゃおけねぇよ。レコード針やターンテーブルの生産会社が潰れちまうだろうがよ。代わりにこれ、レコードを買うと録音したカセットテープをプレゼント。あ、ほら、もう録音なんてする必要がねぇってもんだ。これにて一件落着。あっぱれあっぱれ。

DTP? よしてくれよ、写植職人が路頭に迷うぞ。最低限でもだな、今の写植と同じ仕組みでなければな。もちろん操作方法も同じだ。

活版印刷? おいおい、版木職人を飢え死にさせる気か? まあ仕方がないから、版木本を買えば、活字本もおまけしてやろうじゃないかい。

版木? そんなの許しちゃおけねぇ。真の書というものはよく手書く者によって写されるべきなんだよ。このままだと、写本職人が失業するだろうがよ。そこでこれ、写本を買うともれなく版木本をプレゼント。

紙? おいおいバカ言っちゃいけねぇや。日常の文章は木簡や竹簡に書いて、高級な文章は絹に書くのが常識だろうがよ。紙なんていう最近できたもんに字なんか書けるかってんだ。

字? おまえなぁ、生きておる智慧が、字などという死物に書きとどめられるはずがない。絵にならまだしも画けようが。それより口伝の続きじゃ。さて我がご先祖は~、怨敵をことごとく討ち平らげ~、この地に来たりて安住し~。さあ覚えるんじゃ。

2011-10-19

Dartで誤って無限ループに陥るコード

Dartは非常にシンプルな言語であるが、恐らく初心者が、誤って無限ループに陥ると思われる箇所がいくつかある。

ファクトリーコンストラクター

class X
{
    factory X() =>  new X() ; // 無限ループ
} 

void main()
{
    X x = new X() ;
}

このコードは、無限ループに陥る。なぜならば、new X()というのは、ファクトリーコンストラクターXを呼び出す式である。これは、つまり自分自身を再帰呼び出ししていることになる。結果として、無限ループになる。

正しいファクトリーコンストラクターの書き方は、別のコンストラクターを呼び出すものである。

class X
{
    X.internal() { }
    factory X() => new X.internal() ;
}

クラスのゲッターとセッター

クラスのゲッターとセッターは、クラスの変数への簡単な読み書きを提供するための特殊なメソッドである。これは、暗黙に生成される。

class X
{
    int val = 0 ;
// 以下のようなゲッターとセッターが暗黙的に生成される
    // int get val() => val ;
    // void set val( int value ) { val = value ; }
}

void main()
{
    X x = new X() ;
    x.val ; // ゲッター呼び出し
    x.val = 0 ; // セッター呼び出し
}

ご覧のように、セッターとゲッターは関数であるが、特別な文法で呼び出すことができるのだ。

サブクラスでは、この暗黙のゲッターとセッターをオーバーライドすることができる。つまり、ゲッターとセッターで、なにか複雑な処理を行うこともできるのだ。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => val ; // 無限ループ
}

これは無限ループとなる。なぜか。考えてみて欲しい、クラスYのスコープにおけるvalとは何なのか。それは、もちろんYのスコープで宣言されているvalである。つまり、Yのゲッター関数valということになる。これは、自分自身の再帰呼び出しである。つまり、無限ループになる。

正しいサブクラスによるゲッターとセッターのオーバーライドは、スーパークラスのゲッターとセッターを呼び出すものである。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => super.val ;
 
}

これで、再帰呼び出しは起こらない。

ちなみにいうと、ゲッターとセッターはトップレベル関数でも使える。

int _val = 0 ;

int get val()
{
    print("このままでは菌類が死滅してしまう") ;
    return _val ;
}

void set val( int value )
{
    print("勉強でも仕事でも 楽しんでやったものが、一番自分の力になるものさ。") ;
    _val = value ;
}

void main()
{
    int x = val ;
    val = 1 ;
}

ChromeがText-to-Speech APIを提供

Chromium Blog: New Text-to-Speech API for Chrome extensions

Chromeがエクステンション向けにText-to-Speech APIを提供するらしい。これは面白そうだ。

2011-10-18

Dartの興味深い機能

named parameterとnamed argument

void f( int x, [ int y = 0, int z = 0 ] ) { }

void main()
{
    f( 0 ) ; // f( 0, 0, 0 )
    f( 0, 1 ) ; // f( 0, 1, 0 ) 
    f( 0, z : 1 ) ; // f( 0, 0, 1 ) 
}

まあ、コードを読めば一目瞭然の機能だろう。省略可能なのは、named parameterだけである。名前を指定できるのも、named parameterだけである。normalFormalParameterは省略も名前指定もできない。

noSuchMethod

class X
{
    void noSuchMethod( String function_name, List args )
    {
        print("$function_name") ;
        for ( var elem in args )
        { print("$elem") ; }
    }
}

void main()
{
    X x = new X() ;
    // 関数名と実引数が表示される
    x.f() ; 
    x.hoge(1,2,3,4,5) ;
    x.fuga("All base is belong to us.")
}

これは解説が必要だろう。もし、クラスからメソッド名のlookupに失敗した場合、そのクラスからnoSuchMethodという名前のインスタンスメソッドが探され、第一引数としてメソッド名を、第二引数として、実引数のリストを渡し、呼び出されるのだ。もし、noSuchMethodという名前のインスタンスメソッドがなければ、NoSuchMethodExceptionが投げられる。

ということはだ、noSuchMethodというインスタンスメソッドを定義していれば、あたかもoperator .を定義したかのように振る舞うのだ。もちろん、実際にはoperator .はないし、メソッド呼び出しにしか適用できないが、DSLオタクは歓喜するだろう。

typedef

typedef int func_type(int) ;

void f( func_type func )
{
    int x = func( 0 ) ;
}
main()
{
    f( (int x) => x + 1 ) ;
}

typedefは、静的型の別名を定義するための構文である。現在のところ、関数の静的型の別名を定義することしかできない。

これはなぜかというと、関数は、具体的な静的型を直接に指定するのは面倒なのだ。こんなふうになってしまう。

void f( int func(int) ) { }

インターフェースFunctionはあるが、あまりにアバウトすぎる。だから、厳密な静的型を意味する識別子を定義するために、このtypedefが存在する。

べつに、これを使う必要はない。たとえば、varで受けても問題ない。DartはOptional Typeを採用しているからだ。静的型は実行時には、ほとんど意味がない。

量子浮遊

こいつは最高にクールだ。

2011-10-17

さっそくDartの規格上のバグを発見

私の唯一誇れる能力は、読解力である。そのため、私がプログラミング言語の規格を読むのを好むのは、自然なことである。このたび、Dartの規格上のバグを発見した。なかなか笑えるので紹介する。もちろん、実装者にとっては洒落にならないが。

以下のコードは、現行ドラフトの文面に従うと、well-formedなDartコードである。

main()
{
    a : { break a ; }
    b : { continue b ; }
}

なぜかというと、現行のDartのドラフト規格は、ラベル付きのbreak文とcontinue文は、label文の中に入ることができるとされている。ラベル文には、文を書ける。また、ブロック文も文である。よって、Label : { } はwell-formedなDartコードであり、その中でbreakやcontinueを使うのもwell-formedである・・・はずだ。

傑作だったのは、現行の実装が、このコードを実際にコンパイルできてしまうということだ。break文の方は、期待通りに動いた。つまり、

a : { print("before") ; break a ; print("after") ; }

は、beforeを出力する。

continue文の方は、コンパイルは通るが、実行時に、不思議なエラーを吐いて強制終了してしまう。もし規格通りに動いていたならば、無限ループになったはずだ。

この件はすでにバグ報告済みである。

DartのFlorian Loitschとのチャット

IRCのチャットで興味深かったチャットの断片をいくつか。

ezoe: 単項マイナス演算子をユーザー定義するにはnegateを使わないといけないのはちょっと驚きだね。
floitsch:何か代案でも?
ezoe:いや、別に不満ってわけでもないけど、理解するのに戸惑ったし、パースでも早くなるのかな?
floitsch:-は二項演算子にすでに取られてるからね。
floitsch:もちろん、引数の数を見て判断することもできるけど、それは他ではやってない処理だから、"operator negate"を導入することにした。
ezoe:なるほど、つまり例外的なルールを作りたくなかったのか。

ezoe:そういえば~/演算子ってのもあるけど、他の言語でこの演算子を使ってるのは知らないな。
floitsch:多分ないよ。
floitsch:切り捨ての除算が欲しかったんだ。
TheSheep://?みたいな?
floitsch:そうそれ。
floitsch:それも考えたんだけど、すぐ却下した。
TheSheep:他の言語でも使ってるよ。
TheSheep:特にpythonとかw
ezoe:一行コメントみたいだね。
TheSheep:あ!
floitsch:ほらね
floitsch:他の言語で、/や//以外で、切り捨て除算の演算子があるなら、教えてほしい。

ezoe:ふーむ、>>>演算子もあるね。
floitsch:イエス
floitsch:僕が推したやつだよ。
ezoe:どのコアライブラリが何のために使ってるの?
floitsch:なにも。
ezoe:えーと、まあ、ユーザー宣言可能な演算子が増えるってのはいいことだけど、でもコアライブラリすら使ってないんじゃ・・・
floitsch:>>>はunsigned shiftを意味する。
ezoe:>>は?
floitsch:signed shift
floitsch:そもそも、無限の精度をもった整数のunsignedな値って何さ?
floitsch:だから、コアライブラリでは>>>を定義していないんだ。

TheSheep:dartのintってjavascriptではどの型に対応するの? number?
floitsch:そう、JSのnumberさ。
TheSheep:それ固定精度じゃないじゃん。
floitsch:まあ、JSにコンパイルされたらdoubleさ。
floitsch:もちろん、それに起因する驚くべき挙動もそのままさ。
ezoe:なんだって?
floitsch:すべてのdartの数値は、JSのdoubleにコンパイルされる。
TheSheep:JSで動くツケさ。
floitsch:その通り
ezoe:そんなの整数じゃない・・・DartCが特別なコードを生成して多長演算をしてくれるかと思ってたのに。
floitsch:そりゃ遅すぎる。
TheSheep:そりゃ「遅い」
floitsch:そんなに悪くはないよ。
floitsch:ほとんどの数値は32bit以下だからね。
floitsch:それ以上が必要な場合は、開発者は分かるはずだ(Javaのlongとか)
ezoe:dart VMは任意の精度の数値を提供しているの?
floitsch:イエス

(末尾再帰最適化の話がでた後で)
ezoe:ファクトリーコンストラクターから同じコンストラクターをnew経由で呼び出してしまったことがある。俺は何を期待してたんだっていうw
floitsch:はは、結果を長く待たずに済んだことを祈るよ。
ezoe:でも、初心者は同じ間違いをすると思うんだ。
floitsch:直接の再帰呼び出しは、簡単に判定できるはずさ。
floitsch:IDEによって補足されて警告が出せるようになるといいかも。
ezoe:そうなってほしいな。うっかり書くこともありえると思う。

DartCではDartの数値をJavascriptのNumberにそのまま割り当てているとは驚きだった。JavascriptのNumberは、御存知の通り、内部的には浮動小数点数なのだ。まあ、大抵の場合は、その精度が気になることはないとはいえ、まさか規格で無限精度と定められているものを無視するとは。まあ、JSへのコンパイルは、移行措置のようなものなので、その程度の実装でも困らないのだろう。それより、数値計算の遅くなってしまうほうが問題だ。

ファクトリコンストラクターの条は、私がファクトリーコンストラクターを試したときに遭遇したうっかり間違いである。とりあえず、手っ取り早くファクトリーの文法を確かめようとして、以下のように書いてしまった

class X
{
    factory X()
    {
        return new X() ; // 再帰による無限ループ
    }
}

ファクトリークラスからは、別のコンストラクターを呼びださなければならない。

class X
{
    X.detail() { }
    factory X()
    {
        return new X.detail() ; // ファクトリーではないコンストラクターを呼び出す
    }
}

main()
{
    X x = new X() ; // ユーザーコードからはX.detailを使う必要はない

}

2011-10-16

数学を学ぶべきなんだろうか

Dartの規格に、次のような文がある。

The static type of null is ⊥.

The decision to use ⊥ instead of Null allows null to be assigned everywhere without complaint by the static checker.

現行のドラフト規格にはbeがニ連続するtypoあり。

この⊥が何を意味するのか分からなかった。しかたがないので、IRCで人に聞いた。

私:この⊥ってやつはなんだ?
人:"bottom"
私:bottom? 何かプログラミングか数学の用語なのか?
人:lattice theoryから来てる。
人:top(本当は特別な文字があるけど)ってのがすべての上にたつ汎用的な存在で、たとえばObjectだね。
人:bottomは何よりも特殊な存在なんだ。
私:つまり、bottomであるnullからみれば、すべての型はスーパークラスのようなものだということか。
人:そういうこと。

ちなみに、topの記号は⊤で、UnicodeではU+22A4である。⊥はU+22A5である。

なぜか、昔から数学はさっぱり理解できなかった。高校生の時、理系クラスに進もうとしたら、親に反対された。特に普段、勉強しろとも言わない親ではあったが、子供の勉強を反対するというのも奇妙だ。その時の言葉が印象に残っている。

「あんたに数学は無理よ。私達にだってできなかったんだから」

まるで、なにか遺伝的、先天的に数学ができないかような物言いだったのである。私の両親はそれなりに高学歴である。これは一体どういうことか。

親の案の定、私は数学をさっぱり理解できず、高校時代は、古文、漢文、英文を読んで過ごした。なぜか、私の親と同じ道をたどっているのである。

思えば、私も変な子供だったものだ。何故か昔から読書が好きだったし、小学生の頃には、すでに古事記や論語や徒然草などを読んでいた。もちろん、これは親がそのような本を家に置いていたし、「論語のどこそこ 」とか、「徒然草の第何段」といった会話が成立するほどの教養を持っていたからということもあるのだろうが、やはり不思議なことだ。何か、遺伝的なものがあるのだろうか。

今だって、私の感じるプログラミングの面白さとは、コードを書くのではなく、プログラミング言語の文法を理解することなのだ。何故こうなってしまったのだろう。

2011-10-15

DartのOptional Typeについて

Dartの素晴らしさがまだ分からない無知無識の者が、Dartの型システムについて深刻な誤解をしている。ここでは、Dartの型システムであるOptional Typeについて、ひとつ解説をする。これを読めば、Dartの如何に大昔のJavascriptより優れているかが、一目瞭然であろう。

強い静的な型付けは、C++のような、ほとんどを静的に決定する言語では非常に便利である。しかし、動的な言語では、むしろ邪魔にさえ感じる。

Dartの型システムは、Optionalである。型を明示的に書こうが書くまいが、自由である。

変数には、型を指定してもしなくてもよい。

var x = 0 ;
int x = 0 ;

関数の引数には、型を指定してもしなくてもよい。

int f( int x ) => x ;
f( x ) => x ;

ジェネリックのタイプパラメーターには、型を指定してもしなくても良い。

List<int> l = <int>[ 1, 2, 3 ] ;
List l = [ 1, 2, 3 ] ;

異なる型を代入することもできる。

int x = "肩のうしろの2本のツノのまんなかにあるトサカの下のウロコの右" ; // static type warning

これでは、型の意味が無いではないかと思う者もいるだろう。それは、Dartにおける型の目的を理解していないからである。Dartにおける型システムは、最適化のためにあるのではないのだ。ツールを助けるためにあるのだ。

まず、Dartの変数について一言説明しておかなければならない。Dartの変数とは、「メモリー上のストレージの場所を示す」ものである。これは、Javascriptのような言語に親しい物には、馴染み深い概念である。そのような言語に馴染みのないものには、とりあえず、ポインターだと考えておけばよい。もちろん、ポインターは、実際には異なる概念である。ポインターとは、やはり、メモリー上のストレージの場所を指し示す、すなわち「アドレス」を格納するために必要なだけのサイズのストレージであって、Dartの変数ではない。DartやJavascriptのような言語では、変数はすべてメモリー上のストレージへの参照であり、その参照を格納するストレージを意識することはない。

Dartにおける変数とは、内部的には、単にオブジェクトへの参照なのだから、型という仕組みがなかったとしても、不思議ではない。たとえば、DartやJavascriptでは、

var x = 0 ;
x = 1.5 ;
x = "肩のうしろの2本のゴボウのまんなかにあるスネ毛の下のロココ調の右" ;

このようなことができる。Dartにおける「代入」とは、単に変数が参照する場所を変えているだけである。変数自体は、固定されたストレージを持たないのだ。もちろん、実装上はストレージを持つが、それはユーザー側からは隠されている。

しかし、Javascriptのように、ソースコード上では、変数が型情報を持たないとすると、少々厄介である。

たとえば、ある変数はある型だと想定して使っているのに、うっかりと別の型を代入してしまったばかりに、型が変わってしまう。もちろん、コンパイルエラーどころか、警告すら出せないので、このバグを探すのは非常に難しい。プログラマーは、自分の目でバグを探さなければならないだろう。

Dartにおける型とは、言わばannotationなのだ。

int x = 0 ;
x = 1 ; // OK
x = 1.5 ; // Static type warning.

このように、型が合わない場合、コンパイル時に警告を出すことができる。そのため、プログラマーは目でコードを探す必要がなくなる。

現代では、IDEによるコード支援が盛んである。例えば、識別子を補完したり、メソッド名を補完したりしてくれるのは、非常に便利である。ところが、Javascriptのように型がないと、これは少し難しい。

var x = "肩ぐるまして後ろ向きに乗り2本のゴボウを持った歌舞伎顔の男" ;
x. // ←ここに注目

xという識別子に続いて、ドットを使っているのに注目してもらいたい。賢いIDEならば、ドットを打った時点で、プログラマーはメソッドを呼び出したいのだと解釈し、メソッドの一覧を表示してくれることだろう。ただし、この場合、xの型を静的に求めるのは難しい。

上記のような二例であれば、静的な解析でも可能である。ところが、Javascriptには、不可能な場合もあるのだ。

function f( x )
{
    x. // xは何かって? (´・ω・`)知らんがな
}

これはどうしようもない例である。

Dartでは、型をannotationのように指定することができる。そのため、静的ツールは静的に型を決定することができる。

f( String x )
{
    x. // Dartならば、IDEによってメソッド名の一覧を表示可能(`・ω・´)シャキーン
}

文法上、型を書くことができるというのは、コメントで書くよりもずっと分かりやすい。

var x = 0 ; // type of x suppose to be int. 
int x = 0 ; // horay! no comment is needed!

しかし、実行時に型が一致しなくても、エラーとはならない。つまり、実行を続けることができるのだ。ただし、警告は出るので、バグを見つけることができる。もし、型を固定したくなければ、varを使うこともできる。自由である!

2011-10-14

Dennis Ritchieに関する良記事

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

氏の死去を始めて公にしたページ。

Dennis Ritchie, 70, Dies, Programming Trailblazer - NYTimes.com

NY Timesの記事。個人的な経歴もまとまっていて、なかなかの良記事。

Dennis Ritchie « Sutter's Mill

Herb SutterによるRitchieの回顧。Ritchieは、それまで不可能だと言われていた、portableでefficientな言語を発明した男である。

Interview with Dennis Ritchie, Bjarne Stroustrup, James Gosling

Herb SutterによるRitchieへのインタビュー。Ritchieは、ほとんどインタビューを受けない男であったので、貴重である。

2011-10-13

何故Dartが史上最高の言語なのか

史上最高にして、恐らく今世紀最高となるプログラミング言語は、Dartである。DartはC++以外の既存のプログラミング言語のほとんどを駆逐する事ができる潜在性能を持っている。これからの真のプログラマーは、C++とDartという二大言語に加え、目的に応じて、アセンブリやシェーダーなどの専用言語を学ぶことになるだろう。

Dartの美しさを理解出来ない近眼者が、愚にもつかぬ批判をしている。恐らく、彼らは規格書が読めないのであろう。曰く、「Javaのパクリ」、曰く、「目新しい新機能がない」。Javaのパクリという阿呆は、Javaのような聳え立つ糞の信者なのだろう。ただJavaと同じようなキーワードや文法を使っているからといって、それがJavaのパクリであるとは片腹痛い。Dartからみれば、Javaなど歯牙にもかけぬ愚物である。目新しい機能がないという批判もあたらぬ。およそ斬新な新機能というのは、人目を引くのは確かだが、一般に普及しがたいものである。

Dartは、すでにその価値を証明されている機能を、ごく自然に提供している言語である。いや、重要なのはむしろ、提供していないモノにこそある。Dartは、他の言語にあるような、不必要なクソを提供していない。例えば、パースが難しかったり、時間がかかるようなcontext sensitiveな文法はないし、複雑怪奇な暗黙の型変換も存在しない。この点において、改行が終端記号とみなされるJavascriptは、近い将来にDartの後塵を拝する事になるであろう。

Dartの主目的である、Javascriptの置き換えという目的には、ソースコードのコンパイルを高速に行えることがまず第一である。それには、パースが難しかったり、文脈に依存して意味が変わったりするような文法を、極力避けるべきである。Dartはこの点において、特に優れている。

例えば、Dartでは、二項マイナス演算子と、単項マイナス演算子をオーバーロードすることができる。二項マイナス演算子のオーバーロードには、おなじみの、-という記号を使えばいいのだが、単項マイナス演算子のオーバーロードには、negateというキーワードを使用する必要がある。

class C
{
    C operator - ( C other ) => this ; // binary minus
    C operator negate () => this ; // unary minus
}

main()
{
    C c = new C() ;

    c - c ; // binary minus
    -c ; // unary minus
}

これは恐らく、パースを高速にするためであろう。operator -と読み込んだならば、その時点で、それは二項マイナス演算子のオーバーロードであると決定できる。

例えば、Dartには正規表現ライブラリがあるが、正規表現リテラルは存在しない。これも、パースを高速に行うためであろう。そのかわりに、DartにはRaw String LiteralやMultiline string が存在する。

// Raw string literal
@"\n\r\f" ; 

// Multiline string
"""もんちゃらへっぴー
もけもけさー""" ;

まだ書きたいことは様々あるのだが、ともかくDartの規格書をすべて読んでしまわないことには、詳しい説明をすることができない。Dartを批判する前に、まず規格書を読んでみるべきである。今の実装はまだ不完全で、バグも多い。言語を実装によって判断するのは愚か者のすることである。とにかく重要なことは、Dartは今世紀最高のプログラミング言語であり、輝かしい未来が約束されているということだ。

デニス・リッチー逝去

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

Steve Jobsより、こっちの方が大ニュースだ。しかし、リッチーは世界に多大な影響を与えたにも関わらず、あまり表にでない人物であった。もしリッチーがいなければ、今日のプログラミング言語は、かなり別の文法を使っていたかもしれない。

2011-10-12

Dartすごい。マジすごい。美しい

Dart : Structured web programming

というわけで、Dartが発表されてからこのかた、Dartの規格を読んでいたのだが、これはすごい。マジですごい。ヤバイほどすごい。美しすぎる。

私が多少なりともかじっている言語は、C++とJavascriptとアセンブリである。私は、もうこれ以上、学びたいと思う新言語が出てくるとは思っていなかった。たしかに、C#はWindowsでアプリを作るには面白そうだし、PythonやらRubyやらは、かなり人気だ。しかし、これらの言語を学びたいとは思わなかった。昔、Schmeに興味を持ち、SICPを買った。しかし、未だ綺麗なまま、本棚の中に眠っている。Haskellに興味を示したこともあったが、やはり最初の感動が覚めると、学ぶ気にはならなかった。つまりは、わざわざ学ぶほどの魅力がなかったのだ。しかしどうやら、私は間違っていたようだ。Dartが来た。

Dartは美しい言語である。規格書を読むと、その美しさが一目瞭然である。従来のどの言語にもない完璧なまでの美しさを備えている。

Dart Programming Language Speci cation

まず、規格書が短い。現在のドラフトは、たったの78ページしかない。この規格書は、コア言語だけを定義している。この短さには理由がある。Dartのコア言語は、美しいほどにシンプルだからである。

たとえば、Dartには、暗黙の型変換が、boolean conversion以外に存在しない。Javascriptのように、改行が文脈によっては終端記号と解されるような仕様もない。この美しい言語を設計したのは神ではなかろうか。よくぞここまで思い切ったものだ。

ときくと、そんな厳格な言語がWebのクライアント言語として使えるはずがないと思う人もいるかもしれない。実は、暗黙の型変換のチェックは、コンパイルエラーとはならない。静的型警告(static type warning)が発せられるだけで、コンパイルには影響を及ぼさない。たとえば、

void main
{
    int x = 0.1 ; // static type warning
    print("${x}") ;
}

これは、静的型警告を出すが、コンパイルや実行には、何の影響もない。もちろん、出力も、0.1である。これは、あたかもvar x = 0.1 ;と書いたかのように振る舞う。

記述は厳格に、実行は寛容にというのが、過去に成功したWeb上でのクライアント言語に共通する理由である。HTML然り、Javascript然り。Dartはこの点からみても、失敗する余地はない。

コア言語側には、組み込み型というものがない。intやdoubleといった基本的な型でさえも、ライブラリである。

そして重要なことに、DartはJavascriptの代替として、Chromeに組み込まれることが決定している。もちろん、DOMも使える。

とにかく、Dartは信じられないほどに美しい言語だ。早くこの言語でプログラミングがしたい。Dartが使えるようになれば、Javascriptなどは即座に絶滅してしまうだろう。

おいおい、オメーのブラウザ、Dartも使えねーのかよ。さっさとDartが使えるブラウザーにしろよ。

下駄の鼻緒が切れた

「下駄の鼻緒が切れると縁起が悪い」という迷信があるが、あれは迷信などではなく、事実である。

私はここ二年ほど、下駄を愛用している。何故いまどき下駄なのかと不振に思う人もいるだろう。これは、特に下駄を履くことによる不利益がないからである。

まず、下駄の値段は数千円であり、通常の安い靴と何ら変わりない。私の使用頻度では、下駄は一年ほど使えるので、この点においても、安物の靴と何ら変わりない。走るのではなく、長距離を行くのでもなければ、靴と比較した場合の不利益がほとんどないと言って差し支えない。

唯一の不利益といえば、下駄を履くと足が汚れるので、玄関先で足を洗ってから上がらなければならないことぐらいだ。歌舞伎や昔の時代劇などで、家に上がる前に、足を拭く動作がみられるのも、このためである。

ところで、今朝、下駄を履いて歩いていると、突然、下駄の鼻緒が切れた。見ると、下駄の歯があまりにも擦り切れていて、鼻緒をかけている縄が地面に接触するようになったため、次第に縄がすり切れていき、とうとう切れたらしい。以前の下駄は、そうなるまえに下駄の歯が完全にすり切れてしまったので、鼻緒が切れる前に買い換えたのだった。

当然、その場で思い当たったのは、「下駄の鼻緒が切れると縁起が悪い」という迷信である。今日、私は、この迷信が、実は事実であるということを身を持って思いしらされた。

下駄の鼻緒が切れたせいで、その下駄を履いて歩けなくなってしまったのだ。仕方なく、私は下駄を脱ぎ、裸足で歩いて帰らざるをえなかった。この不便は、下駄の鼻緒が切れたという事象によってもたらされたものである。下駄の鼻緒が切れたという直接的な理由で不便を被ったのだから、「下駄の鼻緒が切れると縁起が悪い」という迷信は、実は正しいと言える。

2011-10-07

欧陽修の未発見の書簡、発見さる

日本で宋・欧陽修の書簡…中国で「盗んだ」、「韓国でなくて幸い」 2011/10/06(木) 17:38:42 [サーチナ]

九州大大学院比較社会文化研究院の東英寿教授は3日、宋代の政治家で詩人・文筆家として知られる欧陽修の書簡96篇を発見したと発表した。中国でも同ニュースは報じられた。かつては「13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」と紹介されたが、「日本が中国から盗んだものだ」などのコメントが寄せられた。「発見されたのが韓国でなくて幸いだった」との書き込みもある。

天理大学付属天理図書館が所蔵していた1191-96年に編纂(へんさん)された欧陽修全集「欧陽文忠公集」に、これまで知られていなかった欧陽修の書簡96篇が掲載されていた。同「公集」は木版による原刻本。中国国家図書館や日本の宮内庁も所蔵しているが、天理図書館所蔵の原刻本は、編纂作業が終わってから、抜け落ちていた書簡を追加した版であるとみられる。

環球網などの記事は「(日本側が古い時代に)中国で購入し、13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」「日本では国宝に指定」などと紹介したが、コメント欄には「日本が戦争中に中国から盗んだものだ」、「中国の文化財だ」などの書き込みが相次いだ。

「幸いなことに、(発見場所は)韓国でなかった」などと主張する書き込みも多い。「『欧陽修は韓国人だった』とされてしまう可能性が100%」だからという。

どうせ中国にあっても度重なる革命や、記憶に新しい文化大革命で焚書されてるだろうに。それにしても、このニュースは自己言及的である。なにしろ、あの欧陽修である。あの日本刀歌をつくった欧陽修である。

徐福行時書未焚
逸書百篇今尚存
令厳不許伝中国
擧世無人識古文

2011-10-06

スティーブ・ジョブズ死亡

Apple - Remembering Steve Jobs

Apple社はヴィジョンとクリエイティビティあふれる天才を失い、世界は驚嘆すべき男を失った。幸運にも彼を知り、ともに仕事をした者は、最良の友であり師でもある人物を失った。スティーブは彼以外に成し遂げられぬ会社を後にして旅立った。彼の魂は、Apple社に生き続けるであろう、永遠に。

スティーブ・ジョブズ:自分の立ち上げた会社をクビになったが、後に買収しなおした、世界一カリスマのあった男。すい臓がんにより2011年に没す。享年五十六歳。

非staticデータメンバーの初期化子

今月にビルドされたgcc4.7で対応していることを確認。

struct S
{
    int member = 123 ;
    S() = default ;
    S( int value ) : member(value) { }
} ;


int main()
{
    S s1 ; // s.member == 123
    S s2(456) ; // s.member == 456
}

なお、非staticデータメンバーの宣言にauto specifierを使うことはできない。これは、auto specifierが、ブロック、名前空間スコープ、for文の初期化句にしか使われてはならないとされているためである。

struct S
{
    auto member = 0 ; // error
} ;

ちなみに言っておくと、staticデータメンバーにはauto specifierを使うことができる。これは、staticデータメンバーが、実は名前空間スコープであるからだ。staticデータメンバーは、クラス定義の中に書かなければならないとか、クラス名による修飾をしなければならないなどの制約はあるが、名前空間スコープに属する名前である。

struct S
{
    static auto const member = 0 ; // OK, type is determined to be "const int"
} ;

もちろん、staticデータメンバーに初期化子が許されているのは、constなリテラル型だけであるので、autoがそれ以外の型に推定された場合は、エラーとなる。

struct S
{
    static auto member = 0 ; // Error, the type of static member is not const literal type.
} ;

ちなみに、gccには七ヶ月前、上記のコードを通してしまうバグがあったが、バグレポートを送ったところ、現在では修正されている。

2011-10-03

花粉症?

ここしばらく、体はだるくないし熱もないが、謎のくしゃみと鼻水と目のかゆみに悩まされている。一日中というわけではなく、起きた直後がひどいように思われる。

さて、思いつく病気は花粉症だが、果たして。

2011-10-01

火の用心に効果はあるのか

毎年この時期になると、拍子木をやかましく打ち鳴らして「火の用心、火の用心」と叫ぶ集団が出現する。果たして、あれはなにか意味があるのだろうか。あれを聞いたことで、用心を心がける人間が、果たして存在するのだろうか。近所迷惑だとは思わないのか。

目の前に火鉢や囲炉裏がある時代は知らず、現代では、常に火を灯している場面は、少なくなっている。

たとえば、電子機器や配線からの発火は、少なくとも発火するまでは、火は存在しない。それに、発火するまで事前の兆候がなく、またコレといった対策も取りづらい問題である。

そもそも、現代の火災の原因の最上位は、「放火」である。

参考:総務省消防庁

放火は、いくら個人が用心しようとも防ぎようがない。ある人間が火をつけようと考えたならば、その手段を手に入れるのは、この日本ではたやすいことであるからだ。

次いで、「たばこ」が原因としてあげられる。これは、用心できる種類の原因である。

ということは、あの集団は「火の用心、火の用心」と叫ぶよりも、「禁煙、禁煙」と叫んだほうが効果的ではないだろうか。

それにしても日本は、廃品回収といい、古紙回収といい、騒音に対する規制が緩いように思われる。

ついさっきも、家の前を「火の用心」と叫びつつ通過する集団がいたので、このような疑問をぶつけてみた。彼らの言い分は、実に不思議である。

私「何故このようなことをしているのか、近所迷惑だとは思わないのか」
翁「町内会で決まっている。学校からも要請がある」
私「それで何の疑問も抱かずやっているのか」
翁「そうだ」
私「誰が決めたのか」
翁「町内会の代表である私が決めて、私がやっている」
私「自分で決めて自分でやっているのか」
翁「町内会で誰も反対しなかった」
私「そもそも、効果があるのか」
翁「ついこの間もこの近所で火事があって云々」
私「それで効果はあるのか」
翁「これを聞いて用心する人が少しでもいればそれでいい」
集団「この人頭おかしいんやわ、ほっといていこいこ」

集団は、なおも質問しようとする私を、「頭がおかしい」と言い捨て、過ぎ去っていった。この翁は、いつも家の前でタバコを吸っている翁である。ために、公道が煙たくてしょうがない。火災の原因No.2の喫煙者が火の用心を叫ぶのは不思議だ。

2011-09-30

今年のイグ・ノーベル賞の日本人受賞者は8人

まず、名誉ある受賞から、今井真(滋賀医科大学講師)、漆畑直樹、種村秀輝(シームス)、田島幸信(香りマーケティング協会理事長)、後藤秀晃、溝口浩一郎(エア・ウォーター防災)、村上純一(琵琶湖病院)の七名の者は、イグノーベル化学賞を受賞した。これは、眠っている人を起こすのに最適な空気中のわさび濃度を発見したためである。これは、火災などの警報器で、聴覚障害者を起こすのに使われる技術である。

不名誉な受賞は、麻原彰晃とその他大勢の終末予言者、世界は1997年に終わると予想し、数学的予想と計算には注意すべきだと、世界に知らしめたことをもって、イグ・ノーベル数学賞を受賞した。

2011-09-27

クッキーモンスター

「オ゛ー、ミ゛ー ラ゛フ゛ ク゛ッキ゛ー オ゛ー イ゛ェア゛」
~都道府県ドメインについて、クッキーモンスター

「ちょっと待てや」
~都道府県ドメインについて、高木 浩光

高木浩光@自宅の日記 - JPRSに対する都道府県型JPドメイン名新設に係る公開質問

以下は素人丸出しの説明である。

cookieは、今日のWebサイトにとって、非常に重要であると同時に、プライバシー、セキュリティ上、気を付けなければならない機能でもある。あるWebサイトによって設定されたcookieが、全く別のWebサイトによって読み込まれることがあってはならない。このため、cookieにはsame origin policyがある。異なるドメイン間では、基本的にcookieを共有できないのだ。example.comで設定されたcookieは、example.orgからは読み込むことはできない。

ところで、今私がexample.comというドメインを取得し、Webサイトを運営したいとする。この場合、第三レベル以降のドメインは、自由に名付けることができる。自作の音楽は、music.example.comで公開し、ブログはblog.example.comで公開するとしよう。この二つのドメインは、異なるものであるから、cookieは共有できない。しかし、このドメインは、どちらもexample.com下にあるものであり、私の所有するドメインであり、私の運営するWebサイトである。したがって、このふたつのドメイン間でcookieを共有できたとしても、セキュリティ上の問題にはならない。

そこで登場するのが、super cookieである。このcookieは名前の通りスーパーなクッキーなので一部ドメインを指定しないことができる。たとえば、.example.comを指定すれば、music.example.com、blog.example.comまた他のあらゆる、「任意.example.com」で共有することができる。

しかし、もしこのスーパーなcookieを、.comに対して指定すればどうなるだろうか。この場合、私の所有するexample.comだけではなく、トップレベルドメインがcomでさえあれば、どのドメインからでもスーパークッキーの読み書きができる。これはまずい。

もちろん、問題はcomだけではない。トップレベルドメインはもっとたくさんある。では、トップレベルドメインに対するスーパークッキーを禁止すれば、問題は解決するのだろうか。

例えば、example.co.jpは、co.jpまでがパブリックなサフィックスである。トップレベルドメインの禁止だけでは、この問題を解決できない。

問題の解決方法とは、パブリックなサフィックスのリストを作成し、スーパークッキーの指定が、そのリストに該当するときは、使用を禁止することである。これは、クソなサイトからユーザーを守るためにも、ブラウザー側で対処する必要がある。

今、都道府県のサブドメインを導入するということは、日本全国の47都道府県の分だけ、パブリックサフィックスが相当に増えることになる。もし市町村も導入ということになれば、1722市町村。もちろん、これはブラウザーをアップデートすることで対処しなければならない。誰がやるというのか。アップデートされないブラウザーはどうしようもない。

明らかに、極東の小国は非常に重要なので、時にはこんな乱暴も許されるのだろう。

2011-09-26

GCC 4.7で非staticデータメンバーに初期化子が使えるようになったらしいが

C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)

なんと、Non-static data member initializersがGCC 4.7で実装されているという。早速試してみようと、昨日ビルドされたばかりのgccのバイナリを落とした。さっそく試してみたが、sorry, unimplementedと表示される。何故だろう。

struct X
{
    int member = 0 ;
} ;

2011-09-25

説経

今日は気分転換に、本物の日本語を読むことにした。私の言う本物の日本語とは、数百年前に書かれて、今なお読まれている文章のことである。まだ書いた当人の生きているような新しい文章は玉石混淆であり、しかもほぼすべて石である。数百年前以前に書かれて、今なお読まれている文章は、名文の可能性が高い。路傍の石の中から玉を拾うより、世間から何百年も玉だと言われ続けている石の中から玉を探すほうが簡単である。ちょうどブックオフで、新潮日本古典集成の説教集が投げ売られていたので、それを読むことにした。

今からたったの400年ほど前、日本には説経説き、または説経者と呼ばれる下層階級の芸人がいた。彼らは当時、三十三間堂の境内で、大きな傘をかざし、ササラと呼ばれる、竹で作った、こすりあわせて音を鳴らす原始的な楽器を擦り鳴らしながら、地蔵や仏像の由来を往来の人々に説き聞かせ、おひねりを得ていたのである。

三十三間堂の近くに住む者として、これがどうにも実感がわかない。今の三十三間堂は、決して無料見はさせじとばかりに周りを厳しく塀で取り囲み、たった一箇所の入り口から、拝観料を払って入る、まあなんとも近代的で罰当たりな商業施設である。地獄で銅の湯を飲ませられることは、まず間違いあるまい。それが、かつては人通りの激しい往来であり、しかもこのような所謂「ササラ乞食」の商売の場所であったとは。今の四条大橋のような雰囲気だったのだろうか。

さて、恐らく説経の中で一番有名な話は、「さんせう太夫」であろう。これは、森鴎外の「山椒大夫」という小説のためである。しかし、実際に説経のさんせう太夫を読んでみると、森鴎外の作品は、単なる劣化コピーに過ぎないことが分かる。もちろん、当時の説経説きと森鴎外とでは、力の入れどころが違うというのもあるが、原典はさすがに強烈である。安寿は凄惨な拷問によって焼き殺されるし、返り咲いたつし王丸がさんせう太夫に行う報いも、やはり残酷な処刑である。また、誓文の文句も興味深い。

2011-09-23

スライム冒険記が面白い

コンビニでは、懐かしのマンガを再録したペーパーブックが売られている。今日、ふと売り場を見ると、興味深い本が売られていた。スライム冒険記である。

スライム冒険記とは、かねこ統によって描かれ、当時のVジャンプで連載されていた、ドラクエの世界観を元にしたギャグマンガである。灼熱炎が吐けるボケキャラのスライムのスラきちと、ツッコミ役の山賊ウルフのウルフ、その他のドラクエにおなじみのモンスター達が、なんとなく勇者を目指す物語である。

作風は、随所に鳥山明へのオマージュが感じられる。

なんとなく、ドラクエ4コママンガ劇場を読み返したい気分になった。思えば、ドラクエ4コマからは、かなり良質なマンガが生まれた。衛藤ヒロユキしかり、柴田亜美しかり。思えば、エニックスは、ゲームだけではなく、出版事業でも、結構新しいことをしていたのだな。今は見る影もないが。

しかし、どうも今、ドラクエ4コママンガ劇場は売られていないようだ。中古を手に入れるしかないのだが、近所のブックオフには見当たらない。クレカさえあれば、アマゾンの中古市場から買えるのだが。

早いところ執筆を終わらせて、まじめに働かなければなるまい。

2011-09-21

日本語の限界を感じる

C++の参考書を書くのがつらい。どうも、日本語という言語の限界を感じる。

日本語で技術書を書くのは、苦痛極まりない。どんなにわかりやすく言葉を選ぼうと、結局やっていることは、英語の翻訳でしかない。それならば、最初から英語で書けばいいではないか。明治になってから、医学はドイツ語から翻訳されたオランダ語ではなく、元のドイツ語で学んだように、プログラミングも英語で学ぶべきなのだ。確かに、一般人は翻訳で学んだが、専門家たる医者は原語で学んだのだ。専門家であるプログラマーも原語で学ぶべきである。

実際のところ、今や、もはや参考書というもの自体が時代遅れなのではないかと思う。何故ならば、誰もが一次ソースたる規格書を読むことが出来るからだ。まあ、C++はISOの規格なので、規格書は無料ではない。とはいえ、たったの352スイスフランだ。クソの役にも立たぬ参考書を何冊も買うより、規格書を買ったほうがいい。

むしろ、今の時代に日本語のプログラミングの参考書を出しても、害悪でしかないのではないかと思い始めている。日本語の資料がなければ、まともにプログラミングを学びたいものは、自然と英語を学ぶようになるはずだ。かつて私は、プログラミングを学ぼうとしたが、まともな日本語の参考書がなかったので、まず英語から学ぶことにした。この2011年になっても、まともな日本語の参考書が存在せず、世間一般に良書とされている日本語の参考書は、すべて英語からの翻訳(それもかなりひどい翻訳)であるという事実からしても、私の取った戦略は正しかったといえる。

とすれば、日本語の参考書をこれ以上増やしても、害悪でしかない。

結局、今の私は、自分自身が全く必要としていない、それどころかむしろ、害悪であるとまで考えるような参考書を書いているわけだ。道理でつらいわけだ。

追記:確かに、352スイスフランは、個人で買うにはちょっと高い。恐らく来年頃には、ANSIから数十ドル程度の値段で、規格書が買えるようになるはずだ。

2011-09-16

プログラミングの魔導書 Vol.2の予約受付中

株式会社ロングゲート - 製品案内
『プログラミングの魔導書 Vol.2』予約開始! - Faith and Brave - C++で遊ぼう

プログラミングの魔導書 Vol. 2の予約受付が始まった。今回、私はDave Abrahamsへのインタビューを敢行し、また、constexprの入門記事を書いている。

Dave Abrahamsは、C++プログラマーでその名前を知らなければモグリであるほどの有名なプログラマーである。

私自身のconstexpr記事は、constexprを紹介する入門的な記事である。まだ、constexprの具体的な活用例が少ないので、応用よりもむしろ、基礎を書いたほうがいいと思ったのだ。constexprをまったく知らない読者は、この記事を読めば、constexprの機能と使い方は、ひと通り分かるであろう。逆に、constexprの応用を期待している読者は、失望するかもしれない。

紙媒体が好きな人は、紙を注文できるし、電子媒体を好む人は、お世辞にも電子書籍として優れているとは言えないフォーマットであるPDFを買うこともできる。

ともかく、ようやく二冊目の刊行となったわけだ。今回は、前回のように理想を語るのではなく、批判をしようと思う。魔導書はこれから、方向性を変えるべきであると思う。電子媒体に絞るべきなのだ。

紙媒体は、すでに終わっているコンテンツである。コンテンツを印刷物で公開するのは、非常に労力がかかる。今の規模では、まあ、年に一冊が関の山だろう。これは思えば、非常に不思議である。何故ならば、今日び、コンテンツというものは、一瞬にして全世界に公開できるからだ。

たとえばこのブログだ。この本文は、書き終えた後、即座に公開されている。この文章は念入りに校正されていない。おそらくはtypoを含むだろうし、同じ助詞の連続などの、読み易くない文章も含まれている可能性もある。とはいえ、そんな誤りは些細なものである。感じの誤変換であるとか、てにをはな間違いだあるとかは、一見して明白であり、読者は容易に本来の意図した意味を推測できるであろう。それよりも、コンテンツの作成、公開にかかる労力を削減できれば、コンテンツ作者はより積極的にコンテンツを作成することができるようになり、世の中により多くの良質なコンテンツをもたらすのだ。

現代の技術を持ってすれば、一瞬で可能なことに、半年以上もの時間を費やす。無駄の極みにはあらずや。例えば、いまだに活字拾いから始めたり、写本したり、レコードで音楽を聞いたりするような無駄さ加減だ。もちろん、道楽としての活字拾いや写本やレコードを否定するつもりは毛頭ないが、それは趣味や道楽だからこその芸当であって、真面目なプロジェクトでは、やはり無駄である。

しかるに、プログラミングの魔導書は、いまだに紙媒体に固執しているため、実際の記事自体は何ヶ月も昔に完成しているというのに、印刷という障害物のせいで、半年がかりの労力になっている。これは明らかに、時代遅れである。

追記:組版自体は一ヶ月ほどでできるらしい。

たとえば、インタビューも今年の前半に行われたが、公開するまでに何ヶ月もたってしまっていては、せっかくの価値も減じてしまう。私の書いたconstexpr記事だって、当時のドラフトを参照にしていたので、最終的なC++11とは少し違ってしまっている。これはできるだけ修正したが、どうしても付け焼刃的な感は拭えない。FDISが当時読めていたならば、こうは書かなかっただろうという箇所も多い。これは、C++11発行の最終段階のツメの作業を行なっている途中での執筆だったので、仕方がないといえば仕方がないが、魔導書の発行が遅すぎるとも言える。

PDFの問題は厄介だ。PDFは印刷を前提としたフォーマットであり、電子書籍のフォーマットには適していない。電子書籍は、あくまでコンテンツを記述するフォーマットを使うべきである。コンテンツをどのように表現するかというのは、クライアント側の仕事だ。フォント、文字色や背景色、余白、さらには禁則処理や文字のツメやアキなどといった組版は、クライアント側が表現すればいいのだ。

2011-09-15

C++11のattributeは流行らない

世間では、Windows 8(仮称)の詳細の発表に湧いている。とうとう、Windows 8のDeveloper Preview版が公開されたのだ。同時に、かねてから噂されていた、Metroの詳細や、プログラミング方法も公開されている。

Building your first Windows Metro style app using C#, C++, or Visual Basic

では、さっそくC++のコード例を見てみることにしよう。

// C++
// ...
void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
    DisplayText->Text = "Hello World";
}

ん? 何か違和感を覚える。非常に気になるが、先に進もう。

Platform::String^ _title;
Platform::String^ _author;
Platform::String^ _pubDate;
Platform::String^ _content;

何じゃこのdeclaratorらしき^は?

はよう、MSの独自規格スパゲッティ量産言語、C++/CLIというものならん。

と考えた私の予想はるかに上回るクソ仕様であった。

Windows Runtime objects and ref new

Note that you use the ^ (“hat”) symbol instead of the pointer dereference operator (*) when declaring the variable

そんな馬鹿な。C++/CLIではない、通常のネイティブコードを生成するC++に対する拡張だというのか。やおれMSよっく聞け。そちはC++を何と心得る。偉そうに口ヒゲなど生やしてる場合か。もっとも、最近は剃っているそうだが。そもそも、declaratorとしての*は、declaratorであり、ポインターデリファレンス演算子ではない。爾、C++規格を知らざる者にドキュメントを書かせたるか。

結局、これがMSの選択か。attributeではなく、特別なdeclarator、^を選んだということか。

もちろん、MSを標準規格に従わない、常に独自規格を再発明する、独裁者だと批判するのは容易であるが(実際、その通りであるが)、もう少し考えてみる。MSはdeclaratorに^を使うことには、合理的な理由がある。C++/CLIで全く同じ構文を提供しているので、実装経験と実績があるのだ。この構文に決定するにあたって、既存のC++コードとの互換性を保てるかどうか、相当な検証を行ったはずである。C++/CLIとは、既存のC++のコード資源が使えるという利点のみが、C#より優れているのであって、C++のコード資源の利用が必要なければ、まともな頭をしていれば、普通はC#を選ぶはずだ。

もちろん、attributeも互換性に関しては申し分ないが、実装経験の差で、選ばれなかったのだろう。実際の実装で使われないならば、規格には意味がない。

言語拡張自体は、悪いことではない。C++の標準規格は、どの実装でも必ずサポートされるべき最小限の必須機能だけを規定している。たとえば、C++98の時点では、アライメントの指定は、あらゆる環境でサポートされるべき必須機能ではなかった。それ故、MSVCやGCCその他の、アライメント指定を必要とするコンパイラーは、#pragmaや独自のキーワードを用いた言語拡張によって、アライメント指定をサポートしていた。

C++11では、このような言語拡張の中でも、とくにコードに付加的な意味を与える要素に着目して、attributeという文法を付け加えた。これを使えば、独自の汚いキーワード(例:__declspec、__attribute__)を導入することなく、言語拡張が行えるはずであった。少なくとも、机上の理論ではそうであった。

しかし、__declspec(hogehoge)と[[hogehoge]]では、汚さには余り変わりはない。むしろ、attributeの方が見た目に宜しくないとも言える。

だいたい、C++11の機能からして、当初attributeで提供されるはずだった、アライメント指定やoverrideやfinalといった機能は、「公式な標準規格の言語機能は独自のキーワードを与えられる資格がある」という理由で、独自のキーワードを与えられた(厳密に言うと、キーワードではなく、contextual keywordなのだが)。あとに残ったのは、carries_dependancyとnoreturnという、まあ、言わば、それほど重要ではない機能だけである。

おそらく、attributeはasmと同じ轍を踏むだろう。どの実装からも顧みられることなく、黒歴史となるのだ。

2011-09-13

EUで音楽の著作権が70年に延長されるそうだ

BBC News - Rock veterans win copyright fight

ビートルズの録音は、あと数年で著作権が切れるはずだった。しかし、この法改正で、著作権は存続するようになった。情けない話だ。どうせ、20年後にも、保護期間をさらに延長するように法改正されるに決まっている。過去の栄光にしがみつくようでは、音楽はこれ以上成長しないだろう。

日本ではどうなるのだろう。ビートルズの最初の音楽、Love Me Doは、1962年に録音、発表されている。日本では、映画以外の団体名義の著作物の保護期間は、50年である。ビートルズは団体であろう。とすると、日本では、2013年以降は、Love Me Doの当時の録音の著作権が切れるのだろうか。

問題は、たとえビートルズの著作権が切れた所で、私にとってはあまり意味がないということだ。世代が違いすぎる。まだレコードという物理的な音溝に針をあてて音を再生する古代の装置を使っていた時代の話なのだ。

2011-09-12

post-Bloomington mailingの簡易レビュー

post-Bloomington mailingが公開された。

ISO/IEC JTC1/SC22/WG21 - Papers 2011-09

N3301: Defect Report: Terminology for Container Element Requirements

見逃していた文面上の僅かな誤りを修正。

N3302: Constexpr Library Additions v2: complex
N3303: Constexpr Library Additions v2: chrono
N3304: Constexpr Library Additions: containers
N3305: Constexpr Library Additions: utilities v2

それぞれのライブラリーで、constexpr化できる関数をconstexprにする変更。

N3306: A Proposal to Tweak Certain C++ Contextual Conversions, v2

幾つかの場所では、式の評価には、ある種の制限が課せられる。例えば、if文やwhile文のオペランドの式を評価した場合、boolに変換可能であることが求められる。このような制限を、規格では、contextualという用語を用いている。

ところで、規格の文面中に、このcontextualとよく似た意味を、それぞれ別の言葉を使って表現している箇所が、4箇所ある。その箇所では、オペランドがクラス型であった場合、期待される型への、「唯一の非explicitな変換関数」が求められている。

この4箇所の言葉を統一するために、新たな用語、contextually implicitly convertedを定義して、その用語に置き換えようという提案。

N3307: Issues Found Implementing C++0x

C++0xを実際に実装している途中で見つかった不具合集。多いので説明はしないが、興味深い問題も多い。特に、constexprと例外指定に関する問題が多いように思われる。例外指定は、私の印象では、些細なものが多いが、constexprは厄介だ。

しかし、いくつかの問題を解決するためには、それなりに大きな変更が必要になる。例えば、ある問題を解決するためには、テンプレートコンストラクターも、コピー/ムーブのコンストラクターとし、他のあらゆる箇所を、それに対応して修正し、さらに既存のコードの意味を変えないために、テンプレートなコピー/ムーブのコンストラクターは、暗黙のコピー/ムーブのコンストラクターの生成を妨げないという条件も付け加えなければならない。

N3308: constexpr consternation

constexprの原案では、constexpr関数を前方宣言することはできなかったし、定数式の入力に対しては、常に定数式を出力しなければならなかった。そのような制限は後に変更されたが、文面上では、その変更を正しく適用できていない箇所がいくつかある。その修正案。

ちなみに、今回のcore active issuesは、タイトルだけで詳細が書かれていないものが多い。これは、次のmailingで修正される予定らしい。

しかし、今書いているC++の参考書は、ある部分では1年以上前のドラフトを参考にして書かれたので、今とはだいぶ異なっている。constexprのような、明らかに多大な変更が入るであろう機能は、当時執筆を保留したが、実際にFDISを読んでみると、殆どの項目で、一年前とは文面が改良されている。問題は、そのような改良を、参考書にも適用しようとすると、ほぼ書きなおしになってしまうということだ。これでは、いつまでたっても本が完成しない。結局、不完全でも僅かな修正だけで済ますしかないだろう。やはり、C++の参考書を日本語で書くべきではなかったのだ。しかし、英語でいいとなると、なおさら今書いている本のようなものは必要ない。英語でいいのならば、規格を読めばいいからだ。なんともニッチな需要であることよ。

old new thing: 他人の尻拭い、rundll32にまつわる悲壮悲劇

Throwing garbage on the sidewalk: The sad history of the rundll32 program - The Old New Thing - Site Home - MSDN Blogs

Windows Vistaの開発中、アプリケーション互換チームは、rundll32の呼び出し規約の仕様に従わない関数を無理やり呼び出した挙句のスタック破壊の問題を抱えていた。

訳注:Windows上で動く32bitコードにおいては、関数の呼び出し規約が統一されていなかったので、呼び出し規約の誤りによるスタック破壊はよくあることである。もっとも、呼び出し規約が統一されていたからとて、意図的にスタックポインターをずらされてしまってはどうしようもないが。

問題は複雑だ。例えば、rundll32を間違った方法で使っていたバッチファイルが動かなくなった。なぜならば、rundll32プロセスが終了しないからだ。スタックアライメントの誤りは、スタックからのレジスターのリストアの誤りを生じさせ、rundll32の終了時のコードを動かなくさせてしまうからだ。以前のバージョンのWindowsは、この問題を、たまたま、避けることができていた。Windows Vistaで使っているコンパイラーは、最適化方法が異なるので、スタックやレジスターの使い方が異なり、以前のバージョンのWindowsでは、たまたま問題にならなかったスタック破壊が、問題になるのだ。偶然は何度も続かないものだ。

私はこのrundll32の問題を解決して、間違った方法で使っていた人々を救うよう、命ぜられた。つまりは、他人のバグの尻拭いというわけだ。

解決方法とは、関数を呼び出す前に、呼び出された関数がスタックから余計にpopする可能性を考えて、スタックをあらかじめ数百バイトほど余計にpushしておくのだ。そして、スタックポインターをグローバル変数に保存しておく。関数から戻ったら、関数がスタック操作を誤った場合に備えて、そのグローバル変数からスタックポインターをリストアする。たしか、他のレジスターもグローバル変数に保存しておいたような気もするが、何だったかは忘れた。

もちろん、これを悪用してはならない。コンビニの前にゴミを投げ捨ててはいけないのと同じ理由だ。

訳注:アプリケーションの互換性を保つためのworkaroundは、ユーザーのためにあるのであって、プログラマーのためにあるのではない。

2011-09-09

Project Gutenbergの創始者、Michael S Hart逝去。

Michael S. Hart - Gutenberg

Project Gutenbergの創始者が亡くなっていたらしい。残念なことだ。享年64歳。まだ若かったのに惜しい。

2011-09-06

それがおたくの書籍ってやつか

出版社からスキャン代行業者への質問状を全文公開、潮目は変わるか - 電子書籍情報が満載! eBook USER

それなら俺にも考えがある。長えことジョジョとゴルゴ13のファンだったが、今日限りだ。

今や、あらゆるコンテンツは物理的な媒体の拘束を受けずにすむのだ。これは不可逆な時代の流れであり、誰も抗うことはできない。仮に対抗しようとしたとて、かの進化神は歩みを緩めず、障害物を物ともせずに蹴散らし、より一層荒々しく、物事を先に進めるだけである。故に、かの進化神の途上に横たわる障害物を除くのは、我々、今を生きる者の努めである。写本は死んだ。版木は死んだ。活版印刷は死んだ。いかに紙書籍のみ、無常の理を逃れんや。

2011-09-01

bloggerの新しいレイアウト

とりあえずテスト投稿してみる。どうも慣れない。

2011-08-26

次期VC++のIDEに関する情報

First Look at the New C++ IDE Productivity Features in the Next Version of Visual Studio - Visual C++ Team Blog - Site Home - MSDN Blogs

コードの強調表示がより強力になる。仮引数はイタリック体で表示される。

これは改悪だ。私はイタリック体とボールド体が大嫌いなのだ。現にChromeでも、* { font-weight : normal !important ; font-style : normal !important ;}というCSSを全ページに挿入するエクステンションを自作して使っている。わざわざ設定を変えるのが面倒そうだ。

リファレンスハイライト:あるシンボルにカーソルを合わせると、同じシンボルがすべてハイライトされる。単に名前が同じだけの違うシンボルはハイライトされない。

まあ、それなりに便利だろう。

ソリューションエクスプローラーが改良され、ソースコードを展開して、ソースコード内の関数や型などの一覧をみることができる。

これは、今のIDEにも、クラスビューとして存在するが、ソースコード単位で、しかもソリューションエクスプローラーからみられるところは、便利だろう。

インテリセンスのメンバーリストの自動表示。今までは、ショートカットキーを押さなければならなかった。

今でも自動表示されるような気がするが、たぶん、::とか.などに反応しているのが、もっと自動的に出るようになるのだろう。

メンバーリストフィルター。一致する名前だけが表示される。一致検索はファジーで、pbでpush_backが表示されたりする。このファジーな検索は無効にして、単に先頭からの一致に変えることもできるし、フィルターを無効にすることもできる。

コードスニペット。C#などでおなじみのコードスニペットがC++にもやってくる。

2011-08-25

米軍の言語専門家の無駄遣い

Lost in Translation: How The Army Wastes Linguists Like Me | Danger Room | Wired.com

抄訳。

2006年の冬のこと、私は軍隊に、言語専門家として志願した。外国語の翻訳を担当する兵士だ。軍の採用担当は、大学で何年もアラビア語を履修した私のジェイムズ・ボンド的技能を信用しなかったようだ。ともかく群の採用担当は、実地における経験を積めるよう配慮すると約束した。そこで、私は入隊して教育訓練を受けた。

2年間の教育訓練の後、国内でのアラビア語関連の仕事を経て、ついに2009年の3月、私はデルタ基地に着陸したブラックホークより降り立った。イラク南部のアルクートに近い基地だ。私の仕事は、傍受したアラビア語の通信を翻訳して、前線兵士に警告を出すことであろうと、私は考えていた。

任地で私を迎えた曹長の専門言語が朝鮮語であると知った時の、私の驚きを想像してもらいたい。どうやら、私の配属された5人班の半分は、朝鮮語話者であるようだ。イラクの砂漠で、朝鮮語の需要がどれだけあるというのか。これが、私の配属は、訓練内容とまったく合っていないのだと知る、最初の兆候であった。

イラクでの任務が始まり、私は、誰が言語を英語に翻訳しているのかという事実を、すぐに知った。それは、中年の巨漢なアラブ人であった。私ではない。モースル生まれのネイティブであり、我々の配属が必要としている翻訳の半分をこなす、民間人からの任用者であった。噂では、彼は20万ドル以上儲けているらしい。私の給料の優に5倍の額である。その間、私の班員は、暇そうにそこらへんに座り、装備をいじったり、パソコン画面を眺めたりして、退屈な時間を過ごしていた。

どうやら、どこの班でも事情は同じらしい。私は8ヶ月の勤務中に、35冊の本を読み終えた。そのうちの一冊は、Fiasco: イラクにおけるアメリカ軍兵士のアドベンチャーであった。

例えば、イランの国境に近いアマラーの基地にいる、ある兵士は、ペルシャ語を流暢に話す。もし、彼が通信兵に配属されたならば、非常に便利であろう。では、彼は代わりに何をしているのか? 彼は同僚がWoWで遊ぶのを観察するという非常に忙しい任務に付いている。

私の知る限り、軍隊内の言語専門家は、皆同じ問題を抱えている。

こんな状況ならば、そもそも軍は言語専門家など派遣するべきではないのだ。戦地に派遣されなかった言語専門家は、NSAとかのインテリジェンス部門で働いている。海外に派遣された者とは違い、彼らは実際に言語技能を活用して、派遣された兵士の力になっている。毎日の仕事によって、彼らの言語技能は維持されている。ある防衛会社などは、言語専門家を遠隔通信で前線にいる兵士とつなぎ、必要な翻訳を担当させるようなことまでしている。

一方、現地に派遣された言語専門家は、全く関係ない退屈な仕事をしている。他の兵士と何ら変りない。専門の言語技能は必要とされず、技能を維持することすら難しい。多くの者は、技能確認のテストに落第してしまう。

少なくとも、軍は我々言語専門家を、どこにでも使える万能要員のように扱うのを辞めるべきだ。我々の技能は専門的である。朝鮮語話者は朝鮮にいるべきであって、アルクートにいても仕方がない。スペイン語やフランス語専門の者は、ラテンアメリカとかNATO軍とかに配属されるべきなのだ。

まあでも、軍は私の代わりに、民間任用者を多数雇用して仕事をさせている。むしろこっちの方が優れているのだろう。ネイティブの技能には、太刀打ちできるわけがない。金はかかるが、品質も悪くない。

セロ弾きを妨害する猫

あまりに可愛いので貼らずにはいられまい。

2011-08-24

explicitデフォルトコンストラクターと空の初期化リスト

規格を読む限り、explicitデフォルトコンストラクターを持つクラスを、空の初期化リストでリスト初期化できると思う。

12.3.1 [class.conv.ctor] p2

A default constructor may be an explicit constructor; such a constructor will be used to perform default-initialization or value-initialization (8.5).

とあり、デフォルト初期化か値初期化が可能である。また、リスト初期化で初期化リストが空の場合、

8.5.4 [dcl.init.list] p3

If the initializer list has no elements and T is a class type with a default constructor, the object is value-initialized.

単にデフォルトコンストラクターと言っているので、explicitかどうかは問わないはずだ。

2011-08-23

今日学んだ英単語:defenestrate

defenestrate [diˌfɛnəˈstreɪt]
動詞
窓から(人、物を)投げ捨てる

そんな動詞があるのか。

Defenestration - Wikipedia, the free encyclopediaによると、それなりに歴史のある言葉らしい。

Bastionが興味深い

Bastionというゲームが、非常に興味深い。実際にプレイしたわけではないが、プレイ動画を見るかぎり、かなり面白そうだ。

特徴的なのは、動的なナレーションだ。ゲームを止めることなく、プレイヤーの行動にあわせてナレーションが流れる。いままで、こういうゲームはなかったと思う。

最近のゲームは、やたらとストーリーを重視し、やれカットシーンだのQTEだのと、ゲームを途中で止める変な要素を入れたがる。ゲームはユーザーの入力に反応するから面白いのであって、単に映像をみるのならば、それは映画と変わらない。この仕組は、ゲームの流れを止めないという点で、優れている。

Zero Punctuationもレビューしている。

Zero Punctuation: Bastion and From Dust

2011-08-21

コピーとムーブが本当に難しい

どうやって説明したものやら。

2011-08-16

Firefoxがしかるべき方向に動いている

Mozilla takes Firefox version numbers to the next level… by removing them | ExtremeTech

Firefoxが、バージョン番号というものを、ユーザーには意識させないようにするそうだ。これは当然である。ブラウザーは、常に最新にしておくべきであり、もはや特定のバージョン番号に留まるなどということがあってはならない。

これは良い方向に動いていると言える。

2011-08-15

C++11という名称は定着するのか

C++0xのFDISに、どの国の支部からも文句がつかなかったので、めでたく正式なISO規格として承認された。それは今さら言うでもない。しかし、この名称は一体どうなるのだろうか。

もちろん、正式名称はC++である。しかし、規格ごとの区別をつけるため、我々は俗称を用いてきた。1998年に承認された最初のC++規格を、C++98と呼び、2003年にマイナーアップデートされた規格を、C++03と呼んでいる。C++0xは、200x年に正式に発行される予定だったので、C++0xと呼ばれたわけだ。それが、結局色々あり、2011年までかかってしまった。xは実は16進数なのだというジョークはさておき、一体どうなるのだろうか。こればかりは、規格で決めるものではないので、自然の成り行きをみるより他はない。

現在、C++11という呼称を、一部の人間が使っているが、果たしてC++0xより定着するのだろうか。疑問だ。

2011-08-14

日本語に句読点要らぬ

先日通俗三国志の本を得て読み侍りしが句読点なき由いと不審なりとはいへ本来日本語には句読点てふもの存せずまた読むに不都合なしさらば句読点てふもの畢竟無用なり。

2011-08-13

通俗三国志

今行われている、下鴨納涼古本まつりで、面白い本を見つけた。表紙には、軍談三国志と書いてある。中には、通俗三国志と書いてある。明治四十五年発行の本だ。興味深かったので買うことにした。

あとで調べたところによると、三国志演義の翻訳らしい。元禄の頃に成立したのだとか。内容は簡潔ですばらしい。興味深いのは、句読点が一切ないことと、御、申、候といった漢字に対して、特殊なくずし字のようなものが使われていることだろうか。それから、おそらくは「やう」だと思われる言葉が、「よふ」と表記されているのも気になった。また、細かいところでは、閑話休題のルビが、「あだしごとはさておき」となっているのが興味深かった。

それにしても、これはいい本を手にいれたものだ。昔、本の価値は文章量によって決まるのだと考えていたが、今は、簡潔な文章を好むようになっている。だらだらと長文を弄して説明するだけなら誰にでもできる。真の文章は、最低限の長さで内容を伝えることにあるのだ。吉川英治の三国志は、この点であまりよろしくない。いつも最期まで読もうとして、途中で諦めてしまっている。文章が無駄に長すぎるのだ。それが、この通俗三国志では、まだ44ページ目だというのに、もう呂布が死んでいる。かといって、三国志で重要な話を省略していたりはしない。なかなか表現力の高い文章だ。気に入った。

2011-08-11

例外オブジェクトとしてのクラス

追記。正しくは、例外オブジェクトは、コピーかムーブのどちらかをサポートしていなければならないというものであった。つまり、コピーするのならば、ムーブは必要ないし、ムーブしかできないクラスも、例外オブジェクトたりえる。したがって、この記事の内容は誤りである。

例外として投げるオブジェクトのことを、例外オブジェクトという。例外オブジェクトがクラスのオブジェクトである場合、コピーコンストラクター、ムーブコンストラクター、デストラクターにアクセス可能でなければならない。(たとえ、使われなかったとしても)

struct X
{
    X() = default ;
    X( X const & ) = delete ;
} ;

void f()
{
    throw X() ; // エラー、コピーコンストラクターにアクセスできない
}

しかし、これは非常にわかりにくいと思う。例えば、以下のコードは誤りである。

struct X
{
    X() = default ;
    X( X const & ) { } // ユーザー定義コピーコンストラクター
} ;

void f()
{
    throw X() ; // エラー、ムーブコンストラクターにアクセスできない
} 

なぜかというと、ユーザー定義のコピーコンストラクターがある場合、ムーブコンストラクターは暗黙にdefault化されないからだ。よって、エラーになる。どうやら、今のC++コンパイラーは、まだこの挙動を正しく実装していないようだ。

これは、コピーコンストラクターに限った話ではない。ユーザー定義のコピー代入演算子や、ムーブ代入演算子、デストラクターがある場合、ムーブコンストラクターは暗黙にdefault化されない。

また、暗黙のコピーコンストラクターは、ユーザー定義のコピー代入演算子や、ムーブコンストラクター、ムーブ代入演算子、デストラクターがある場合、default化される。しかし、この挙動はdeprecatedである。将来的には、廃止されるだろう。とすると、将来、C++の改定されたときに、以下のコードは動かなくなる可能性がある。

struct X
{
    X() = default ;
    X( X && ) { } // ユーザー定義のムーブコンストラクター
} ;

int main()
{
    throw X() ; // C++0xではOK。ただし、将来的には不安。
}

もちろん、これは例外に限った話ではない。C++0xで、暗黙の特別なメンバー関数が欲しい場合は、明示的にdefault化すべきだろう。

Walmartがオンライン音楽販売を停止

Walmart pulling the plug on its MP3 store, but not its DRM servers

Walmartが、オンラインでの音楽販売をやめるそうだ。すでに購入した客のために、DRMサーバーは残すそうだ。ただ、すでに中止されたサービスのためのDRMサーバーがいつまで残っているのかは、疑問だ。

DRM付きのコンテンツを買うということは、常にこの問題に悩まされる。したがって、我々が取るべき戦略は、DRM付きコンテンツをボイコットすることである。音楽など聞かなくても、死にはしない。第一、すでに著作権、著作隣接権とも切れた録音は、山ほどある。DRMの存在は、正規のユーザーに対する侮辱である。

2011-08-10

GMailのフォワード警告が全然消えない

最近、GMailはForwardするフィルターがある場合、警告を表示するようになった。これは、意図せずメールをフォワードするフィルターが何らかの方法で設定されてしまっている場合を考えてのことであろう。自分で設定しなかったフィルターは、なかなか確認されない。ましてや、大部分のユーザーは、フィルターを使っていないだろう。

ただ、私の場合、そのフィルターは自分で設定したものなのだ。どうも、私の父親は、私にメールを送る場合、過去のメールに返信するという形をとっているため、携帯に送るべき時でも、GMailに送られてくる。そのため、親から送られてきたメールは、携帯にも転送するようにしているのだ。

Googleが言うには、警告が表示されるのは、一週間程だという。ただ、もう二週間ほど表示されっぱなしなのだが、どうにかならないものか。あまりにウザイので、しかたなく、このフィルターを消した。

2011-08-07

二期はクソの法則

アニメの二期は必ずクソになる法則があるのではないだろうか。少なくとも、私の好きなアニメは、皆クソになっていた。

例えば、魔法陣グルグルだ。一期はすばらしかった。作画もネタも最高であった。ところが、二期はどうも毒が抜けたのか、つまらなくなってしまっていた。二次使用料の不払い絡みに関連する、ニケの声優の変更も痛かった。

THEビッグオーも、二期はひどかった。謎は謎のままにしておけばよかったと思うのだが、何もあんな方法で解決することもあるまいに。

.hackは.hack//SIGNしか認めない。

私のアニメの知識は、10年ほど前で止まっているので、最近のアニメについてはわからない。

もちろん、アニメに限らず、大抵の続編はつまらない。例外は本当にごくわずかしか存在しない。Back To The Futureなどは、稀有な存在であろう。

何故こうなるのか。思うに、二期を制作するにあたって、一期とまったく同じ制作環境が用意できるわけではないからだろう。

QuakeCon 2011 - John Carmack Keynote

90分間もある、John Carmackの講演。

25分経過、内容は、現行コンソールの貧弱なハードウェアに対する愚痴になっている。

32分経過、PCのハードウェアはコンソールの10倍も優れているのに、60fpsを保証できないことを愚痴っている。

ソースコードの静的解析ツールを熱烈に推奨している。

言語をHaskellとかOcamlに移行したいとも言っている。しかし、周りのプログラマーが全員移行できるわけではないので、やはりC++のサブセット(未初期化配列、未初期化ポインターなどの禁止)を使ったほうがいいと言っている。

モバイル向けのゲーム。モバイル機はハードウェアが貧弱なので、昔のハードでプログラミングしてた頃の知識が役に立っているのだとか。

2011-08-06

いくつかのアメリカのISPは検索クエリーをハイジャックしているらしい

Widespread Hijacking of Search Traffic in the United States | Electronic Frontier Foundation
I need to fill out a CAPTCHA to search google. - Web Search Help

いくつかのISPでは、Googleなどの検索エンジンへのアクセスが、DNS鯖への細工によって、不思議なプロクシを経由して行われるそうだ。このプロクシは、appleとかdellとかkindleとかの検索クエリーを検知して、検索エンジンではなく、該当の公式サイトなどに飛ばすらしい。それ以外の場合は、単にユーザーと検索エンジンとの間のトラフィックを通過させるだけなので、ユーザーはその存在に気がつかない。

技術的には、通常の検索クエリーを監視、記録したり、書き換えたりすることも可能である。実際、この不思議なプロクシを運営している会社は、そのような特許まで取得しているのだとか。

これは非常に危険だ。そろそろWebサイトは、常にSSLを使うということを、真剣に考えるべきだろう。

2011-07-31

フィンランド人から送られてきた画像

知り合いのフィンランド人からこんな画像が送られてきた

Funny Japanese T-Shirt

近所の服屋で売っているのを発見したらしい。フィンランドはさだめしカオスな国なのであろう。

2011-07-30

モルグ街の殺人が難しい

モルグ街の殺人(The Murders in the Rue Morgue)を読んでいるが、思いの外に英語が難しい。考えてみれば、もう160年ぐらい前の文章なのだから、今の英語と違っているのは当然なのだが。

ともかく、モルグ街の殺人は、探偵小説の初めとなった小説である。ファンタジー小説における指輪物語にあたる本だ。

The Murders in the Rue Morgue

2011-07-28

16ドルで家を手にいれた男

あるテキサス人が、放棄されていた家を16ドルで手にいれた。

動画によると、この家は放棄されていて、誰も所有権を主張していなかったそうだ。元の住人は賃料が払えず手放し、家を管理していた不動産会社は倒産した。そのため、家の権利は宙ぶらりんで、誰も権利を主張していない状態であった。

そこで、この男は、一ヶ月もの間、テキサスの法律を調べ、この放棄された家の所有権を主張する法的な申請を行った。その申請手続きにかかった金が16ドルとのこと。このまま三年間、元の所有者か、倒産した不動産会社の負債をもっていた銀行に権利を主張されずに住み続ければ、完全にこの男の所有物になるそうだ。しかし、元の所有者が権利を主張するには未納の賃料を払わねばならず、銀行が権利を主張するには、相当に複雑な手続きをしなければならない。だから、誰からも権利を主張されることはないだろうと男は踏んだそうだ。なんとも賢い男である。

しかし、お隣のレイシストな白人ビッチは、どうもこのやり方を気に入っていないようだ。

2011-07-27

ストーム・トルーパーのデザインはすでに著作権切れ

BBC News - Lucas loses Star Wars copyright case at Supreme Court

ストーム・トルーパーの衣装をデザインした人物が、その衣装を作って売っていたのだが、それに対してジョージ・ルーカス側が文句をつけた。

問題は、当時、明確な契約というものが存在しなかったらしい。

今回、イギリスの最高裁で、ジョージ・ルーカスは販売差し止めの権利を持たないという判決を下したそうだ。

イギリスの著作権法はよく分からないのだが、記事では、工業意匠の著作権の保護期間は15年であると言っている。そういうものなのだろうか。

しかし、これはルーカスの他の映画のデザインにも影響しそうだ。

追記:オリジナルの設計者の主張は、コスチュームは芸術品ではなく、実用品だというものらしい。イギリスの法では、そういう工業意匠の著作権の保護期間は15年間なのだとか。

CSSで垂直方向の中央に配置するのがややこしい

CSSで、画像や動画を垂直方向の中央に配置したいと考えた。さっそくどのプロパティを使えばいいかググったのだが・・・どうもプロパティ一発というわけにはいかないようだ。もちろん、この問題は、いまさら知らなければモグリであるほどの古典的なものだが、CSSグルではない私は知らなかったので、書いておこうと思う。

もちろん、垂直に中央配置する方法はある。しかしどの方法も、汚いハックなのである。さらに、大抵の初心者が陥る問題がある。

まず誤解しやすいのが、vertical-alignプロパティであろう。これは名前が宜しくない。vertical-alignは、インライン要素のラインボックス(つまり文字列のレイアウト)の垂直方向の配置を指定するためのプロパティである。残念ながら、凡人が期待するようには動かない。

ただし、テーブルセルにvertical-alignを適用した場合のみ、凡人が期待するように動く。つまり、要素自体のアラインを垂直方向に対して指定できる。

CSS 2.1: vertical-align
CSS2.1: Table height algorithms

つまり、vertical-alignには、二つの全く異なる機能が混在しているといっていい。なんとも悲惨な仕様である。

ただし、このテーブルセルの仕様は利用できる。つまり、displayプロパティで、要素をtable-cellに変えてしまえば、vertical-alignが使えるのだ。ただし、その要素を囲むdisplayプロパティがtableな要素が必要になってしまうのが欠点だが。

<div style=" display : table ; ">
    <div style=" display : table-cell ; vertical-align : middle ; ">
        <!-- 実際のコンテンツ -->
    </div>
</div>

この方法は、コンテンツのheightをあらかじめ知っておく必要はないし、コンテンツのheightを動的に変えても問題のない、現時点で最良の方法である。IE8以下では動かないようだが、CSSの信奉者は、IE8などという劣ったブラウザーはもとより使わないので問題はない。

一応、CSS 3には、Flexible Box Modelというのが提案されているようだが、どうも仕様が二転三転して、未だに固まっていないように思われる。現時点では、まだ使うべきではない。

2011-07-26

gccとclangのC++0xサポートの比較

C++0xの規格はほぼ固まり、もはや変更されることはない。恐らく、このまま規格制定されるものと思われる。さて、今C++の主要なコンパイラーを上げるとすると、gccとclangをおいて他にはない。MSVCはオモチャだ。右の両コンパイラーは、C++0xの新機能を実装し始めている。もちろん、まだ不完全な実装も多いが、とりあえず遊べる程度には実装できている機能も多いので、比較してみることにする。

gccのC++0xサポート状況は、以下のページに簡易な一覧がある。

C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)

clangのC++サポート状況は、以下のページに簡易な一覧がある。

Clang - C++ and C++'0x Status

面白いことに、どちらか片方のコンパイラーでしか実装されていない機能が、結構ある。ここで少し比較をしてみようと思う。もちろん、細かく観ていくときりがないので、大きな機能だけを紹介する。また、どちらのコンパイラーでも実装されている機能は省く。実装されていない機能は紹介する。

gccしか実装していない機能は、以下の通りである。

初期化リスト

std::vector<int> v = { 1, 2, 3, 4, 5 } ; // 便利便利

lambda

std::string str("表示するよ:") ; // キャプチャもできるよ
std::for_each( v.begin(), v.end(),
    [=](int i){ std::cout << str << i << std::endl ; }
) ;

ローカルクラスと無名クラスをテンプレート実引数に取る

template < typename T >
void f(T) { }

void g()
{
    struct X { } ;
    std::vector<X> v ; // ローカルクラスはOK

    enum { e1 } ;
    f( e1 ) ; // 無名クラスもOK
}

生文字列リテラル

char16_t const * ptr =
uR"(
ここには何でも書ける。
もちろん、\とかも書けるし、
この改行だって、ちゃんと改行として反映される。
ただし、\に続くuとUは使えないので注意。
"に続く(とか、)に続く"も書けない。
もちろん、連続しなければOK。
)" ;

unionの制限取っ払い

union U
{
    int x ;
    double d ;

    // 普通のクラスは余裕で持てる。
    std::string s ;

    // コンストラクターだって楽勝。
    U() : s("initialize") { }

    // メンバー関数もOK。virtual関数はダメだけど
    void f() { } 
} ;

constexpr

constexpr int twice( int x ) { return x * 2 ; }
template < int I > struct X { } ;
X< twice(100) > x ; // X<200>

clangしか実装していない機能は、以下の通りである。

コンストラクターのデリゲート(丸投げ)

struct X
{
    X( int i ) : X(i, 0) { } // 丸投げ
    X( int i1, int i2 ) { }
} ;

非staticデータメンバーの宣言の初期化子

struct X
{
    int m = 0 ;
    X() { } // mは0
    X( int i ) : m(i) { } // mはi
} ;

テンプレートエイリアス(エイリアス宣言も含む)

using A = int ;
A a ; // int
template < typename T >
using B = T ;
B<int> b ; // int
template < typename T >
using C = std::vector< T, CustomAllocator > ;
C<int> c ; // std::vector< int, CustomAllocator > 

まだどちらも実装していない機能

アトリビュート

[[]] int [[]] x ;

アライメント

struct X { int x ; double d ; } ;

void f()
{
    alignas(X) char a[100] ; // X型に要求されるアライメントを指定
    alignas(16) char b[100] ; // 16バイトアライメントを指定
    alignas(X, 4, float) char c[100] ; // X型と4バイトとfloat型とで、一番強いアライメント要求を指定

    alignof(int) ; // int型に要求されるアライメント(定数式)
}

コンストラクターの継承

struct Base
{
    Base() { }
    Base(int) { }
    Base(double) { }
} ;

struct Derived : Base
{
    // コンストラクターを継承
    using Base::Base ;
} ;

Derived d(0) ; // OK

ユーザー定義リテラル

void operator "" _owata ( char16_t *, std::size_t ) { }

int main()
{

uR"(
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄」
―――――――――――――‐┬┘
                        |
       ____.____    |
     |        |        |   |   
     |        | ∧_∧ |   |  
     |        |( ´∀`)つ ミ |   
     |        |/ ⊃  ノ |   |
        ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄    |    ミ ユーザー定義リテラル

)"_owata ;

}

Twitterが検索用URLの仕様を変えた

今までは、

http://twitter.com/search?q=文字列

だったのに、今日からは、

http://twitter.com/#!/search/エスケープされた文字列

になってる。URIの文字、, / ? : @ & = + $ #などを、たとえばJavascriptでいうencodeURIComponent()を使ってエスケープしなければならない。

URLのエスケープは、Bloggerのテンプレートのexprではできないので、Javascriptを使って行うことにした。

また、すべての検索を表示するには、http://twitter.com/#!/search/realtime/というURLになっている。

コンピューターウイルスという用語は廃止すべき

慣習的に、malwareを「ウイルス」とか「ワーム」とか「トロイの木馬」などと読んでいる。これは、やめるべきである。結局、これらの言葉は、一般人には理解出来ない専門家が、ある特定のソフトウェアのカテゴリー分けをするために使っていた符牒である。符牒は、一般人に使われることを想定していないのだ。

寿司屋では、「上がり」とか「おあいそ」といった言葉が使われる。これは、「うぉーい、客が()ェるぞぉ。茶ァ出せ茶ァ」とか、「勘定しろぉい」など叫ぶのが、あまりにも客に対してぶあいそであるので、店側の人間だけで通じる、同様の意味を持つ暗号を取り決めたのだ。それが、いつの間にか客側にも広まってしまい、今では、客が「上がり頼むよ」とか「今日はこのへんでおあいそして」などというようになってしまった。本来、客側での使用を想定していない言葉が定着してしまったために、知らないものから見ると、非常に不思議に聞こえるのである。

ウイルス、ワーム、トロイの木馬にも、同じことが言える。これらの用語は、一般人が使うべきではない。英語圏では、すでにこれらの用語は廃れ、今では、マルウェア(malware)という言葉が使われている。これはMalicious Softwareの略である。日本語に直すと、悪意あるソフトウェアとなる。

単に、「彼、ウイルスを保管せしによりて罪せらる」というのは、誤解を招く。正しくは、「彼、ウイルスを邪まに用いんと欲して保管せしによりて罪せらる」と書かれるべきなのだ。しかし、これがもし、「彼、悪意あるソフトウェアを保管せしによりて罪せらる」とあれば、誤解は生じないはずだ。

したがって、ウイルス、ワーム、トロイの木馬といった用語は、使ってはならない。マルウェアも、日本人にはmalfunctionなどと使われるmalという言葉の意味がわからないので、不適である。「悪意のあるソフトウェア」という言葉を用いるのが、最もふさわしい。

2011-07-25

バンダイチャンネルがあまりイケテない件

月額1,000円見放題|アニメ・動画配信 / バンダイチャンネル

バンダイチャンネルが、月千円でアニメ見放題の動画配信を始めるらしい。第一話が無料でみられるようなので、ためしにTHEビッグ・オーを観てみた。

「THE ビッグオー」 | アニメ配信 | 無料動画2000本以上! | バンダイチャンネル

どうせ旧態依然のバンダイのやることだろうから、嫌な予感はしていたものの、品質が最悪である。まず、エンコードがクソである。正直いって観れたものではない。しかも、常に右下にロゴが表示されている。これで金を取るというのだから、呆れるばかりだ。あるいは、課金するとまた違うのだろうか。

さらに極めつけは、日本国外から観ることはできないということだ。せっかくアニメ好きの外人に紹介したのがバカみたいだ。クソにもほどがある。

ところで、THEビッグオーは、個人的に好きな数少ないアニメのひとつである。だいぶ世間からは過小評価されているが、私の中では、文句なく最高の巨大ロボットアニメである。一言でいえば、バットマンが巨大人型ロボットに乗って戦うアニメである。そのあまりにアメコミかぶれの内容から、日本よりアメリカでの評価が高い。ただし、アメリカのスポンサーを得て作られた第二期は黒歴史なので、見る必要はない。

しかし、なぜアニメ業界はこうも旧態依然なのだろう。いまどき光学ディスクなど売れるわけがない。売れないから値段を高くして、ますます売れなくなっている。光学ディスクにしたって、ブルーレイほどの容量があれば、一枚に一期程度を収めることは可能である。それが、一枚に二話程度入っているだけだ。いちいちディスクを入れ替えろというのだろうか。

要するに、アニメを見るのはものすごく不便なのである。技術の進歩に全く追いついていない。いまだに、VHSとおなじような感覚でいるのだ。時代は変わったというのに。

2011-07-24

テンプレートはコピー、ムーブではない

この問題だけを完結にまとめた文章が必要であると感じたので書く。

テンプレートなコンストラクターや代入演算子は、コピー/ムーブコンストラクター、コピー/ムーブ代入演算子とはみなされない。したがって、テンプレートなコンストラクターや代入演算子の存在は、暗黙のコピー/ムーブコンストラクターやコピー/ムーブ代入演算子の生成を妨げない。

ただし、テンプレートなコンストラクターや代入演算子は、コピー、ムーブが必要な場合に、オーバーロード解決の候補になる。

struct X
{
    X() { }

    template < typename T >
    X( T & ) { }

    // 以下の暗黙のコピーコンストラクターが生成される
    // X( X const & ) ;
} ;

int main()
{
    X a ;
    X const b( a ) ; // テンプレートコンストラクター
    X c( b ) ; // 暗黙のコピーコンストラクタ―
}

bの初期化では、aは非constなオブジェクトであるので、オーバーロード解決により、テンプレートコンストラクターが選ばれる。cの初期化では、bはconstであるので、オーバーロード解決により、非テンプレートな暗黙のコピーコンストラクターが選ばれる。

もし、この挙動が嫌であれば、コピーコンストラクターを明示的にdelete定義しておけばよい。

struct X
{
    // 暗黙のコピーコンストラクターの生成を阻害
    X( X const & ) = delete ;
}

クラスXのコンストラクターは、Xを引数に取ることはできない。

struct X
{
    X(X) ; // エラー
} ;

ただし、テンプレートの場合、インスタンス化の結果がこのようなシグネチャになる場合、インスタンス化されない。

struct X
{
    X() { }

    template < typename T >
    X( T ) { }
} ;

int main()
{
    X a ;
    X b( a ) ; // 暗黙のコピーコンストラクター
}

したがって、テンプレートなコンストラクターを、安心して書くことができる。

代入演算子も、同様である。テンプレートな代入演算子は、コピー代入演算子ではない。ただし、コピーが必要な場面では、テンプレートな代入演算子も、オーバーロード解決の候補になる。

2011-07-21

zoomeがサービス終了

[重要]zoomeサービス終了のお知らせ zoomeインフォメーション - 動画共有サイトzoome

zoomeがとうとう修了するらしい。確かに、他の動画サービスに比べて、何の特色もない平凡なサイトであった。規模でいえば、どの動画サイトも、YouTubeには勝てない。ただし、ニコニコ動画は、コメントなどの、動画以外の要素で勝負している。ではzoomeはというと、アップロードした動画が、ある基準を満たしている場合、再エンコードされない程度の要素しかなかった。これでは、一部の動画ヲタを除いては、誰も喜ばない。そんな一部のユーザー向けに課金を初めても、収益の上がるはずがないのは当然だ。終わるべくして終わった動画サイトと言える。

それにしても、動画サイトというのは、もうすっかり一般的になったものである。私は、大衆化したものには興味をなくしてしまう性質なので、最近は動画サイトも積極的に観ているわけではない。たまに、Google Readerを通じて流れてくる、面白い動画の紹介ページを通じて、間接的に観る程度である。

では、今注目しているものは何かというと、これが実は、存在しない。Pixivは毎日みているが、これも、最近きな臭い話が聞こえてきて、いつまでつづくとも思えない。思うに、インターネット自体が、すでに大衆化してしまい、これ以上進歩する見込みがないのではないだろうか。この現状を打破するためには、インターネットを超える「何か」を発明するしかない。

もちろん、その「何か」を、いま予測するのは不可能である。かつて予測された、蒸気で動く鉄の馬とか、空を飛ぶ車、体にぴったりとフィットする機能的に無駄のない統一された服、栄養のバランスが完璧にとれた完全食は、一向に実用化される気配がない。

ただ、あえて妄想を書くとすれば、アプリケーション層より下層が、P2Pになったら面白いのではないかと思う。たとえば、すべてのノードは無線通信装置を備えており、数十メートルから数百メートルぐらいの範囲の他のノードと通信できる。各ノードが接続しあい、P2Pなネットワークを構築する。無線の届かない距離にあるノードに対しても、ノードを中継することにより通信ができる。

これにより、検閲の不可能なネットワークを構築できるだろう。

まあ、もちろんこれは妄想であって、実現することはない。未来は常に、予想外の技術にとって変わられるのだ。ただし、私が生きているうちに、インターネットはラジオやテレビと同じく、過去のメディアになっているとは思う。それだけの時間はあるのだから。

2011-07-16

遠州弁で書いてみるに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2011-07-14

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でも動くようになる。

2011-07-13

Boost 1.47.0にはratioとchronoがある

Boost 1.47.0がリリースされた。

Boost Version 1.47.0

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

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

2011-07-10

面白そうな語学サイト

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

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

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

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

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

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

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

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

2011-07-07

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++本をさっさと書き終えて、真面目な仕事を探さなければ。

2011-07-04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

松本龍が小物すぎる

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

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

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

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

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

2011-07-03

潔すぎる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の利用を禁止しているわけだ。しかし、ちゃんと話の通るサポセン要員を用意している点は、評価できるのかもしれない。

2011-07-02

複数の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を使うべきである。

2011-06-29

そうめんと豆腐

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

2011-06-28

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を忘れていた。

2011-06-27

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