昔の最近の出来事(2001.08)

2001/08/31

出張。

出張。

出張。

出張。

出張。

夕方間近まで寝こけてました。ちょっこり出社。

ファイルシステムコーディング。うひぃ、とても2,3時間でコーディング できるものではありませんでしたよ(^^; コーディング中にもディスクと して必要な情報を取り出すディスクアクセスコマンドを追加したり色々。

そういえば、この前タクシーに乗ったら、カーナビが装備されていました。 このタクシー大丈夫か？とも思ったのですが、ある意味これは良いかもと 思い直しました。というのは、以前、電車が無くなって新宿から家まで 帰ったとき、最寄駅を言ってもどこだかあまりよく判らないと言います。 普段電車しか使わないので道ったってよく判りません。結局、随分遠回り して辿りついたことがありました。でもカーナビが付いているなら とりあえず判らない所は無くなるし、昔のタクシーみたいに、道が わからないことを察してわざと遠回りしてみたりという事も無いんで ないかなと思いました。

息抜きでCG描き(ぉぃ; .....................赤○白×でハング(汗; 操作不能になったため、強制電源切断。20分間scandisk。あぅ。
彩 0.7.0.2で、「マスク自動選択モード」で「全表示レイヤーから選択」 をチェックた状態で、キャンバス上でスポイト実行するとハングします。 「全表示レイヤーから選択」をチェックしなければ普通にスポイト 実行できます。また、一度「全表示レイヤーから選択」をチェック してしまうと、チェックを外しても同じくハング状態に陥りました。 複数レイヤーが存在し、編集している状態でのみチェックしたので、 レイヤーが一枚しかない場合や、全体が透明だと再現しない可能性が あります(必ず操作不能になり、再起動に時間がかかるので再現テスト未)。 システムハングを引き起こしているので致命傷です。確認して みてください。

ちょっと期待されているらしい。びくびく。

そんな感じで明日から再び出張ですm(_'_)m

出張。帰着。

ファイルシステムの構成を変更。データブロックの先頭にリンク接続 するためのヘッダを設けてつなぐ方法で考えていたのですが、BSD ファイルシステムのような直接参照/間接参照を混ぜたデータリンク 方式にしてみることにしました。前者の方法だと大きなファイルも 小さなファイルも同じ方法でアクセスできるメリットがあるのですが、 ランダムアクセスを行うためには一度全てのブロックをなめて接続 情報を拾わなくてはならないので、大きなファイルの場合はシークが 死ぬほど遅くなることが考えられます。直接/間接参照を用いるBSD 方式のファイルシステムだと、小さなファイルは直接参照でブロック 位置を高速にシークでき、大きなファイルでも、そこそこの速度で 参照するデータブロックのサーチができます(アルゴリズムの改善で 高速化することも可能でしょう)。実際の所はよく判りませんが、 UNIXの場合だとよく使う小さなコマンド(lsとか)でも実行ファイル を実行するので、小さなファイルは直接参照でアクセスして高速化 することは有効だと思われます。また、ディスクキャッシュを 考えた場合、小さなファイルを優先的にキャッシュに乗せる様に 考えると、キャッシュ効率が上がるようにも思います。
MS-DOSやHumanの様なFAT式のファイルシステムについては(も?)よく知らない のですが、FATのサイズと、指すポインタサイズと、全ディスク容量 から一つのブロックの最小サイズを決めないと、ポインタがとどかな いという事が起きると思います。ディスク容量が大きくなると ブロックサイズが大きくなるため、小さなファイルばかり作ると 実際にはスカスカにしか使っていないという事になると思われます。 実質、それでもあまり問題は無いとは思うのですけどね(^^;

コーディングには着手できず。

出張。

出張。

出張。

出張。

日付け越え。

帰りついたら即死。直ぐに寝てしまいましたよ(^^;
明日から出張なのですが、台風は大丈夫か？

13時間以上寝てしまいましたよ。おかげで起きた後も動く気力なっしん状態。

ちょっこり出社。順調。

ファイルシステムのインプリメントをちょこっと考えてみました。でも、 あまりに簡単に考え過ぎて、明らかに遅そうって感じ(^^;。 まぁ、ファイルシステムの次は、メモリ管理とか色々あるので、適当にちゃっちゃと 終わらすって感じでいきたい気分。 インプリメントを考えていて、更新日とか入れるフィールドを設けたのは良いのです が、時間を得るためのpseudo-deviceが付いていないことに気づいたので付けてみました。

なにげにTINAMI経由で だらだらとCGサイトを眺めていたのですが、profileとかに 「生年月日 1984年」とかさらっと書いてあったりすると、ひょえーっ とか思ってしまう今日この頃。面白いのは、年をそれなりに重ねていると、 「若くないです」とか「20代後半」とか割と曖昧に書かれている所。そういうのは 大体27〜32の間かな？みたいな匂いを感じてしまう自分もアレなのですが。 24才くらいまではちゃんと24と書くような感じのようです。後は、実際に描く絵柄とか でも判るし、好きな作家も大体 年相応という感じのようです。1980年代生まれで 「大友克洋が好きです」なんてなシヴい人はあんまり居ない感じがします(^^; そういや、世の中には84同盟 なんてringがあるようです。よく判りませんが、この世代って何かあるのかしら？

何気にTVを見ていたら任天堂GAME CUBEのソフトのCMが流れてました。一瞬しか 見れませんでしたが、やっぱ絵が綺麗ですなぁ。

ちょっこり出社。珍しく事無きを得たので少し早めに離脱。

本屋に行ったり、ゲーセン行ったり。人が多いと思いきや、今日は花火大会の様子。
やっとこさ「攻殻機動隊2」が入荷してました。そこら中の本屋にいっせいに大量入荷 されていたのが謎。後で気づいたのですが、マウスパッドが同梱されていたので、 なかなか出なかったのはもしかしてそれのせい？そんな感じ。
何気にゲーセンに入ってみると、「プロギアの嵐」の上手い人がプレイしていたので 後ろから眺めていました。一面からジュエリングの嵐ですよ！ちゅうか、こんな所 で取れるなんてっ！ 上手い人はスコアアタック目的だったようですが、二面で死んで 捨てゲー。それを三回繰り返して離脱。うーん、残念。で、自分でもやってみたり して(^^;........う、こ、これは......今さらながらはまってきたかも(笑;

ppcsimでのpseudo-driveを使用したファイルシステムの実装を考えてみたり。 ファイルシステム自体も奥が深いようで、フラグメンテーションと性能、ファイル システムが破壊したときの復旧方法、ファイル破壊の無いファイルシステムの考案 など、考え所は色々あるようです。今までなにげにfsckやscandiskでファイルが 復活して、漠然と「便利やなぁ〜」と思っていましたが、そのメカニズムを実際に 考えてみると、結構複雑そうな予感。 性能やファイルシステムの頑丈さなんてのは、システムが安定してアプリケーション にバグがなければ、ファイルが壊れる事もないし、cacheをメモリに持てばいくら でも性能が上げられそうな気がするので、考えなくてもよさそうな感じなのですが、 実際はそういう訳にはいかないようです。単純に安定したシステムなんてのは (ハードもソフトも含めて)世の中に存在しないから という理由のような気が しなくもありませんが(^^;。
例えばUSBの様にホットプラグが許可されたようなデバイスでも、ファイル システムが破壊してはいけないとか言われると、結構面倒な感じがします。 いつプラグを抜かれるか判らないという条件が入りますから、うかつに キャッシュに上げることは不可になります。リトライすればOKかというと、 もう一度挿し直した時、さっきと同じディスクが挿されなければ、書きこんでは ならない。じゃあそこで捨てて良いかというと、勝手に捨てられると怒る人 も居るなど、自由度が上がると例外操作の組合わせが増えるという法則に モロに乗っかっているような気分です。
そんな感じで、なんかむずかしくってゲンナリ。簡単なので済ましてしまいそうな 予感。

起きてられなくて、めずらしく日付が変わる前に寝てしまいました。

急遽強制呼び戻し。そして日付け越え。帰着。

ファイルシステム関連の資料を眺めたり、だらだらとダウンロードして みたり。

出張。

出張。

出張。

出張。

昼まで寝て起きて、洗濯しながら「平成日本のよふけ」などをだらだら 観てみたり。あぁ、この番組の本が出てるのね。出張期間中の暇つぶしに 買ってくることにしよう。

ppcsimのディスクデバイスのプログラム書き。疲れたのでお出かけ。 今日は妙に涼しいです。

本屋行ったりゲーセン行ったり。鉄拳4とバーチャ4が稼動してました。 バーチャの方は雑誌などで見ているとライトがうるさくって絵的に いまいちな感じがしなくもなかったのですが、鉄拳と並べてみてみると、 結構ハデに見えるので、バーチャの方が良い感じに見えました。鉄拳 の方もバックでギャラリーが見ているというステージがあるのですが、 10人以上はいるかと思われるただの背景の人までポリゴンになっているのは 驚きでした。アーケードでは久々のビッグタイトル２本なので、プレイ する人でいっぱいでしたよ。

で、本屋。「よふけ」を探していると、「タミヤRC 四半世紀の記録」 という本が目に入り手に取ってみました。ヲレ的直球。即買い(^^;;;
一番最初のタミヤRCであるところのシャーマン戦車から今年発売の最新 RCまで、カタログ風にもれなくビッシリ詰まった濃縮の一冊です。 コロコロコミックでの連載であったところの「ラジコンボーイ」から RCカーブームに火がつき、そのブームにもろに乗っていたTANE少年(藁; だった訳ですが、その頃のRCカーやその周辺パーツと、近年のRCカーの それとを比べると、随分と進化しているところに驚かされます。 まず、電動RCカーの動力燃料であるところのニッカドバッテリー。 ご存知の方も多いと思いますが、このころのバッテリー(7.2V 1200mA)は 家庭用充電器(ファミコンのアダプターみたいなの)で8時間充電して、 実際に走らせることのできる時間はわずか10分だったのです。恐ろしく 燃費が悪いのですが、これはどうしようもないことでした。ところが 最近は、ニッケル・水素バッテリーと呼ばれるもので、同じ電圧で容量 が2.5倍(7.2V 3000mA)になっている(しかもサイズは昔のより軽くなって いるくらいの勢い)らしく、単純計算で25分走らせることができるような 時代になっているようです。しかも、家庭用充電器でも数時間で充電 できるようになっているようで、とてもうらやましい技術進化を遂げて いるようです。
後、動力であるところのモーター。マブチのRS-540モーターと呼ばれる ものが標準でしたが(この本によれば、2度のモデルチェンジ後、RS-540SH という現行型があるようです)、さまざまなチューニングが施されたモーター が発売されていました。最近でも新しいチューニングモーターが発売 されているようです。モーターも高回転/高燃費型と中速/低燃費 という用途に応じて交換することが可能なのですが、高回転モーターで、 「進角」と呼ばれる更に回転数を上げる為の必殺パラメータをいじって 無茶苦茶速いモーターに仕上げることができたのですが、ものの 5分でバッテリー切れになってしまいました。チューニングは面白いけど 長く遊べない(時には回転数を見るためだけに、全く走らせることなく バッテリーを使い切った事も幾度かありました(^^;)というパラドックス にはまったものでした。
最後はスピードコントローラ。私が知っている頃のRCは全て抵抗を 使って流れる電流を調節する機械的なスイッチだったのですが、 最近はFETを使った無段階スピードコントローラ(通称FETアンプ)が デフォルトの車体(FETアンプ搭載専用に設計されている)があるようです。 私の知っている頃もFETアンプというのは存在していましたが、非常に 高価であったため、とても手の出る代物ではありませんでした。

かなり話が逸れますが、ここまで書いておいてなんですが、ワイルド ウイリスからグラスホッパーという二台のタミヤ製を経て、これからは四駆 の時代という頃は、もう一つのRCメーカーであるところの京商製の RCカー(オプティマ これベースで何種類か出た オレ的名車)に乗り 換えました。ここで感じたのが設計思想の違いでした。 四駆車で前後に動力を伝える方法として、京商はチェーン、タミヤは シャフトを使っていました。京商の最初の四駆車(プログレス(らしい) 先進の4WDS 車だったのですが、色々な点でかなりヘボいデキでした)から チェーンが採用されていて、タミヤの最初四駆(ホットショット こち亀に 出て来たりミニ四駆になったり結構有名かも)は、それに比べて後発だった のですが、そのときのタミヤの言い分は耐久性の点でシャフトの方が優れている というものだったと思います。また、ギアボックスは、タミヤのは比較的 密閉しているのに対して、京商のはやけにホコリが入り易かったように 思います。シャフトだと、ギアボックスから出る穴を小さくできる ので、自然と密閉率も上がるように思います。チェーンやベルトだと どうしても行きと帰り分の穴が必要であること、外れにくくするために ガイドレールが必要なため、シャーシ上で占める動力伝達部品の割合 が増えることなど、不利な点が多いと思います。それでも、京商の オプティマがオレ的名車たるゆえんは、サスペンションが抜群に良かった (四輪独立サスペンション タミヤのホットショットは前輪がモノサス ペンション)のと、軸受けを全てベアリングに変えた時(フルベアリング化 の事で「フルベア」などと言ってました)の値段の安さ(確かホット ショットは全部で8800円くらいしたけど、オプティマは5000円くらい だったかと)という点からだという感じです。
話を本の方に戻しますが、この本で初めてみたアバンテ4WDは、シャフト駆動 であるのはタミヤ風味なのですが、構造的にはオプティマに似た点が あるように思います。 本当の所は判りませんが、私視点で見た限りでは、このアバンテ4WDって のは相当良い感じのような予感がします(34800円は お値段的には ちょっと手が出にくい感じですが(^^;)。
そんな感じで堪能できる一冊でした。 以前紹介した「田宮模型の仕事」 と合わせてみると、より深くRCの歴史を楽しめるように思います。

などと昔話を書いててppcsimの方が進みませんよ(ぉい。とりあえず DISKデバイスとしての実装は完了したものの、テストプログラムを書く 時間無し(汗;。このデバイスを使って、sc命令のエミュレーション 相当の動作を行うには、sc命令割り込みをきちんとハンドリングする 必要があります。すなわち、ネイティブで動作する本当のOS(もしくは それ相当品の動作を行うライブラリ)を書く必要がありますよ。 でも、それができればファイルアクセス系についてはsc命令エミュ レーションが不要になるため、異なるプラットフォームへのポーティングが より簡単に行えるハズなのですが......。どうしてくれよう。

なにげに買ったDesignWaveMagazine。斜め配線を使用して、どうやって セルに電源供給するのかしら？ まぁ、できることはできるか。

そんな感じで明日から再び出張ですm(_'_)m。

って書いた後に、実装したppcsimのディスクテストプログラムを書いて みたりして(^^;; 大ボケを一件かましてましたが一応、意図通り動いている予感。 ディスクの容量の設定や接続、予め用意したディスクイメージの ロードはppcsim上のコマンドで行います。以下テストプログラムの 実行時ログ。

test_disk.ppc Exec Start 
mount 0 0x100
mount 1 0x100
mount
  0  type=0x00000003  track=0x00000100(       65536 byte)
  1  type=0x00000003  track=0x00000100(       65536 byte)
dload src.img 0

exec test_disk
called exit.

dsave dst.img 1

exit
done.

#define DISK_CMD             0x8000ff10
#define DISK_ACK             0x8000ff14
#define DISK_DRIVE           0x8000ff18
#define DISK_TRACK           0x8000ff1c
#define DISK_DATA_TOP        0x8000ff20
#define DISK_DATA_LEN        0x8000ff24

#define DISK_TRACK_LEN       256

#define DISK_NOP             0x00
#define DISK_INQ             0x01
#define DISK_READ            0x02
#define DISK_WRITE           0x03

int main()
{
  int i,j ;
  static unsigned char buf[DISK_TRACK_LEN] ;
  volatile int *dcmd=(int*)(DISK_CMD) ;
  volatile int *ddrv=(int*)(DISK_DRIVE) ;
  volatile int *dtrk=(int*)(DISK_TRACK) ;
  volatile int *dtop=(int*)(DISK_DATA_TOP) ;
  volatile int *dlen=(int*)(DISK_DATA_LEN) ;

  for( i=0 ; i<256 ; i++ ){
    *ddrv=0 ;              /* ドライブを選択                   */
    *dtrk=i ;              /* 読みこみ先頭トラックを指定       */
    *dtop=&buf[0] ;        /* 読みこむメモリ物理アドレスを指定 */
    *dlen=DISK_TRACK_LEN ; /* 読みこむデータ長を指定           */
    *dcmd=DISK_READ ;      /* 読みこみの実行                   */
    
    *ddrv=1 ;              /* ドライブを選択                   */
    *dtrk=i ;              /* 書きこみ先頭トラックを指定       */
    *dtop=&buf[0] ;        /* 書きこみメモリ物理アドレスを指定 */
    *dlen=DISK_TRACK_LEN ; /* 書きこみデータ長を指定           */
    *dcmd=DISK_WRITE ;     /* 書きこみの実行                   */
  }
  exit(0) ;
}

出張。夜帰着。

ぐるぐるしたり色々。最近の eCosはPS2やDCもターゲット システムに入っている(正確には近々正式に入る予定？)のですね。 で、なにげにCVSダウンロードを開始してみたり(^^; 以前、ダウンロードしよう としたときはやたらサイズが大きかったのでやめたような気がするのですが、 gzip -9 でアーカイブにくるむと9.5MB程度だったので、小さくはないですが、 我慢できるサイズです(.....やっぱできないか(ぉい)。ターゲットシステムを 作る前にconfigrationツールをmakeして、それにコマンドとテンプレートを 渡すことで、ターゲットCPU、使用するIOデバイスなどに応じたシステムが 構築できるというしかけのようです。 ただ、クロスコンパイラなどをまともにインストールしておかないと、えらく 構築に苦労するしくみのようです。で、放置(ぉ

ppcsimにディスクデバイスを実装する案を考えたり。

出張。

出張。

出張。

出張。

いきなり出張が明日に延期(^^;

先日のGNU GLOBALをちょっと追っかけ。エラーしているhtagsコマンドを見て みると、perlスクリプトだったのでちょっこりデバッグしてみました。 まず先日のエラーの理由ですが、htags内でgtagsコマンドを実行しているの ですが、カレントパスのgtagsコマンドを実行しようとしています。これだけ だと本来はcommand not found になるハズなのですが、カレントディレクトリ にGTAGSという大文字ファイル名のデータベースファイルが存在しているため、 これを実行しようとしたbashが、シェルスクリプト起動でGTAGSを実行した結果、 バイナリの一行目が解釈できず1行目がsyntax errorとなったようです。
こうなった原因は習慣とファイルシステムの違いによる二重衝突から生じた ようです。まず、私のシェル環境で、コマンドパスにカレントディレクトリ'.'を 含んでいるため、パス無し実行でカレントディレクトリのgtagsを実行しよう としたのが一つ、もうひとつは大文字小文字を区別しないファイルシステムで あるため、gtagsとGTAGSの区別をおこなうことができなかったということの二点。 清く正しいUNIXシェル環境ではカレントディレクトリをパスに含まないという 風習があります。もうひとつの大文字小文字は、いかんともしがたいところ。 で、htags内で実行されるgtagsをフルパスで実行するように変更すると、 syntax errorは解決しました。ところがもうひとつ、 「cannot make cache database.」なるエラーメッセージが出て止まって しまいました。dbmopen()自体は特に変な感じはしないので、dbmopen()の エラーチェックを外して強引にオープンさせたところ、うまくいったもよう。 常にエラーを返しているのかしら？
で、MegaPOVソースを変換してみたのですが、なかなか良いですよ(^^)。 できあがったHTMLソースが巨大というのが難点で、サンプルとして上げられ ないのが残念ですが、各ソースファイルに対応するページには使用されている 関数の一覧が出てるし、もちろんソース中で使用されている関数部分も タグジャンプできるしで、デバッガで追っかけているような感覚です。 Linuxのソースもこれで変換かけておくと追っかけるのが楽になるかしら？

そんな感じで明日から本当に出張です。

ちょっこり出社。どうやら片付いた模様。

なにげにぐるぐるしていたら GNU GLOBALなるものに 興味が沸いてきました。 以前Verilogのソースをhtml形式に 変換するコンバータの存在を知ったのですが、それのC言語版って感じです。 でも、makeまで(恐らく)問題なくできたのですが、肝心のhtmlへの変換がうまく ゆかず。

source_org> gtags
source_org> htags
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
./gtags: 1: Syntax error: "(" unexpected
htags: cannot traverse directory.

ちょっこり出社。何事もなかったもよう。

MegaPOV on ppcsimでMegaPOVなデモシーンファイルをレンダリングして みました。

exec megapov -i megapovdemo/photons/threelens.pov +W320 +H240 +A -o threelens.png
Persistence of Vision(tm) Ray Tracer Version 3.1g.mp.0.7.mcp.0.1 (MegaPov MCP 0.7.0.1 )ppc-cross
   :
   :
----------------------------------------------------------------------------
Time For Parse:    0 hours  0 minutes   8.0 seconds (8 seconds)
Time For Photon:   2 hours 44 minutes   9.0 seconds (9849 seconds)
Time For Trace:    5 hours 59 minutes  35.0 seconds (21575 seconds)
    Total Time:    8 hours 43 minutes  52.0 seconds (31432 seconds)
Total cache size: 16720
called exit.
Number of executed instructions=0x80000000*28 + 1027624861

ひと段落。22時過ぎに帰りついてみたり。

彩の新版がリリースされてました。スクラッチパッドが少し大きくなったり、 スクラッチパッドが自動セーブされてたり、その他、細かい点が改善されて いるようです。



つーか、折角マスクが直ったのに、マスクを使ってないし(大汗;; 浴衣の構造がよくわからなかったり色々。浴衣と着付けでサーチ してみたりなど。それでも変ですが(^^;;。そんな感じ。

そういや最近やけに携帯電話へくるメールが多い。俗にいう迷惑メール という奴です。でも、私は携帯メールでのやり取りが全く無い ので、むしろ「毎回誰が考えてるんだ？」と思うような えろーす系 ビデオの宣伝やらサイトの紹介やらのバカっぽい売り文句をつぶさに 観察しています。毎回同じメッセージだとかなり迷惑なのですけどね (＜なんじゃそりゃ)。でも一体どこでアシが付いたんだろう？

起きられやしない。昼前に出社。日付け越え。

あまりのしょーもなさに愕然としてしまいました。megapovを実行 しているつもりが、同じディレクトリに置いてあったノーマルpovrayを 実行してましたよ(滝汗; どうりでどんなに変更を加えても結果が 変わらない訳だわ(-.-;;;;

date
Fri Aug  3 02:10:39  2001
exec megapov -i povray31/scenes/incdemo/colors.pov +W180 +H120 +A -o colors_megapov.png
Persistence of Vision(tm) Ray Tracer Version 3.1g.mp.0.7.mcp.0.1 (MegaPov MCP 0.7.0.1 )ppc-cross
  :
  :
----------------------------------------------------------------------------
Time For Parse:    0 hours  0 minutes   3.0 seconds (3 seconds)
Time For Trace:    0 hours  7 minutes  36.0 seconds (456 seconds)
    Total Time:    0 hours  7 minutes  39.0 seconds (459 seconds)
Total cache size: 14800
called exit.
date
Fri Aug  3 02:18:18  2001

日付け越え。つーか、空が少し明るいのですが(T_T)

今気づいた驚愕の事実。クロスコンパイルしたPOV-Rayは、時間に 関する出力が全然行われていませんよ。でも、Cygwinネイティブで コンパイルした時はちゃんと時間表示されているのに。コンパイラ のdefineが何か違うのかしら？

.......ソースを追っかけてみると、表示されるべき各種トータル時間 が0の時は表示自体をスキップするような仕掛けになっているようです。 なぜ0になるかを追っかけてみたところ、time()が変臭い。う〜ん？ 何かつじつまが合っていない予感。

つーか、もう寝ろっ！(＞をれ)