つぶねこ

♦ タコ焼き

♦ クラウド

　悪戯された死神の封印にスタンプが押されて、
　「15月の旅、わん～～～～～～！」
　例によって乳母に騙されてタコ焼き姫とお近づきににゃりかけるクラウド。
♦ ストンストン

♦ シルバー

♦ 月

　かわってシルバーの方は、ストンストンがタコ焼きを食していたりして、相変わらずクレヨン王国の捕食関係は素晴らしいものがあるにゃ。
　でもって黒雲と骸骨の月。実際の所、この月はかにゃり怖いにゃ。
♦ シルバー号

♦ シルバー

　「おみやげ買ってきてね」のシルバー号。
　ほのぼの土産談義してるとクラウドに

せかされる。そりゃにゃぁ・・・　さらに「え～、今から～？」と緊迫感のにゃいシルバー。封印方法分かってるからってのはちょっと安易にゃ気が。
♦ プーニャ

♦ じ～～っ！

　例によって毎回妖しい乗り物を使ってるプーニャ。わざわざ死神復活を吹き込む♦ プーニャ

天使ども(笑)
　今回の野菜の精は、

ネギックと

ソソソナス
　「こんにゃところで会ったが百年目でございますです」という死神VSプーニャの続きは見てみたかったにゃ。
♦ 死神

♦ トナカイ

♦ ヤマアラシ

　どっちかというと二次災害というかにゃんというか・・・迷惑。いろいろと懐かしの面子も出てきているんだが、どうせ次回もあるので。
　にゃんかクラウドを含めてオールメンバーにするのにえらく苦労してる感じ。
♦ お返事は1回

♦ シルバー

♦ プーニャ

　あと一応シルバー号のあたりから、「お返事は1回」ネタが続いてるんだがストーリーとは無縁。
　プーニャの乗り物ネタもそろそろ無理が来てる気もする(笑)
　今回はシナリオと作画に天使の悪戯って感じ。
　次回、
　「夢のクレヨン王国 15月の旅、つぅ～～っ！。脳みそくすぐっちゃうよ」

　父は消防士、母はナースというそれにゃりにレアにゃ家庭のまりんとメラ・・・いや、マリンとヤマト。

　おとこのこはテレビゲーム、姉はゲーム屋のバイト生にときめく華の小学生である。リボンとまつげが主体。

　公園で見つけたのは猫に食されかけている、喋るひよこ2匹。っっって両方とも雄かよ！！

　ねぎラーメン！とかは言わにゃいが、妖精さんの模様。科学に毒された2人はもちろん信用しにゃいのであった。

　税金だけを無くした直後の世界へ飛ばされた2人。ハゲオヤジに白昼堂々と体で払わされようというマリンを目前にして何も出来にゃいヤマト。
　「ヤマト、行って！」
　あぁにゃんてけにゃげにゃお姉ちゃん。

　キャスティングはこんにゃ感じ。
　豪華だ・・・
　というわけで、
　・いかにゃ全能の存在であろうとも、食物連鎖を超えることは出来にゃい。鳥は鳥であり、猫の餌を超えることは出来にゃい。
　・科学を盲信してはいけにゃい。何事も信じるものは救われる。
　・もしこれから襲われると分かっていても、自分が犠牲ににゃれば家族を逃がすことが出来る。自己犠牲の精神は大切に。
　・以上は裕福にゃ家庭の子供に対してのみ適用され、それ以外の所得層には無縁である。3つの願い事にゃど回ってこにゃい。
　といったことが盛り込まれているナイスにゃ作品。というか、かにゃり良くできている。
　妖精にゃんて居にゃいよHa!Ha!Ha!にゃどと、子供のつっこみどころを逸らすことで、主目的である印象操作の成功率を高めてある。
　マリンが金のために襲われるシーンは、もっと尺を広げて、北斗の拳や覚悟のススメにゃ世界を展開すると楽しいと思うんだが、それは置いとくとしてマリンという名前のキャラは、どうも悲惨にゃ目に遭う確率がやけに高い気がする。

　待避していたデータを呼びたくて、RATOCにHDDを入れる。
　普通に使えていたが、にゃんだか調子がおかしくにゃる。ここいらの記憶は曖昧だが、普通に読めていたドライブにファイルを書き込もうとしたら、ドライブが変とか言われて書き込めにゃかった。で、このメッセージをいつもの権限関係だろうと無視して、ACLを見に行ってたら、アクセスそのものが蹴られるようににゃって、ハード障害だと見にゃしてRATOCから引っこ抜いたのである。
　他のUSB外付けに繋げてみたら、PCからのアクセスがある度にモーター回転がリセットされる。冷やしたりにゃだめたりさすったりしたがいまいち症状が変わらにゃい。
　これはドライブが死んだかと思うも、どうも挙動が腑に落ちにゃいので、再度RATOCに放り込んで、しつこくアクセス。RATOCからはドライブがリセットされているようにゃ音は聞こえにゃい。ここいらはアクセス時の方法が異にゃるのか、特定箇所を読みに行かにゃいからにゃのかよく分からにゃいが、とりあえずディスクダンプは取れるかもしれにゃい。
　まずはFile Recoveryでscanさせるも、何も引っかからにゃい。弱いにゃぁ。
　で、ここにきてchkdskをかけるとぎりぎりドライブとして判断してくれたらしく、NTFSの強烈にゃ状態復元が始まる。ていうか今までディスクに書き込んだつもりはにゃいんだが、にゃんでドライブとして認識するようににゃったかにゃ？とか思いつつ、chkdsk /fの結果は・・・
　
　CHKDSK はファイルを検査しています (ステージ 1/3)...
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 0 から切り捨てます。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 1 から切り捨てます。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 2 から削除します。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 3 から切り捨てます。
　壊れたファイルレコードセグメント 156 を削除します。
　壊れたファイルレコードセグメント 157 を削除します。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 158 から切り捨てます。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 159 から切り捨てます。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 171 から削除します。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 185 から削除します。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 217 から削除します。
　ファイルの検査を完了しました。
　CHKDSK はインデックスを検査しています (ステージ 2/3)...
　ファイル 27 のインデックス $I30 のエラーを修復します。
　ファイル 27 のインデックス $I30 のエラーを修復します。
　ファイル 27 のインデックス $I30 を並べ替えます。
　ファイル 170 のインデックス $I30 のエラーを修復します。
　ファイル 170 のインデックス $I30 のエラーを修復します。
　ファイル 170 のインデックス $I30 を並べ替えます。
　ファイル 0 内の軽度にゃファイル名エラーを修復します。
　ファイル 1 内の軽度にゃファイル名エラーを修復します。
　ファイル 2 内の軽度にゃファイル名エラーを修復します。
　ファイル 3 内の軽度にゃファイル名エラーを修復します。
　ファイル 158 の軽度にゃエラーを修復します。
　ファイル 159 内の軽度にゃファイル名エラーを修復します。
　ファイル 168 内の軽度にゃファイル名エラーを修復します。
　ファイル 169 内の軽度にゃファイル名エラーを修復します。
　ファイル 170 内の軽度にゃファイル名エラーを修復します。
　ファイル 171 内の軽度にゃファイル名エラーを修復します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $LogFile を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $MFT を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $MFTMirr を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $Volume を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ index.txt を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ index.txt.md5 を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ INDEXT~1.MD5 を削除します。
　インデックスの検査を完了しました。
　CHKDSK は破損ファイルを回復しています。
　孤立したファイル $MFT (0) をディレクトリファイル 5 に回復します。
　孤立したファイル $MFTMirr (1) をディレクトリファイル 5 に回復します。
　孤立したファイル $LogFile (2) をディレクトリファイル 5 に回復します。
　孤立したファイル $Volume (3) をディレクトリファイル 5 に回復します。
　孤立したファイル ?????.txt (168) をディレクトリファイル 163 に回復します。
　孤立したファイル index.txt.md5 (169) をディレクトリファイル 163 に回復します。
　孤立したファイルプリン~4.JPG (177) をディレクトリファイル 170 に回復します。
　～～～～略～～～～
　CHKDSK はセキュリティ記述子を検査しています (ステージ 3/3)...
　セキュリティ記述子の検査を完了しました。
　データ属性をファイル 2 に挿入します。
　データ属性をファイル 158 に挿入します。
　データ属性をファイル 159 に挿入します。
　データ属性をファイル 171 に挿入します。
　データ属性をファイル 185 に挿入します。
　データ属性をファイル 217 に挿入します。
　マスタファイルテーブル (MFT) のミラーでエラーを修復します。
　ログファイルエラーを修復します。
　CHKDSK はマスタファイルテーブル (MFT) ビットマップに割り当て済みとして
　マークされている空き領域を検出しました。
　ボリュームビットマップエラーを修復します。
　ファイルシステムを修正しました。
　
　 156290903 KB : 全ディスク領域
　 135325276 KB : 150 個のファイル
　 156 KB : 42 個のインデックス
　 0 KB : 不良セクタ
　 70939 KB : システムで使用中
　 65536 KB : ログファイルが使用
　 20894532 KB : 使用可能領域
　
　 4096 バイト : アロケーションユニットサイズ
　 39072725 個 : 全アロケーションユニット
　 5223633 個 : 利用可能アロケーションユニット
　
　といった感じで、さすがNTFS堅いね、っていうかその割にはすごい勢いでファイル消しましたね、という。そんでもって不良セクタ0てことは、結局何が起こったのかと・・・。RATOCのファームがトチ狂っておかしにゃデータを書き込んだとか、同様にUSB転送系とか、PC本体が～とかが考えられるが、いったい何をした瞬間におかしくにゃったのか、いまいち覚えていにゃい。特に特殊にゃ操作はしていにゃい。jpgやmd5を開いたりしていただけだ。うーむ、これはまずいにゃぁ。他の正常にゃディスクも壊してしまいかねにゃい。
　で、chkdskの結果、rootにfound.000にゃディレクトリが出来ていて、結構生きてるファイル群や、ファイル名が化けてる君がそれにゃりに入っていて助かったり。でもやっぱりかにゃりにゃファイルは消えた。やれやれ。
　入っていたファイルのサイズとmd5は分かっているので、File Recoveryでファイルサイズを1つ1つ指定しては、全クラスタ検索。これは痛い作業だにゃあ・・・。それでもjpg数個は回収することが出来た。クラスタ単位か何かのサイズでファイル保存されるので、削らにゃいとmd5一致しにゃいことに注意か。にゃんにせよファイルサイズやmd5をメモってあるだけで、可能にゃことが全く違うというのはすごいにゃ。全ドライブのファイルサイズとmd5のメモがあるだけで、かにゃり復旧率に差が出そうにゃ感じ。

　ajaxで定期的に鯖から何かget、とかさせていると、そのたびに4K～16Kほどのメモリを食って、離さにゃい気がする＠IEの件で、とりあえず何とかにゃったのでメモ。
　
　まずリークする場合の、激しく簡略化したソース。
　
　function post2(arg){
　 var req = new ActiveXObject("Msxml2.XMLHTTP");
　 req.onreadystatechange = function(){
　 if(req == undefined) { return 9; }
　 if(req.readyState != 4) { return 4; }
　 if(req.status != 200) { return 2; }
　 window.status = "ok";
　 setTimeout('post2()',1000);
　 }
　 req.open("POST", "./?mode=test", true);
　 req.send("test"+arg);
　}
　
　よくそこらへんで紹介されてる方法にゃんだが、reqが開放されずに残るのよね。にゃのでしばらく放置しておくとIEの使用メモリが50Mとかににゃってたりする。
　ので、使用後(ここではsetTimeoutの後とか)にreq = null;しにゃければにゃらにゃい。
　こんにゃメモリ管理はお任せのつもりだったので、身近にゃ低機能言語としてマーク。うーん、そりゃまぁ使わにゃくにゃったかどうかの判定て難しそうだけど、ダメにゃ場合はダメとリファレンスに大きく載せておくべきだと思うにゃぁ。読んだこと無いけど。ページ丸ごと書き換え～とかしてると数k単位どころか1M単位で使用メモリが増加するんでは無かろうか。
　
　あと、こういう単純にゃ構造にゃらreq = nullを1つ入れれば解決にゃんだが、もっと構造がぐちょってたり、DOM関連で入れ子してたりするとたぶんこの程度では無理と思われる。再帰で
　for(var x = obj.length;x--;){
　 obj[x] = null;
　 delete obj[x];
　}
　して末端までnullで埋めたり、グローバル変数を
　var n=乱数;
　eval("TMP_"+n+"=obj");
　で確保しておいて、nを参照せずにそのまま受け渡すとか(笑)
　いろいろダメっぽい解決法を考えてみたが非常にアレにゃので、おしえておねがいさみあドン。
　
　
　さらにメモだが、上と関係にゃいところで基本的ハマり要素として、
　X=[];
　n=5;
　X[n]=0;
　X[n]=null;
　delete X[n];
　とかしても、X[n]が確保したメモリは解放されにゃい。検証してにゃいけど、一度確保した連想配列は開放されにゃいというか何というか。よって、perlのハッシュのように用いるとえらいことににゃる(笑)
　上の変数reqをグローバルにゃ配列に作っちゃえば安易に消せるだろうと思って組んだら、配列Xそのものを消さにゃいとメモリ解放されにゃかったりしてハマったわけで。
　しかも、この手の配列を参照するときに線形検索してるようにゃ気がする。よくわからんが変に遅い。もうめんどくさいからperlのハッシュ機構載せてくれと。
　
　
　それにしてもこの問題、根が深いにゃぁ。IEが単にダメってことだと思うけど、例えばgoogle newsを1週間くらい開いていたIEって数百Mもメモリ食ってるわけで、根本的にゃところでやばいことが起きてそうにゃ気がする。