|
．gcc for ARM の 最適化のバグにハマる。 ．こういうコード:
/* 比較用 (正常) */
int
foo(unsigned short val)
{
return (val & 0x8000U) != 0;
}
/* 問題のコード */
static __inline int bar(unsigned short) __attribute__((always_inline));
int
bar(unsigned short val)
{
return (val & 0x8000U) != 0;
}
int
hoge(unsigned short val)
{
return bar(val);
}
を gcc -O1 でコンパイルすると foo: @比較用 (正常) mov r0, r0, asl #16 mov r0, r0, lsr #31 mov pc, lr hoge: @問題のコード mov r0, #0 mov pc, lrというコードを吐いてくれるわけです。foo() のほうはそれなりに エレガントなんですけどねぇ。 ．ちなみに bar() の引数を unsigned int にすれば解決します。 ．そんなこんなで、セーブ機能のバックエンドが実装完了。 ．「お嬢様にはかなわない / やぶうち優」を引っこ抜いて読んで寝た。 |
|
．会社 - 神保町買い物 - 岩本町 - 秋葉で買い物 - OutRun2 美女ビジョンモード E コース - 神田 - 門仲で飯 - 帰宅 ．帰ってきて CD 鑑賞。美鳥たんはまあこんなもんでしょ。可もなく不可もなく。 ．OutRun2。OutRun から継承した曲についていえば、まあ、 オリジナルに忠実に作ってもアレンジしても文句言われる 宿命にあるから大変だなぁとは思うものの、でもそれにしてもこれは駄目だなぁ。 一言で言えば「バランスが悪い」以上でも以下でもないわな。 誤解を恐れずに言えば、オリジナルの OutRun はヘボイんですが、 でも、ヘボイけどヘボイなりの完璧なバランスがあったわけです。 しかしこの OutRun2 のは要素間のバランスが全く取れてないですよね。 かろうじて残ってる生演奏のいいところをシンセが全部殺してるし、 あるいはピアノとかのおざなりさ加減がぐんにょり感をより引き立てる。 ．録音も、エンジニアリングが全く駄目ですね。 まず耳につくのが、 耳に刺さるようなピーキーな高域と、そのくせ上に延びてない f 特でして。 いくらトーンコントロールで High のツマミを右に回しても、 テープに乗ってない高音は出ないからやめとけ。 あと、抜けの悪い低音。要するにドンシャリ。わざとやってるのかなぁ、これ。 ドンシャリだと全くサマにならないジャンルの音楽だと思うんですけど。 ．まあ細かいところはキリがないからこれくらいでやめとこう。 いずれにしろ、今の音楽と 80 年代の音楽は、基本からして方向が 180 度違う ってことを再認識したような気はする。 ．まあ、新曲のほうはそんなに悪くないと思うんだけど、 でもセガにしてはあまりクオリティが高くないやね。 |
|
．FS フォント 。 どうも GT フォントのライセンスの扱いが怪しいような。 この理屈が適用できるのならば、あらゆるフォントデータは 無条件で利用可能になってしまう。 ．日本国内法上の事情として、 「タイプフェイスは保護されない」というのは事実だけども、 それは「フォントデータが保護されない」という意味ではない。 実際、GT フォントデータの使用許諾条件はパブリックドメインと 相容れない条件になってる。 ．問題は この回答 の存在なんですよねぇ。これは混乱に輪をかけるだけのような気がしますな。 これを見るかぎり、もともとの GT フォントの権利者も、どうもフォントの 権利事情についてあまり明るくないんじゃないかという気もする。 単なるタイプフェイスの利用と、フォントデータの改変ならび変換についての 混同がある。そのへんがあいまいなので、 FS フォントが、使用許諾条件の 3 ないし 4 のケースにあたるのか、 それともこの回答 3 のケースにあたるのか、 ちゃんと原著作権者に確認を取らないとわからないですな。 ．第一、 「フォント・デザインに関しては著作権もしくは無体財産権を主張していません」 という文言も変でして、 確かに「主張してない」という事実はあるものの、それ以前に 「国内法では主張できない」という事実が存在するわけです。 この「してない」と「できない」の区別は重要でして、 たとえば、タイプフェイスに法的な権利が認められているドイツのような 国にこのフォントを持って行った場合には、使用許諾条件の 「このフォントと漢字データ」という文言は当然タイプフェイスにも 適用できるという話になるわけです。 そこまで考えて「回答 3」が出てるのならば、 それはそれでいいような気もするのですが、 きっとそこまで考えてないんじゃないかという気がしますね。 あるいは、仮にそこまで考えていたとしても、使用許諾条件に 明記されていない以上はアンオフィシャルなのでちょっと困りもの。 ．一方で、ぢつは日本国内やアメリカなど、法的にタイプフェイスに権利を 認めていない国に限れば (といっても今のところ認めてる国のほうが少数派だけど)、 一度全文字を紙に印刷し、それをスキャンしてアウトライン抽出すれば、 どんなフォントでも自由に複製可能なんじゃないか、 という噂もあるわけですが、まああまり健全とはいえませんな。 |
|
．一回休み。最悪の状態は過ぎたけど頭痛が痛い。 ．夕方、水戸黄門を見ながらカップの沖縄そばを食う。 ．昨日買ってきた「機工魔術士(4)/河内和泉」とかを読んだ。 ．「M と N の肖像(6)」「学園アリス(1)-(3)/樋口橘」を読んだ。 ．「水色時代(1)-(7)/やぶうち優」を読んだ。 ．明け方寝た。 |
|
．まあ、フリーライダーとかそういう話は脊髄反射だからいいとして、 それにしたってあの Web ページのアホさはありえない。 アレと同類と見られるのはやっぱり嫌だから、 同類と見なされるようになる前に足抜けせんといかんかなぁ……。 となると 4/1 よりも前に以下略ということで、 2 月中には動いとかんといかんということか。謎。 ．フリーライダーという話をすれば、 まー昔はともかく、某弊社あたりはすでに以下略。 ．個人的には、 「しょせんオープンソースは FSF の偉大な思想的発明(=GPL) に対するフリーライダー」 だと思ってるので、どう転んだところで結局はアレを疑問視してる連中も、 アレの中の人々と |
|
．これ とか このネタ 。 あまり深入りはしたくないのだけど (というか深入りした末「どーでもいい」が俺の最終回答)、 まあじじいがいろいろ回顧する分には面白いよね、ということでリンク。 ．チェックできるのなら勝手に修正してくれ 。 全くもってそのとおりですね。UI は寛容に作るべし。 |
|
．X サーバってああみえて結構 C でギリギリの オブジェクト指向をやっていたりする。 いろんな構造体に対するメソッドは関数ポインタ間接になっていて 置き換えやレイヤ化が可能になってるし、 構造体のインスタンスデータ自体も devPrivate などというメンバを使って 拡張可能になっている。こんなもんを 80 年代末には完成させてたんだから、 それなりに頑張ったと思うぞ。 でもガーベージコレクションがないのは失敗ですな。 ．閑話休題、damage エクステンションってのもこういうレイヤ化可能な X サーバの内部構造を利用した拡張なんですな。 作ったのは keithp。ごく最近の XFree86 サーバとかには入ってます。 でも、一般でよく使われる X のエクステンションとは違って、 こいつはクライアントからは存在が見えないのでご注意を (注意する必要もないけど)。 別にプロトコルレベルの拡張をしているわけではなくて、 いわゆる mi (machine independent) コードの「拡張」を狙ったものですな。 ．こいつのやっていることは至極単純で、 主に GC (グラフィックコンテクスト)のメソッド関数(GCOps) の一番上に居座って、 すべての描画によって変更された領域座標(Region)を記録するというもの。 たとえば、一番単純なオペレータの一つである PutImage を取り出してみると、 次のようなコードになってる: 簡単に説明すれば、コピーされる領域の長方形の座標情報を取り出して、 それを damageDamageBox() 関数で記録した後、 本来の PutImage() を呼び出してる。 ．で、これがなんの役に立つのかというと、実は単体では全く役に立たんわけです。 しかしながら、これは直接画面に描画できないような (つまりバックバッファを介して描画するような)ケースでは 便利に使うことができます。 ．昔は、X サーバのポーティングを行うためには、 その対象プラットフォームで利用可能な描画命令を組み合わせる形で GCOps を実装していたのですが、XFree86-4.x 以降の X サーバには リニアフレームバッファに対する generic な描画フレームワークである fb というものが存在するため、 使えるかぎりはこれを使うようにすると実装は楽になります (まあ昔から mfb とか cfb っていう似たようなものはあったけど)。 しかし、X サーバのプロセスに対して リニアフレームバッファを暴露する手段がない 場合などには直接描画ができません。 この場合、従来のように GCOps を実装するという方法を使うこともできますが、 メモリとマシンパワーが十分にあるのならば、 すべての描画をバックバッファに対して行わせておくという方法を使うほうが、 実装は楽になります。 この際、バックバッファの内容と実際の画面の表示内容(VRAM)との sync を取るために damage エクステンションが使われるのですね。 ．実際にこれを使ってバックバッファの仕組みを実装しているのは shadow/layer エクステンションというものなのですが、 まあそれは別のお話。 |
|
．頼むから公開してください…… 。 気持ちはわかるが、そこをなんとか。 開けるだけでいいんだ、あとは何にもしないから(ぉぃ ．やっぱり実用上は softdep じゃなくて metadata journal が楽だよなぁ。 |
|
．このへん から こんなの 。 そういえば手元に csjudge っていう作りかけのライブラリがあるんだけども、 いろいろ考えることが多くて頓挫しとるなぁ。 いくらでも時間をかけてもいいのなら楽なんだけど、 文字コードの判別って割と速度的にシビアな用途ってのもあるので、 思ったよりもインターフェースを一般化するのが難しい。 ．もちろん日本語以外もサポートできるインターフェースにすることを 考えてるのだけど、直接変換アルゴリズムを指定する方法だと 今ひとつ柔軟性がないので、もっと抽象的な「言語」と「ヒント」 で何とかならんかなぁ、とか。 |
|
．居なくなる人々の送別会。私はまだだよ。 ．なんというか、もうどうしようもないところまで来てるわな、この会社。 ．二次会はいつものビール屋さん。 この店、壁に掛かったディスプレイでいつもわたくしのツボを突く映像を 流してくれるわけですが、今日は最晩年の Bill Evans トリオなわけです。 ．わたくし、Bill Evans という人は一番好きなピアニストの一人であるのと 同時に一番嫌いなピアニストの一人でもある。 このあたりに微妙な乙女心は、たぶん人に言ってもわからんと思うのだけども、 より具体的に言えば、この人のピアノのバウンス具合が好きでもあり 嫌いでもあるわけです。 ．Bill Evans という人はモダン以降のジャズに対する大きな影響力を 持った非常に偉大な音楽家なので誰もあまり指摘しないことなのだけども、 この人のピアノの弾き方の一番の特徴というのはもっと古臭い部分にある。 つまり一言で言えば「ブギウギ風のバウンズ」でして、 これが血となり肉となってるのでどんな音楽を演奏しても このブギウギリズムが右手のラインに顔を出してくる。 これが時として鼻につくのですが、 嫌よ嫌よも好きのうちというかなんというか。 ．で、最晩年の Bill Evans トリオ、 つまり Marc Johnson と Joe Labarbera のトリオなんですが、 私は Bill Evans のトリオの中ではこのトリオが一番好きなトリオなんですね。 Scott Lafaro と Paul Motian のトリオが金字塔であるというのもわかるし、 そして Eddie Gomez と Marty Morell のトリオがスタンダードであるというのも 納得できる。これらもそれぞれ好きなのだけども、どれが一番好きかというと Marc Johnson と Joe Labarbera のトリオになる。 1970 年代末から1980 年に Bill Evans が亡くなるまで、 このトリオは実質 3 年くらいしか活動してなくて、 Bill Evans の体調その他諸々の事情ですごく演奏にムラがあるのだけども、 特に本当に最晩年のころのこのトリオの演奏の叙詩感は どれも得がたいものがある。 次点は Eddie Gomez と Eliot Zigmund の「I will say goodbye」。 ．そんな Marc Johnson と Joe Labarbera の Bill Evans トリオの演奏の絵が 流れていたので、 シメイの青とブーングースを飲みながら上の空でそれを眺めていたわけです。 音はあまりよく聞こえなかったけど、そんなことは実はどうでもいいのです。 至福。 |
