Webをぐるぐるしていて知ったのだが「のまネコ問題」なるものがあるらしい、詳細は調べればすぐ見つかるので省略するとして、ユーザー側応援サイトなどではAvexの対応について色々書かれているが大企業の企業体制としては (社会的モラルの是非や戦略としての有効性はともかく) ごく順当な回答な気がする. 問題の内容自体は個人的にはどうでも良い事柄だが、現象としては行く末が面白そう.

結局の所旧来の企業主導型のメディア展開に対し、コンピュータネットワークの発展によりマイナーからメジャーにシフトした個人レベルの情報発信というものが、何処まで影響できるかを知る良いサンプルが得られるかもしれぬという所.

特に既に製品体制を整えているという事は企業側としても容易に妥協すれば比較的大きな損益を被る事になるので、それ相応の抵抗が期待できる. そういった意味では安易な事なかれ的結末に落ち着く事も無く、観察している側としては有意義なデータが取れる可能性を秘めている. ましてやここでの企業体制側は腐った利権主義で肥大化した豚(※1)(一般的なイメージにおける比喩的表現であり別段悪意や揶揄する意図がある訳では無い)である訳で、これは面白い流れが観察できるやもというトコロ.

とは言え元の失策の要因を言えばAvexが軽率なのだろうなぁ、と思う内容ではあるが、短期的な利益を諦めて製品として破棄しちゃえば良いのに(笑)
まぁでも製品イメージがキモカワイイという事であると比較的音楽関連グッズの主要購買層に受けそうなネタなのでそう安易に手放すのは惜しいという所か?

そういう意味では経過が面白そうで、また上手い具合に新しい材料が含まれるケースとして発展して欲しい話だと思う.

---------------

※1) もうずいぶん前の話(学生時代の頃)になるが、数年間デザイン事務所でバイトしていた経験があり、音楽・レコード業界や広告業界などとも繋がりのある事務所(アーティスト関連のイベントや新人アーティスト売り込み戦略の一部なんかも担当していた)だったので、その辺の腐った話は割と見聞きした内容だったり、余り詳しくは書かない方が良いのだろうけど、バイト時代の事務所、上の騒動の会社なんかとも取引が、、、(笑)

ダメだぁーこりゃ、多分だけど予想以上に悪い. うん.

# はっきり言って意味を成していないが、煮詰まった時に何処かに書きたい事もあるという事で.

チャリ購入、雨の中取りに行く、帰りにずぶ濡れに. 雨がやんだので夜中にこぎに出る、自転車に乗るのは5年ぶり位か. 帰ったらそんなにこいでない筈なのに体が痛い. 自転車の乗りすぎかはたまたライトセーバーの振り回しすぎか?

どうせ自転車なんぞ一番重いギアから数段しか使わないのだけど、体感速度が以前乗ってたのと大体同じ気がする. 自転車のギア比もメーカー基準みたいなものあるのかな?

まぁこれで近所の商店街などブラブラしてみようと思う、原チャメインなので4年近く住んでいて全然近所の商店街とかに行った事が無い事に今更気付いたり(苦笑)

---------------

スターウォーズのライトセーバーを2本購入、コレとコレ 本当はヤフオクで購入したのだが入札先がアメリカの会社とかいう話で、本当に届くのかどうか、届くにしても時間がかかるとその間要らぬ気をもまねばならない為、国内で売っている店を教えてもらったのでそこで2本購入、まぁもう2本届いたら壊れた時の予備という事で.

2〜3回振り回して飽きるかと思っていたのだけど思いの他出来が良く、振り回しているうちにテンション上がってきて恥も外聞も無く外で思い切り振り回したい衝動にかられる. 柄の部分は本当に工業製品のレプリカという出来でオモチャ臭さは全く無いし、ブレードはプラスチックなれど暗い所での発光具合は映画の中さながらというカンジで非常に重厚感もある素晴らしい出来.

本当は写真など取ると良いのだろうがデジカメを持ってないので写真は無し.

# なお面倒なので当日お持ち帰りできる店を探したのだが、おかげで珍しく電車に乗る羽目に、んで身体的問題からやはり不快な思いをする羽目に、だから電車は嫌い、そして自分の枠内の常識でしかものを図れぬ人間も大嫌い、別にわざとやってるんじゃないのに、、、sigh
何故電車イヤなのという問いに詳しい問題を話すのがイヤなので「心の病気です ;-)」と言っているのだが、マジで心の病気になりそうな気分ですよ:-<

---------------

仕事がプチ忙しいのでファイナライザの話は後回し、というか結論としては実装は完了、実装形式は全ての標準スコープのオブジェクトに対しファイナライザが実行される事が保証され、インタプリタクリーンナップ時に呼ばれたファイナライザ内で作成されたオブジェクトにのみ呼ばれない事があるという具合. しかし実装して気づいた話だが、GCアーキテクチャにおけるファイナライザの実装を通して見えるのは、現在自分が開発しているJavaScriptインタプリタに限らず、ほぼ全てGC言語においてファイナライザはかなりヤバい代物だと言う事、そのヤバさはC言語でgotoやlongjmpを使うといった議論のレベルでは無く、個人的感想としては「絶対使うべきでは無い機能だが、絶対使うなという話だと現実のリソースに対する管理とGC言語の理念に矛盾が生じる為、どうしようも無い場合にだけごく控えめに使っても仕方ない機能」という印象.

無論ここで書いているどうしようも無い場合などというのはちゃんと設計してたら殆ど起りえないレベルの話だとは思うが、そもメモリの所有権の曖昧さに起因するGC言語の提示とそれを前提にした粒度の細かいクラスライブラリモデル、明示的にクローズされねばならないリソース(その為には所有権が明確でないとならない)というのはその時点で設計的矛盾を持っている為、これらリソースの所有をどこまで考慮し、どこから放棄するかのバランスは少々難しい問題かもしれぬなどと思ったり.

個人的にはリソースは全て明示的にクローズ・破棄するよう設計し、ファイナライザは解放忘れのリークチェッカとして使うに留め、その上でリリース版ではファイナライザ部は破棄すべき機能に思える.

なお関数呼び出しのパフォーマンスは2倍まで改善、これでJScriptの1/5までは縮まった. なお先日の日記で書いた構文木のトラバースがJScriptの1/5と書いたのは間違いで正確には1/2.5、なおPerlについてはそのままの速度、まぁこれはMSのJScriptなどはエンジンも優れているのだけど、それでもPerlの構文の単純さに対しJavaScriptなどのオブジェクトタイプ言語では構文要素がはるかに複雑な為、まぁそんなトコロだろう.

そういった意味ではRubyの速度はかなり頑張っていると思うし、Perlと比較して遅いと言われるのもかなり気の毒な話だよなぁと思ったり(そもそも実行時に解釈される構文構造の複雑さが全然違うので)

# 余談だけど世間で言うRuby信者とかJava信者とか痛いステレオタイプで表現されるような人間って本当にいるのかな、実はそういうのはイメージの上でデフォルメ化されたもので、実際にはそんなプログラマはいないのでは、などと思ったり. 余り自分の周囲で見た事無いし、実際そこまでバカな人間もそういないのではないかと思うのだけど. まぁ居るなら居るで是非実際にお目にかかってとことん痛め付けてみたいというサディスティックな期待もあるのですが(マテコラ

<意識しても疲れるだけなので削除>

相変わらずJavaScriptいじり中.

ちょっとベンチマークを取ってみたが関数コールが遅い、MSのJScriptの10倍程度かかっている. MSのエンジンはバイトコードタイプなので、それより遅いのは当然なのだが、それでもコレは少々重すぎ. ちなみに構文自体のトラバースはバイトコードタイプ(JScript,Perl)の1/5程度、C++の内部構造とマッチさせている部分の冗長さからRubyの60〜70%程度でこれは妥当な所、関数コールが重い理由は一つにはクロージャサポートの為関数コンテキストが使い捨てでは無く、オブジェクトとして生成される為、その生成・初期化コスト. もう一つは戻り値の処理にC++例外処理を使っているのだが、これが思いの他重く、この部分を例外処理を使わないようにするだけで1.5倍程度の改善が予想される.

んー取り敢えず関数戻り値とbreak/continueだけ書き直そうかしらんとつらつら考える. まぁそれでも○○(作者及びコミュニティの名誉の為割愛)の10倍速いが(結局の所オープンソース神話も余りアテにできぬと痛感)余り慰めにならぬ(笑)

---------------

eval&関数コンストラクタ対応の為構文木自体をGC対応にする案は大体設計が見えてきたが、取り敢えず遊びでdll呼び出しを先に実装してみる. 現状こんな具合.

var MB_OK               = 0;
var MB_OKCANCEL         = 1;
var MB_ICONEXCLAMATION  = 0x30;
var IDOK                = 1;
var IDCANCEL            = 2;
var MessageBox          = new DllFunc("user32.dll", "MessageBoxA", "s", "i", "nssi");
var MessageBoxW         = new DllFunc("user32.dll", "MessageBoxW", "s", "i", "nwwi");

/*-------------------------------------------*/

if( IDCANCEL == MessageBox(0, "続行しますか?", "Info", MB_OKCANCEL|MB_ICONEXCLAMATION) ){
    print("Operation canceled");
    exit(0);
}
MessageBoxW(0, "これはUnicodeです", "Info", MB_OK);

バイナリバッファを扱う場合はこんなカンジ、現状バイナリバッファのみだが、これを構造体タグが定義でき'.'演算子でメンバを参照可能な所までｊは作る予定(構造体内に他の構造体へのポインタが入っているようなものはサポートできないが流石にこれは致し方無し)

var puts    = new DllFunc("msvcrt.dll", "puts", "c", "i", "s");
var _gets   = new DllFunc("msvcrt.dll", "gets", "c", "i", "b");

function gets(){
    var buff = new BinaryBlob(1024);
    return (0==_gets(buff))? undefined : buff.toString();
}

/*-------------------------------------------*/
var s;
while(undefined!=(s=gets())){
    puts(s);
}
puts("done");

DLL呼び出しを作ってみて、これでネイティブリソースを自由に呼べるようになったのだが、こうなるとリソースリークし放題のプログラムも作れてしまう為、非常に問題を感じる. という事でECMA言語仕様には存在しないがファイナライザの必要性を痛感し、これの実装を試みる事にする.

(後編に続く)

珍しくプログラムやLW以外の話題、Rebirth-338が開発終了に伴いFree化されたとの事. ちなみにRB-338はテクノ系で伝説的に有名なRolandのTB-303,TR-808,TR-909と言うアナログシンセサイザー(というか元々はリズムマシン)のエミュレーションソフト.

早速ダウンロードしてインストールしましたが、何も言う事なく限りなく素晴らしいの一言に尽きますええ.

テクノ好きなら例え作曲ができなくてもループ単位の編集なのでそこそこ楽しめ、何より大音量のヘッドホンつけて弄っているだけで気持ち良くなってトべる逸品(ヲイ)なのでマジに万人にお勧めデス.

---------------

実際は何か音が出るものが欲しいなーと思って昔欲しかったMC-303とか調べてて見つけた話だったり、というかMC-303販売終わってたのね. 現状ある同系統のマシンだとMC-909しか無いみたいだけど、流石にちょっと高すぎ(実売16万程度)

サンプラーは面白そうだけど、遊びで触るなら303位の方が良いのだけどなぁ、まあいざとなればヤフオクで(笑)

更にJavaScript、コアは大体完成した.

まずは訂正、先日JavaScriptにデリゲートが欲しいと書いたのだが、これは自分の間違いであるように思う、というのもそもそもクラスの概念が違う為で、たまにJavaScriptのサイトなどでthisをカスタマイズしてクラスを作るとあるが、これは正確には間違いでthisはクラスの外に公開する「関数のみ」を公開するインターフェイスであり、メンバ変数などはクロージャ内のローカル変数として定義、それにアクセスするにはgetter/setterを定義するというのがJavaScriptでの正確なクラスインスタンスの扱いのように思う.

何故thisにインスタンスメンバを設定するのが間違いか、については例えば以下の例のような具合になる.

function Foo(msg){
    this.msg="this: " + msg;
    this.say=function(){
        print(this.msg);
    };
    this.say2=function(){
        print(msg);
    };
}

var a=new Foo("I'm Foo1");
var b=new Foo("I'm Foo2");

invoke(a.say);  /* ここでデリゲートが欲しいワケだ */
invoke(b.say);
invoke(a.say2);
invoke(b.say2);
a.say();
b.say();

function invoke(func){
    func();
}

--------------------------
<実行結果>
undefined
undefined
I'm Foo1
I'm Foo2
this: I'm Foo1
this: I'm Foo2

つまりJavaScriptの場合は<オブジェクト> . <メソッド>の形式で呼ぶ限りはthisにオブジェクトが入るのだが、メンバのみをコールバックに渡してそれが呼び出された場合などはthisにはそのオブジェクトは入らない事になる (メソッドだけ渡すようなこういうコードパターンが必要なケースはプログラマなら容易に想像がつくと思う) またどうしてもthisに閉じ込めたい場合は回避策としてはこんなものもある.

function Foo(msg){
    my=this;    /* thisは処理系が勝手に設定してしまう為ローカル変数myにthisを保存する */
    my.msg="this: " + msg;
    my.say=function(){
        print(my.msg);
    };
    my.say2=function(){
        print(msg);
    };
}

var a=new Foo("I'm Foo1");
var b=new Foo("I'm Foo2");

invoke(a.say);  /* ここでデリゲートが欲しいワケだ */
invoke(b.say);
invoke(a.say2);
invoke(b.say2);
a.say();
b.say();

function invoke(func){
    func();
}

--------------------------
<実行結果>
this: I'm Foo1
this: I'm Foo2
I'm Foo1
I'm Foo2
this: I'm Foo1
this: I'm Foo2

自作のインタプリタで無くともMSのWSH上のJScriptなども同様の結果を出す.

---------------

上記の問題や、他にも

> "Hello world" instanceof String => false
> new String( "Hello world" ) instanceof String => true

となってしまう言語仕様、使い物にならないfor〜in構文、また上の instanceof演算子は本来静的なクラス宣言（JavaやC++など)を持つオブジェクト指向言語が持つべきもので、動的なオブジェクトの(擬似)継承構造を持つJavaScriptに向いているとは到底思えない (instanceof自体元々のコアJavaScriptには無く後付けなので、多分その系統の言語に慣れたプログラマの要望を取り入れた結果だろうが、それを主張したコミュニティに「アホか」と言ってやりたい気分:-P

詳しく中身を知るにつれJavaScriptの穴が見えてきており、少々この言語が嫌いになったのも事実ではある(笑)
でもJavaScript 2.0の路線も正直どうかと思うが、JavaScriptを何の工夫も無しに今の手間のかかる開発言語の類(C#,Javaなど、C++はもっと手間がかかるので除外) と同じ所に持って行ってどーするの、みたいな:-P

関数宣言するのにいちいちこんな↓
> public function foo( a : int, b : uint) : double { ... }
書き方をしなければならない言語(JavaScript 2.0)はそも論外だと思う、Javaよりタイプ量多いやん :-<

# 余談だが.netのJScript.NETでアプリを書くとC#などの言語とほぼ一対一の関係のコードになる、、、絶対それ違うだろう、と思う事しきり.

# 更に余談だがC#3.0の型推論もどうかとは思うのだけど、VBについてはアリかもしれないが、ラムダ式は良いのだがメソッド拡張とか(構文糖だが、これを駆使するとソースコードが見難くならんかな、無秩序な拡張に近い部分があるし) ソレ要るのかなぁと思ったり(少なくともvar型と型推論はC#には要らん気がする、VBプログラマの全てを否定するような内容かもしれぬが:-P 少なくともエンドユーザー向けのJavaScriptと違いC#は「プログラマ向け」の言語で、想定開発対象としてクライアントサイドのある程度複雑なアプリまで視野に入れるなら、余り過度に隠蔽するモデルでプログラマを「馬鹿」にするようなアプローチも要らんのではないかなぁ、と.(型を考えるという所が完全に無視してもパフォーマンスに影響しない所までPCが進歩していれば良いけど、まだエンプラ系なんかの単体プログラムの構造は単純な世界は良いかもしれないが、クライアント系ではこの辺がかなり影響する個所も残っているのも事実.

# 別にエンプラ系を馬鹿にしている訳でも無く、あの系統はプログラム単体よりもバックのデータモデルがどうなっているか、とかそういう設計や組み合わせなど全体としてのモデリングが重要だったりするワケで、そういった意味では各プログラムはそれ程重要な要素ではないし複雑である必要もそれ程無いという所(実際には接続数などでのパフォーマンス維持は非常に重要な部分もあったりするけど、根本的にはクライアント系の複雑さとは種類が違う).

---------------

まぁ口だけで偉そうな事を言うのもアレなので、上に書いた自作のインタプリタの現状など置いておく(ソース付き、まぁやる人もいないと思うけど著作権とかは全面放棄扱いで)

ちなみにまだ構造を試行錯誤している段階なので凄まじく汚いコードになっているしモジュールの分離もしていない、関数はgc,print,printfしか無いし各オブジェクトは配列と文字列のlengthプロパティ以外何もメソッドは持ってなかったりするが、構文要素としては現在のJavaScript1.xの構文の殆どをパース可能であるし、言語の内部構造としては殆ど揃っていると思う (eval対応の為に構文木自体をGC対象とするという大仕事が残っているが)

なお自分の好みの問題から文末の ';'は省略不能、まぁ現状報告程度にて.

# というか仕事も忙しくなってきているし、微妙に飽きてきたので中区切りというカンジ ;-)