スラッシュドット・ジャパン

リングノードベンチマーク - どう書く？org から。せっかくなので値の受け渡し方法を変えてみたり（list 1-4, 5, 6、doukaku.orgに投稿したのはlist 4）、いろいろな条件で計測してみたりしたところ、ブラウザの傾向が垣間見えて面白かった。調子に乗って、5回計測して平均を取るまでしてしまった。

(07/12 13:30 追記) list 6を追加

n*m = 1000*1000
          list1   list2   list3   list4
---------------------------------------
FF3.5.0
  old      7521    4264    1670    1608
  new      4262    3369    1459    1403
FF3.5.0 safemode
  old      1936    1077    1311    1346
  new      1805     992    1458    1397
Op 9.64    2047     869     767     615
Op 10b     2003     878     709     631
IE 6      19238    5106    5544    5240 [ms]

Window 2000 + Pen4 2.53GHz

Firefoxにおいて、oldとあるのは現在常用しているプロファイルでの、newは新規プロファイルでの実行結果。常用プロファイルはFireBugなどアドオンが数多く入っているが、FireBugを無効にするだけで新規プロファイルとほぼ同等まで改善する（FireBugのページごとのオンオフのUIで無効にするのではなく、アドオンマネージャでFireBugを無効にする必要がある）。FireBugは他のアドオンのエラーを検出することもあるが、そうした動作が影響しているのかもしれない。

セーフモードではさらに速度が向上するが、この理由はよくわからない。通常モードにおいてアドオンマネージャで拡張・プラグインをすべて無効にしても、セーフモードほどの数値は出なかった。

Operaでは、Firefoxの通常モードの倍以上速い数値が出たが、総ノード数を大きくしていくに従ってのオブジェクト生成の速度低下がFirefoxよりも顕著である（下表create）。ただし一旦生成してしまえば、ノードのオブジェクト呼び出しにおける速度低下はまったくといってよいほど見られない（下表call）。

n*m      5e4*20  1e5*10   5e5*2   1e6*1
---------------------------------------
FF3.5.0 new
  create    143     284    1583    3765
  call     1514    1559    1616    1631
Op 10b
  create    210     462    5281   16750
  call      784     772     781     784

list1-4ではノードを配列に格納しているが、配列の大きさによる影響は思いのほか少ないないようだ。list5のように、参照を張ることのみでオブジェクトを維持して巨大配列の生成を回避しても、速度低下を大きく改善することはできなかった。総オブジェクト数に依存しての速度低下だろうが、100万もオブジェクトを生成することはまれだろうし（200-250MBもメモリを消費する）、問題になることは少ないだろう。

書き忘れていたlist 6を追加した。もっとも素直に実装すればこの形になるかと思うが、オブジェクトにプロパティmsgがつき、若干ではあるがlist 3よりも遅くなる。

ノードを表すオブジェクトのメソッド (receive) が次のノードのメソッドを呼んでいくと、関数スタックがたまりすぎてしまう。ここでは配達人役の関数sendを用意し、メッセージを引数としてノードのメソッドを呼び、戻り値として次のノードへの参照と次に渡すメッセージ（通常は引数として受け取ったメッセージそのまま）を受け取る形にした。規定周回数に達したらメソッドreceiveはfalseを返し、それを受け取った関数sendは処理を終了する。

list 1-4で、sendに参照とメッセージを返す方法を変えている。list 1ではreceive内で参照とメッセージを束ねたオブジェクトを毎回生成している。

// list 1
var send = function (dest, msg) {
    var relay;
    while (relay = dest.receive(msg)) {
        dest = relay.dest;
        msg = relay.msg;
    }
    return msg;
};

var Node = function () {
    var id = 0;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            return {dest: this.dest, msg: msg};
        };
    };
}();

var n = 1000, m = 1000;

var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;

var t = new Date();
var lastMsg = send(ring[0], "read me in turn.");
t = new Date() - t;

alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);

list 2ではsend内でオブジェクトを用意しておき、各receiveがそこに書き込むようにして一つのオブジェクトを使いまわしている。

// list 2
var send = function (dest, msg) {
    var relay = {dest: dest, msg: msg};
    while (relay.dest.receive(relay.msg, relay));
    return relay.msg;
};

var Node = function () {
    var id = 0;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg, relay) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relay.dest = this.dest;
            relay.msg = msg;
            return true;
        };
    };
}();

var n = 1000, m = 1000;

// 以下list 1と同じ

list 3では各ノードのメソッドreceiveおよび関数から見える変数で受け渡している。この変数をクロージャによりグローバルから隠蔽しようと、関数sendもノードのメソッドにしてしまった。

// list 3
var Node = function () {
    var id = 0;
    var relayDest, relayMsg;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            relayMsg = msg;
            return true;
        };
        this.send = function (msg) {
            relayDest = this;
            relayMsg = msg;
            while (relayDest.receive(relayMsg));
            return relayMsg;
        };
    };
}();

var n = 1000, m = 1000;

var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;

var t = new Date();
var lastMsg = ring[0].send("read me in turn.");
t = new Date() - t;

alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);

list 3のようにメソッドsendを全オブジェクトに付加しても呼ばれるのは一つだけでメモリ効率が悪いので、list 4ではプロトタイプで付加するようにした。

// list 4
var send;
var Node = function () {
    var id = 0;
    var relayDest, relayMsg;
    send = function (msg) {
        relayDest = this;
        relayMsg = msg;
        while (relayDest.receive(relayMsg));
        return relayMsg;
    }
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            relayMsg = msg;
            return true;
        };
    };
}();
Node.prototype.send = send;

var n = 1000, m = 1000;

// 以下list 3と同じ

list 5。list 1-4で用いたコメントアウト部のコードに替えて前半部のコードを用い、配列生成を回避した。変数n2が次のノード（新規オブジェクト）を参照しても、一つ前のノードにはさらに前のノードからの参照が残っており、オブジェクトが開放されることはなくリングが形成される。

// list 5

var n0 = new Node();
var n1 = n0;
for (var i = 1; i < n; i++) {
    n2 = new Node();
    n1.dest = n2;
    n1 = n2;
}
n1.dest = n0;
n0.count = m;

/*
var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;
*/

(07/12 13:30 追記) 書き忘れていたlist 6。各ノードにメッセージを保持するプロパティmsgを持たせ、次ノードへのメッセージ伝達はノード自身が行い、メソッドsendは次順のみを管理する。もっとも素直に実装すればこの形になるかと思うが、list 3より若干遅い。（list 3を書き換えて再現したのでメソッド名と動作内容がかけ離れているが、差異がわかりやすいと思い、そのままにしておく）

// list 6

var Node = function () {
    var id = 0;
    var relayDest;
    return function () {
        this.id = id++;
        this.dest = this;
        this.msg = "";
        this.receive = function () {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            this.dest.msg = this.msg;
            this.msg = "";
            return true;
        };
        this.send = function (msg) {
            relayDest = this;
            relayDest.msg = msg;
            while (relayDest.receive());
            return relayDest.msg;
        };
    };
}();

var n = 1000, m = 1000;

// 以下list 3と同じ

2008年末にGizmodoは、Steve JobsがMacworld 2009の基調講演をキャンセル、理由は病状悪化という噂を伝えた。

• Gizmodo - Steve Jobs' Health Declining Rapidly, Reason for Macworld Cancellation - Steve Jobs' health
• Gizmodo Japan: ジョブズの病状が急速に悪化、それでMacworldも欠席、という噂

これにCNBCのシリコンバレー支局長Jim Goldman、即座に反応した。

• Jim Goldman's Tech Check: Apple's Jobs is (Still) Fine

（要旨）Gizmodoの報道は大チョンボだが、おかげでApple株に赤信号が点ってしまった。好意的に見てもソース薄弱のブログなど忘れてしまえ。Apple社内の複数のソースによると、Jobsの基調講演キャンセルは健康問題からではない。AppleがMacworldに見切りをつけたことの一環だ。

株価操作のためAppleが嘘をついているなら監獄行きの者が出るだろう。私はそんなものを伝えたくないし、もっと差し迫った健康問題そっちのけでくだらない噂を流したくない。Appleから材料が出てきたら私はそれを信じる。一方、ソース無しのガラクタが自社株を台無しにしたって、そりゃそうだと言うしかない。

ところが2009年に入ってすぐ、Jobsが噂を認めるリリースを出す。

• Gizmodo: Confirmed: Steve Jobs Prioritizes Health Above Macworld - Steve Jobs Health
• Gizmodo Japan: ジョブズ、Macworld欠席理由は健康問題と書簡発表

さらには、Jobsが6月まで療養を優先するリリースを出す。

• Gizmodo: Steve Jobs Taking a Leave of Absence From Apple Due to Health Problems - Apple
• Gizmodo Japan: ジョブズ、6月末まで休業へ

するとGoldmanは、今度はAppleに矛先を向けるのである。

• Tech Check with Jim Goldman: For Apple's Jobs, What a Difference a Week Makes

私は過去数ヶ月間、Jobsの健康問題を追ってきたが、カルテを見られるわけではないし病状の重さを追っているのではない。ではなく、Appleが出す材料、彼がCEOとして会社を動かせるかどうかの情報に見ることができる、Appleの与信上の責任を追っているのだ。基準はまったく単純、動かせるか否かだ。彼が瀕死でも何とかやっていけているなら、理屈の上ではAppleは、彼の健康にまつわるプライベートな詳細を明かす必要がない。これは法的には申し分ないが、倫理的にはそれほどでもない。Appleがやったのはそういうことだ。

精密検査をやったらホルモンバランスが崩れているのがわかった、それからたった一週間で、健康状態が思っていたより複雑だったとわかった（ので6月末まで療養する）という。疑い深くて悪いが、良く言っても「率直でない」、悪く言えば「誠実でない」ように思える。与信・倫理・財務面での仕打ちに等しい。

実は先週末、Jobsと非常に親しい業界内の重役二人からの情報を受けていた。うち一人は数ヶ月前まで定期的に連絡を取り合っていた人物だ。どちらも他意はなく、Appleの株価操作をもくろむような者じゃない。どうか信じて欲しいがどちらも相当な金持ちだ。驚いたのは、どちらもJobsの健康状態に「深い懸念」を抱いて私に話さずにはいられなくなった、ということだ。一方は長年の付き合いから、Jobsが状況の悪化について「断固拒否」している、という。もう一方は「深い懸念」を抱いており、突然連絡が途絶えてメールや電話などにも返答しなくなったのは「深刻な」状況の現れだ、という。

どちらもJobsの治療について直接知っているわけではないが、それまでの付き合い、Jobsの言っていたこと、最近のJobsの振る舞いから判断をしていると言っていた。

この月曜に私はJobsにこの件について、ごく個人的に記して送った。返答はなかった。Appleの誰かさんから、例の重役たちとJobsの健康問題に関して私が何をやっているのかと訊いてくる電話は受けた。私はこの人物に、Jobs宛ての電子メールを読んだのならわかるはずだと答えた。私はAppleに、我々は更なる情報収集に努めるつもりで、AppleおよびJobsに返答を検討するための機会を与えようと考えていることを伝えた。それが昨日（火曜）の事だ。もう少し時間を与えたかったが。Appleは、同じように近しい社内の者で私に打ち明ける者が出始めたら、彼らや他の者までが私以外の者に対しても話し始める可能性は大いにあることに気付いたに違いない。

我々がAppleの手を動かしていたとは言わないが、ほんの一週前に「これについて、言いたかったこと、そして言おうとしていたすべてのことからすれば言い過ぎてるくらいなので、このあたりで」と簡潔に締めくくる別のリリースを出していたことを考えればなおさら、我々が今夜のリリースにわずかながらも荷担していたと思わざるを得ない。今にして思えば、彼にはもう少し、周りの者が彼に言い出す前に言いたいことがあったのだ。

それはともかく、彼の健康状態は動く標的のようなもので固定しておくのはかなり難しいはずだし、2004年の最初の診断から変化・進行していてもおかしくない。Jobsが変調に気付かなかったと言ったとき、彼はそれが事実に基づいたものとして疑わなかっただろう、と思う。それが最近まで続いていた、精密検査を受けて初めて医師たちが変調に気付いた、そのようにJobsが言うなら私は信じる。Jobsの健康状態がどんなものにせよ変わり続けるものと言うソースがあれば信じてきたし、今も信じ続けている。

私がひどく手を焼いていることは何かといえば、今週これまでに起こったことに他ならない。先週の記述は真実かもしれないが、私は、今週の彼の記述を信じるにあたっては重大な問題を抱えている。そこには不誠実の気配以上のものがある。クパチーノをまっすぐに狙ったメディアミサイルの存在を確認しても、噂の後手に回って掃討するのではなく先んじて公表に努めていて、そのうえでの記述であれば私も信じた、原因はそういったことだろう。すべてに関するAppleの戦略は最初から、妙なものだった。すべての中心にあれほど気まぐれな男がいるとなれば、それほど驚くにはあたらない。

私はもう、白日の下にさらすことがすべての雑菌を殺すと信じるしかない。同社がすべきだったことはただ一つ、最初からすべての者に正直にあれば良かったのだ。我々が知りたいことを語るのではない。ではなく、我々が知る必要のあることを語るのだ。Appleはこの分野の先駆者になり、透明性の新領域に火を点すことになっていたかもしれない。ではなく、別の道を選んだ。そのツケを払うのは、株主、ファン、Appleコミュニティだ。

これはまったく残念だ。私は、Jobsが言うように彼が6月に復帰することを心から願う。しかし現実的になれば、彼が他になんと言おうとも、私はそれを当てにすることができない。

なんというか、苦しい。CNBCのニュースショーでも「健康問題は動く標的のようなもので... 精密検査をしたら...」などと弁明するも、偽Steve JobsをやっていたNewsweekのコラムニスト、Daniel Lyonsに「とにかくGizmodoに謝れよ、視聴者に謝れよ」と叱責され、案の定だがGizmodoにも再度突っ込まれる。

• YouTube: Dan Lyons takes on Jim Goldman on CNBC
• Gizmodo: On Apple Reporting: Fake Steve Rips CNBC a New One
• Gizmodo Japan: 偽ジョブズ、CNBC生放送中に謝罪求め騒然（動画あり）

話は若干それるが、Goldmanはその後、Gizmodoのイジられ役になってしまったようだ。

• Gizmodo: CNBC Is Ridiculous: Macs Come With Photoshop, PCs Need $600 Extra to 'Perform As Well As a Mac' - Cnbc
• Gizmodo Japan: PC vs. Mac価格比較でNBC記者「Windowsは6万円分買い足して初めてMac並み」（動画）

で、6月末。Jobsが肝臓移植手術を受け、復帰も近いと報じられるようになったタイミングで、期待を裏切らない男Goldmanが、今度は手術に投げかけられた疑問を採り上げる――のが表のストーリーの元記事。ところで「Tech Check」か？ これ。

• Tech Check with Jim Goldman: Jobs and Hospital Answer the Critics - - CNBC.com
• Slashdot Japan: スティーブ・ジョブズに「移植用肝臓を金で買った」疑惑、病院側は否定

「instead of」を訳すとき、しっかりと内容が把握できないうちは「ではなく」を選ぶのが無難だと思う。

「instead」の意味を調べると、たいてい「 [副詞] 代わりに、〜に代わって、〜しないで、それどころか」のように示されている（Exceed、英辞郎、プログレッシブ）。 いずれも置換・入れ替わりを意味する言葉だが、用法としては（先にAを述べて「B instead」の場合）、

• 消極的理由から採られる、Aの代理・代用・相当品としてのB。Aと同様もしくはそれ未満の役割・効果を持つ
• 積極的理由から採られる、Aとは別の選択としてのB。Aとは別の役割・効果を（も）持つ

のように幅があり、文意としてはまるで逆になる。どちらなのかは「instead」だけでは判断できず、文脈から判断しなければならない。「instead of」で意味を調べると「〜の代わりに」「〜に代わって」としか示さていないものもあるが（英辞郎）、用例ではやはり後者に近いものも多い。

その一方で日本語の「代わり」という言葉は、前者（同様の役割・効果）を連想させてしまう。文脈がはっきりしないうちは、どうとでも取れる「ではなく」あたりが無難だろう。

ウェブ検索で用例を調べてもみたが、「代わり」が使えそうなものは意外と少ない。「Fox sticking with schedule instead of Obama」（米Foxが大統領の会見中継よりもドラマ『Lie to Me』の放映を優先した話）の訳に「代わり」は使えない。スケジュール通りならならドラマでそれに替わっての会見中継だから、「大統領の代わり」じゃないだろう。「instead of notepad」にしても、「Gedit instead of notepad」というような相当品を示す表現もあるものの、（メモ帳よりも便利だからという）積極的理由からの選択を示す表現が多い。ここでも「代わり」はふさわしくない。

深く考えずに「代わり」を充ててしまうと、場合によっては訳者による誘導とも受け取られかねないので、注意したい。

----

というのは下記コメント（強調は引用者）を受けての内容だが、特にmasakunさんに充てたものではない。

Officially known as Darwinius masillae, the fossil of the lemur-like creature dubbed Ida shows it had opposable thumbs like humans and fingernails instead of claws.

かぎ爪の代わりとなる指の爪と、ヒトのように向き合う親指(opposable thumbs)を持っているとのこと。

続くコメントではこれを手係りに考察を重ねているが、誘導しようとしているのか自ら誤誘導されてしまっているのか傍目に判別できないような有様では、「慌てなさんなはしゃぎなさんな」としか言えない。また、私はID論について屁理屈ぐらいにしか思っていないが、私自身がID論そのものの批判にあたるのは時間の無駄と考えているので、誤りの指摘にとどめている。議論はしないよ。

ここのところ、常用しているFirefoxでスマートロケーションバーを多用するようになった。

手元の環境での反応速度は今のところ許容範囲に収まっているし愛用しているのだが、キーワードを入力したあと表示された候補を選ばずにうっかりEnterキーを押してしまい、思いがけずI'm Feeling Lucky相当のリダイレクト先に飛ばされてしまうことがある。キーワードは忘れたが、「18歳以上ですか YES/NO」が書かれているページに飛ばされてイラッとしたこともあった。

ここをI'm Feeling Luckyではなく普通のウェブ検索にしたい場合、about:config の keyword.URL の設定を変えればいい。I'm Feeling Luckyを活かしておいて特定キーワードでのリダイレクトだけを抑止したい場合には、一旦そのキーワードでウェブ検索し、サーチウィキで当該不要ページをはじいておくと良いようだ（サーチウィキの効いたウェブ検索結果ページに飛ぶ）。

ところで、いろいろ試している途中で何気なく「o」を試すといきなり終わってしまった。Ctrl+L、O、Enterというわずか3ストローク先にこんな結末が待ち構えていようとは、思いもよらなかった。

オフトピなので日記に。「わざわざ主語を転倒させてまで強調」というのは深読みのしすぎではないかと思う。確かに記事の主旨は「測ってみたら言われているように『かなり速くなっている』わけではなかった」だが、同個所については文意の明確化ぐらいにしか感じなかった。

同箇所では3つの事柄を伝えようとしている。

1. 「それぞれのPC (a)」はWindows 7を走らせた場合にわずかながら速かった
2. しかし全体的な改善が「5% (b)」を超える「ケース (a)」は無かった
3. 「5% (b)」は我々の閾値であり平均的ユーザーが性能変化を認識できる場面を想定

英語でも素直に書いていけば語順がほぼ上のとおり、(a)の距離が一番大きく離れ、さらに(a)(b)が互い違いになってしまう。原文のように書けば(a)はコンマ区切りそれぞれの前方に、(b)は区切り位置で一つにまとめられ、互い違いは解消される。

何語だろうと文は前から順に読んでいくもので、文法の平易さよりも、述べる事柄の位置関係の単純さを優先するほうが読み書きしやすい場合がある。同原文の場合でも、倒置程度でどれが主語かと気になるような読者でないかぎり、素早く文意を掴むことができる。ネイティブの人はほとんど気にも留めないのではないかと思うのだが、どうなんだろうか。

余談だが、「may」についてはこちらのACさんの書いたとおりだろう。で、文脈読めとか書いてるほうの人は、「性能評価記事に主観的表現はふさわしくない」とは思わないんだろうか。計測条件や結果を明記しておいて結論は「おおむねそのようです、もしくは、そうなんじゃね、みたいなニュアンス」で書かれていたら、どうにもしまらない記事になるだろう。大文字病の人には、わからないかな。

流行ったのは2年ほど前だが、論理演算子を使えばいろいろ簡潔に書けるといまさらながら解って、使いたくなってしまったと（三項演算子のことじゃなくて、...||iの部分）。面倒くさいのでFirebugのコンソールで。せっかくだからツメツメで。

for(i=1;i<101;i++)console.log((i%3?"":"Fizz")+(i%5?"":"Buzz")||i)

""が2回出てくるのが無駄っぽく思える。で、"FizzBuzz"から切り出せばいいのかと気づいたが、

for(i=1;i<101;i++)console.log("FizzBuzz".slice(!!(i%3)*4,8-!!(i%5)*4)||i)

長くなってしまった。それに、「さらに7の倍数のときには（...何？）」とか条件が加わるとアウトだ。

日中にコメントの付いていないストーリーを見つけると元記事も読まずにあわてて短い難癖をつけるいつものAC氏と、それに便乗するID氏。

前者は「1got」と書かないだけの1got野郎、後者はyasudas二世さん。どうせたいしたものは出てこないんだから、手短かに訂正だけして、あとは放っておけばいいのに。

割り算の筆算 どう書く？を、JavaScript（+それを呼び出す手抜きHTML）でやってみた。コードはそちらに。n、mは正の整数に限定。

fが空欄のまま（もしくは0以下の数、数値として評価できない文字列）の場合、整数の範囲内で除算を行う。

n = m * q + r (within integer)
n: 1000
m: 71
q: 14
r: 6

          1 4
    ----------
7 1 ) 1 0 0 0
        7 1
       -----
        2 9 0
        2 8 4
       -------
            6

fに正の整数を指定すると、商がその桁数に達すると筆算を止める一方で、小数点以下になっても筆算を続ける（止まったときに商より剰余が大きい場合がある）。

n = m * q + r (up to 4 figures)
n: 1000
m: 71
q: 14.08
r: 0.32

          1 4.0 8
    --------------
7 1 ) 1 0 0 0
        7 1
       -----
        2 9 0
        2 8 4
       -------
            6 0 0
            5 6 8
           -------
              3 2

小数部をもつ商をどうしようかと考えた挙句、中間表現として各桁を配列qに入れた（小数部の桁に相当する要素の添字は負数になる）。小数部から始まる場合 (n < m) の処理をループから除外できそうに思えたからだが、それほど効果はなかったかも。

それによって書くことになった商の出力文字列化には、JavaScriptのへんてこ仕様（Array.lengthは、要素総数ではなく最大添字+1を返す）を利用した。

そういえば英国でもGoogle Street Viewが始まってたんだっけ。というわけで観光。

• GSV: the zebra crossing
• en.wikipedia: Abbey Road (street)
• Abbey Road - Google Sightseeing

FirefoxではSVに切り替わったあと表示が進まないが、なんで？

（04/09 22:00 追記） Operaでは問題なく表示され、Firefoxでは進まない状態だったが、いつのまにか再発しなくなっていた。手元の環境だけだったか、などは不明。