2000年7月の日記。

counter

一覧。

2000年07月31日

32MB増設メモリ付きだったのだろうかっていうのは型番を見ると解ります。末尾にAがついていれば増設メモリ付き。あ、もう手遅れですか。

スタンバイやハイバネーションから復帰するときに、LCDに不安な感じの模様が出てくるのは何とかならないのだろうか。って実は、FIVAだとVRAMとメインメモリが独立していないので初期化中のメインメモリの内容がそのままLCDに表示されてしまうのです。多分。他のPCならこんな現象は発生しません。

COOLPIX 800の2倍ズーム、これだと足りない。もっと、もっとだっ!!!!とか思ってしまう。COOLPIX 990に乗り換えるか。こっちだと3倍ズームだしレンズも明るくなる。COOLPIX 800だとF3.5なのが2.8まで明るくなるので、ズーム時でもつぶれにくいのではないかとか。テレコンバータの購入も考えてしまう。テレコンワールドとは関係無いのでよろしく。今出回っているのは2倍だけど、3倍のが出るらしい。というか出ているハズだったのが延期中。これ、800にも付くのか? 使えれば6倍ズーム。レンズ、暗くならないだろうか。

っていうか、F値の見方ってよく知らないのですが1違うとどうなるのですか? なんとなく高度に自動化されているもので設定の仕方がよく解らない。とにかく感度をISO100程度でシャッタースピードを0.5秒にしたい、とかいう時があるのですがCOOLPIX 800ではどうやったら設定できるのでしょうか。感度を下げると自動的にシャッター速度も遅くなるし。

2000年07月30日

ハトをめがけてケリ。

ケリ

この季節は天国である(謎)。

残念ながら再入荷。

MASAO

ソレって再入荷じゃなくて倉庫から再出庫したんじゃないのか?

で、ドトールでコメント作成。1時間30分使ったところでバッテリー残量30%。やっぱりFIVAだとバッテリー持たない。

10%程度残しておかないとハイバネーションできなかったりするのでさらに厳しい。

帰りに時計台を撮影してみる。COOLPIX 100と違い、COOLPIX 800ならシャッターをある程度開放できるので夜景でも何とかなるだろうと。

時計台

んげ、ブレる。やはり三脚が必要か?

Rozorをおいて、姿勢を安定させて、深呼吸してからもう一度。

時計台

まあ、こんなものか。

気が向いたので地下鉄に乗らずにゲーセンをはしごしながら帰宅。

札幌駅前のPaloでDDR。挫折していたMANIAC PARANOiA 190 をぷるうぇい。クリア。あれ? 踏めたよ。もう一度踏む。クリア。おおー、踏み切れるようになったらしい。

天国ぶり(謎)をICQで某氏に報告したところかなりの入れ食い(謎)であった。うーむ極楽極楽(危)。

2000年07月29日

髪切った。っていうか、切ってもらった。切られすぎ。がっくし。

2000年07月28日

朝に見かけたもの。

四駆

なんか無駄にたくましい感じが。

ShellExecute()の挙動がIE3とIE4以降で異なるのだが、どうしたら使い分けられるのだろう。

2000年07月27日

勤務先でFIVAを見かけたような気がする。あの銀色で凹凸のある底面、スピーカの位置、FIVAとしか思えなかったが…。

ふーん、HSPかあ(なにがだ)。

実行ファイルが400KB程度って結構小さくまとまるものね。中にwavファイルとか取り込んでいる割には。

っていうか、このwavファイル、抜き出せないかなあ。

ドットコム娘(笑)ってネーミングもすごいが、趣味もすごすぎ。アクセス解析とかベジェのトレースって一体…。

2000年07月26日

コンパックのPCに「インターネットボタン」というのがつくらしい。ぽちっと押すと業務提携したエキサイトのサイトにアクセスできる。

そんなボタンがつくと邪魔だろうから今後コンパックのマシンは買い替える際の考慮からはずれると思う。動作をカスタマイズできれば便利なんだろうけど、何しろお互いに業務提携を結んで搭載するのだから、カスタマイズできてしまうと契約破棄というか、けっこうやばい? だとするとやっぱりカスタマイズはできないだろうな。

個人的にはそんなボタンをつける余裕があるのだから、当然PageUp PageDown Home Endキーは省略されていないのだろう。。

Appleはクリアボディの17インチCRTを発売するとか。ノイズは大丈夫か?

Delphi Some Tips(まぐまぐID:0000034611)のVol.061。画面解像度の取得と称して

var
  ibKaizodo, ibPLANES, ibBITSPIXEL : Byte;
  DC : HDC;
begin
  DC := GetDC(0);
  ibPLANES := GetDeviceCaps(DC, PLANES);
  ibBITSPIXEL := GetDeviceCaps(DC, BITSPIXEL);
  Releasedc(0,DC);

  ibKaizodo := ibPLANES * ibBITSPIXEL;
  ShowMessage(IntToStr(ibKaizodo) + ' bit = ' +
              FloatToStr(Exp(ibKaizodo * Ln(2))) + ' 色');
end;

それって解像度とは言わない。

2000年07月25日

朝から雨。

ミスドによってハムタマゴを食べる。

DDR、うっかりNONSTOPでぷれいしてしまう。DOUBLEの韓国メドレー、一曲目で轟沈。

2000年07月24日

とりあえず環境をFIVAに移して出勤。

天気予報では雨だそうだが、青空だしどうも雨が降るような気がしない。ので、傘は持っていかないことにする。

賭けの結果、勝ち。雨は降らなかった。

2000年07月23日

雨。んがー。外出する気分になれず。でも外出。

FIVA回収。バックライト交換になったらしい。90日間は修理保証ということでこの間はまた故障しても無料修理とか。しかし、バックライトなんて自費で交換したら破産するぞ。バックライトも消耗品ならバッテリーみたいに交換可能にして。薄くなくてもいいから。薄くなって喜んでるのってユーザーよりも広報部じゃないのかという気がしないでもない。

とりあえず、HDDの容量不足が致命的なのでLibretto SSからFIVAに乗り換える予定。解像度も液晶の発色数もUSBもFIVAの方がいいし。FIVAの欠点としては起動時間が1分かかること。VAIO PCG-SR/K9だっけ、起動に3分かかるとか言う話なので起動時間についてはどうでもよくなってきたとか言う話も。

先日踊るダメ人間(限定解除)にイカスものがあるから撮影してこいとメーられたので撮影に行く。

なんでもYES(電気屋)の向かいらしいのだが…。まあ、アヤシイモノといえば土産物ではないかと思ってのぞいてみる。

土産物屋

どうもそれっぽいのが見つからない。そのままだらだらと狸小路を歩いてみたもののソレっぽいのが見つからないのでデンパを飛ばしてみる。

やはりYESの前だというので来た道を戻りつつ…

発見っ!

やっと見つけたぜ、戦士の鎧っ!

角度的にYESから見た時には物陰に隠れてしまっていたらしい。

しかし、これは素晴らしい。何が素晴らしいって見つけた途端に目が合ってしまったことだ。

戦士の鎧(前)
これが発見された戦士の鎧だ。コレを身につければたちどころに戦士になれる。かもしれない。少なくとも英雄にはなれるような気がする。ある意味。
中央の顔はどうやら見たものを硬直させたり、口の中の液体を吹き出させたりする効力があるらしい。
戦士の鎧(前)の証し
これが紛れもなく戦士の鎧であることを示す証文だ。きちんと右側には着用例が記述されているところが親切。っていうか、前?
戦士の鎧(後)
そう、実は後ろも用意されているのだ。コレで背後の守りは万全だっ!
戦士の鎧(後)の証し
当然、こちらも証しが立てられている。着用例も完璧だ。

私がこの鎧を発見した直後(というか硬直中)、「おれ、鎧着るよっ!」と叫んでいた勇敢な若者がいたことを付け加えておく。

ススキノスガイでTOD。「き」のキーの反応がめちゃくちゃ悪い。叩かないと入力されない。それでも1面はノーミス(!)でクリア。2面もノーミスで進んだものの、ボス戦であえなく撃沈。人差し指で入力するキーだから間違える気がしないので割とスナック感覚で押してしまって反応してくれないのな。これが間違えそうなキーなら気合いも入るかもしれない。現に「へ」とか「ー」はかなり力強く叩いていたような気がする。あと「ゃ」「ゅ」「ょ」。このキーはLibrettoとかFIVAだと配置を替えてあるのでいざという時にハマる。シフト+「な」「に」「ら」に割り当てているのだ。で、本来の「ゃ」「ゅ」「ょ」は「'」「(」「)」にしてある。このあたりの文字って割と使うので。

こんなことしてると自分のマシン持ち込まないでワープロ検定とか受けると破滅するかもしれない。

ドトールでコーヒー飲む。なんか習慣になりつつある。

バッテリーの持続時間、これもFIVAの方が短い感じがする。あとキーボード。好みの問題かもしれないけど、Librettoの方がはるかに打ちやすい。

キーボードの手前のたった3cmの隙間がひざの上でタイプする時の安定性を格段によくしている。ここを軽く親指で押さえているだけでかなり本体が安定するわけ。FIVAだと押さえる場所が無いのでちょっち苦労する。

液晶解像度は慣れてしまえばなんとでもなっているのでHDDの容量と発色数さえなんとかなってればLibrettoを使い続けていた可能性大。

今思ったけど、可能性が高い、っというのに可能性高って書かないで可能性大って書くのな。なんか変。

モスバーガーでカレーナンドッグ食べる。うま。

雪印のアレでチーズバーガーとか販売中止になってるわりには生クリーム入りコーヒーフレッシュなんてついてくるのな。これは雪印じゃないわけ? だったらチーズも雪印以外のメーカーから仕入れればいいのに。っていうか、シーザーサラダにチーズが入っていたような。

とにかく、HDDの容量が厳しいとコンパイラも突っ込みにくいし、色がまともに再現されないと画像の処理が大変。無ければ無いでなんとかやりくりしてきたけど、こればっかりはもう戻れない。解像度はフォントを小さくするとか回避手段があるけど、コンパイラは代替手段が見つからない。色がまともに表示されないというのもハードウェア的な問題というかNeoMagicの問題なのでこれを取り替えるしか手がない。Chips&Techのチップを使っていたLibretto 60だともう少しまともにディザリングしてくれていたけど。もっとも液晶がフルカラーで表示してくれていればそもそもディザリングしなくてすむのでチップの問題というよりは液晶の問題かも。

しかし、常にメニューバーを表示するのって無駄だねー。一太郎のEscを押したら出てくるメニュー、あれはアレで便利だと思う。Escを押せば出てくるというのさえ知っていれば。Susieなんてスマートでいいよね。フックしてメニューバーを隠してしまうプログラムでも作ろうか。

Libretto SS、とりあえず40%までバッテリーが消耗。あと1.3時間動けると主張している。

んで、どれくらい稼働してたっけと思ってこんなプログラムを書いてみる。動けばいいので細かい効率は気にしない。というかこれで悩んでてもバッテリーが減るだけだし。

#define WIN32_LEAN_AND_MEAN
#include<windows.h>
#include<stdio.h>

int main(void){
    DWORD dwTime;
    DWORD hh, mm, ss;

    dwTime=GetTickCount();
    ss=dwTime/1000;
    mm=ss/60;
    ss%=1000;
    ss%=60;
    hh=mm/60;
    mm%=60;

    printf("running time %d:%02.2d:%02.2d\n", hh, mm, ss);
    return 0;
}

1時間36分動いていたようだ。これだけ使っててバッテリーが半分しか消耗していないというのは非常に助かる。FIVAだとそろそろ厳しい頃合いだと思う。

この電源管理の安心感がLibrettoのいいところ。というかFIVAの弱点。

会議室のコメント書き。運営がらみのネタだったりするので詳細は書けないけど、まあ、アレだ。

WebというかInternetがこれだけ普及するとフォーラムもキビシイと。じゃあどうするという話になるわけだけど、どうも視点が若干ズレている気がする。

最近の会員の嗜好に合わせるのもいいけど、個人的にはソレよりももっとやることがあるような気がする。最近の会員だと、フォーラムがつまらなければ別のところに行けばいいやというノリがあるので、あまりそっちに力を注いでも仕方が無いというか、もっとターゲットを絞らないとだめだと思う。むしろ既存の常連を盛り上げるというか。

会議室というか、フォーラムの財産っていうのはライブラリでも何でもなくて「人」なわけ。ライブラリなんて規模から考えればVectorに敵わないし。おもしろい発言をするような人を集めるとか、サポートするのがいいんじゃないだろうか。

なんにしろ発言が無いと読むものが無くなるし、読むものが無いと人が来ない。人を呼ぶには発言が無いとダメ。それもおもしろい発言がベスト。量だけあってもしかたがないけど、量がないと勢いがつかない。質と量とどちらも必要。

それだけの量を書けるか、というと全然自信が無い。

フォーラムのファンというのを作らないとダメじゃないだろうか。

帰り際にみた貼り紙。何度読んでも意味が理解できなかった。

何を言いたいのかわからない貼り紙

どうもスタンプをおすかたが中にあるらしいのだが…。

2000年07月22日

雨。んがー。外出する気分になれず。

FIVA修理完了。でもソレどころではないので回収できず。さて、このままLibretto SSを使うか、FIVAを使うか悩んでいる。

2000年07月21日

もしかしたら再帰呼び出しの人にメーれていなかったのかもしれないので、届いてますか? という感じでメーる。

Cマガ発見っ!

モスバーガーでナンドッグを食べる。シーザーサラダ。

雪印乳業のアレのせいでチーズバーガーなどが販売停止状態。むう。

2000年07月20日

Cマガ見つからず。

勤務先の会議に出席。終わったあと、小一時間ほど食事に行かないかとか言われたのでついて行ったら思いっきり飲み会。あんたと食事には二度と行かないと思った。

2000年07月19日

FNIHONGO、イキナリ「非論理」だとか言われてドキドキする。

レーザー光線は目に見えないはず。見えているのは空気中の何かに反射した結果として目の方向にも光が届いているだけで、本来レーザーのような指向性が強い光は目に見えないはず。レーザーポインタなんかの光線、ホワイトボードにあたっている部分は見えるけど、ソコに至る経路は見えないでしょ?

シューティングゲームをやっていての疑問。アレだけの弾薬はいったいドコから湧いて出てくる? やはり無尽蔵に撃てるようなヤツだと、弾薬系ではなくて光学兵器ではないだろうか。動力源の問題も出てくるけど、それはゲーム中はいつまでも飛行できる戦闘機が出てくるのだから動力源は無視。

というわけで、シューティングゲームに使う自機の兵装はレーザー、当然画面には表示しない。

作りかけのシューティングゲーム 300x200

…なんかつまらんぞ。

グラフィックは実行時にビットマップファイルから抜き出して使うので、これを書き換えれば適当なグラフィックに変更できる。にしても、なんかちゃちー。

さて、当たり判定だ。

要は、矩形同士を比較して重なっている部分があるかないか、ということになる。しかし、こんなことを500回も繰り返すのはばかばかしい。

FNIHONGO、イキナリコメント禁止処置に入っていた。がっくし。

2000年07月18日

再帰呼び出しの人からのメールは届かず。

ヨドバシカメラのマルチメディア館とかいうのにいってみる。って別館だと思っていたけど、今までの札幌店は無くなってますか。マルチメディア館というから、ソレ系のだけ別の建物に移したのだと思った。

デジカメのサンプル画像をかなり拡大してプリントアウトしてあったのでちょっち比較してみる。

CyberShot DSC-F505V、ちょっちだめだねー。擬色がちらほらと発生している。画質も荒いというか、なんかむりやりシャープネスかけているような。なんかあちこちジャギっている。

FinePix 4700Z、解像度が足りない感じがする。さすがにA1判くらいまで拡大するとツラいか。細かい輪郭なんかはジャギっている。

CAMEDIA C-3030Z、画素数はあるはずなのに、あるはずなのに…。画像処理部分の問題なのかもしれない。色が変化していく部分で誤差分散のドットが結構目立つ。

COOLPIX 990…あれ? 雑誌で見た時と画質が全然違うぞ。なんで? 雑誌の記事ではかなりCCDのノイズに振り回されていたような感じだったけど、あれも試作機だったのか?
これならCOOLPIX 800買わないでCOOLPIX 990買ってたかも。

個人的にはCOOLPIX 950の画像よりもCOOLPIX 800の画像の方が好み。

2000年07月17日

1時ころ反論メールを送信。

1時50分、メールが届く。

ふむふむ、なかなか手強い。ただやはり人に物事を説明するのは非常に勉強になるので説明を試みてみます。

同じように、関数から別の関数を呼び出してもスタックを消費します。関数から他のいろいろな関数をネストして呼び出していればそれだけスタックを消費します。

たしかにそうです。

foo()→foo()→foo()→foo()→foo()
と呼び出してスタックがオーバーフローするのなら、同じように foo()→bar()→baz()→fprintf()→write()
というように関数を呼び出していってもスタックはオーバーフローすると思います。それぞれのスタック使用量が充分に多ければですが。

現実的に考え、foo()→bar()→baz()→fprintf()→write()、他の関数を呼ぶことによるスタックオーバフローすることはありません(WindowsやUnixの世界では）。実際に私はWindows&Unixの開発に１０年以上も関わっていますがそのようなバグは見たことがありません。もしそのようなコードを書く人がいたら、残念ながらその人はプログラマーと呼ぶべき人ではありません。したがってこの件は議論の対象にはならないと思います。

char buf[1024];という感じでローカル変数を定義するだけで1Kものスタックを簡単に消費できます。DOSでは簡単にスタックがあふれました。

たしかにそうです、ただその場合の問題はスタックというより、メモリーの概念で考えるべきでしょう。例えばグローバルでchar buf[1024]と定義した場合DOSの場合そのメモリはスタックではなくデータセグメントに格納するはずです、その場合コンパイラにはそのデータセグメントの大きさは考慮してくれないので同じようにデータセグメントであふれてしまいます。

まずここで説明すべきはたぶん、関数から別の関数への呼び出しと関数から同じ関数への呼び出し（いわゆる再帰）の違いについてです。基本的に関数から別の関数の呼び出しは有限回であるが、再帰呼び出しは無限回の可能性がある。なぜなら多くの場合（この場合１００％ではないが）、無限回のアルゴリズムを実現するためのメカニズムが再帰呼び出しである。例えば1+2+3....無限大、1/1+1/2+1/3+...1/無限大、さらにはソートやサーチ。今のWindows なり、UnixなりのOperating systemは有限回のスタック呼び出しに対しては必要十分なスタックメモリーを積んでいます、しかし今現在のOperating systemをもってしても無限回の再帰呼び出しに対してはなすすべがないというのをたぶん説明するべきだったのでしょう。

一回の呼び出しあたりのスタック消費量は大差無いと思います。

そうです、まったく消費量は同じです。しかし前述したように：総スタック消費量を考えると

（別の関数呼び出しのスタック消費量）x (有限回）　= 有限byte(これは商用OS でほとんど収まる量）

（同じ関数呼び出しのスタック消費量）x ( 無限回）　= 無限byte(これは商用 OSでハングアップする量）

という公式が成り立つため、別の関数呼び出しより、再帰呼び出しのほうがコードを 書くうえで注意しなければならないのです。

こんなもんで、納得していただけたでしょうか？

納得できーん。

なんで無限回再帰呼出しをするのだ。

なんでスタックを消費するためにchar buf[1024]をグローバル変数にしてしまうのだ。

というわけでさらに反論をメーる。

こんなもんで、納得していただけたでしょうか？

まだまだです。

現実的に考え、foo()→bar()→baz()→fprintf()→write()、他の関数を呼ぶことに> よるスタックオーバフローすることはありません(WindowsやUnixの世界では）。実際

例として書いたため、関数呼出しがたったの5つしかネストしていないので意図が 伝わっていなかったのかもしれません。 例では5つしか書きませんでしたが、5000個位の関数がネストしていたとしたらス タックを消費しつくす可能性も出てくるのではないでしょうか。

に私はWindows&Unixの開発に１０年以上も関わっていますがそのようなバグは見たことがありません。もしそのようなコードを書く人がいたら、残念ながらその人はプログラマーと呼ぶべき人ではありません。したがってこの件は議論の対象にはならないと思います。

ほぼ同意見です。ただ、プログラマとは呼べないというのはちょっと厳しい感が あります。私としては「プロのプログラマ」とは呼べないという程度にとどめて おきたいところです。プロのプログラマとは呼べない理由については後で述べま す。

char buf[1024];という感じでローカル変数を定義するだけで1Kものスタックを簡単に消費できます。DOSでは簡単にスタックがあふれました。

たしかにそうです、ただその場合の問題はスタックというより、メモリーの概念で考えるべきでしょう。例えばグローバルでchar buf[1024]と定義した場合DOSの場合そ

なぜスタックでは考えていけないのでしょうか。

スタックオーバーフローが発生する原因について議論しているところではヒープの消費量はあまり関係があるとは思えません。

のメモリはスタックではなくデータセグメントに格納するはずです、その場合コンパイラにはそのデータセグメントの大きさは考慮してくれないので同じようにデータセグメントであふれてしまいます。

そして、ローカル変数として定義した場合にはデータセグメントではなくてスタッ クセグメントに格納するはずです。

ここで問題にしたいのは、スタックの消費量です。グローバル変数では、大抵の場合、スタックは消費されません。ですからグローバル変数については議論の対象からは外しても構わないと思います。

現在のOperating systemをもってしても無限回の再帰呼び出しに対してはなすすべがないというのをたぶん説明するべきだったのでしょう。

無限回の再帰呼出しというのは、無限ループと同じです。つまり、端から見ているとハングアップしているのと同じです。これは再帰呼び出しによる問題ではなくて、単なる設計上の問題です。無限ループと同じことですから。

このような無限ループや、無限の再帰呼出しによるハングアップしてしまうような設定をしてしまうようでは、良いプログラマとは言えません。ハングアップしてしまう原因を、再帰呼び出しの責任にしてしまうようであれば、少なくともプロとしては認めたくありません。

また、気付かないとしたらテストが足りないためです。これもプロとしてはあるまじき態度です。

　　（同じ関数呼び出しのスタック消費量）x ( 無限回）　= 無限byte(これは商用OSでハングアップする量）

無限回呼び出してしまうのでは、先程書いたように仮に無限のスタックがあったとしてもハングアップしてしまいます。これは致命的なバグだと判断します。

という公式が成り立つため、別の関数呼び出しより、再帰呼び出しのほうがコードを書くうえで注意しなければならないのです。

再帰呼出しを行っているか、いないかに関らず、スタックの消費量、メモリの使用量には注意すべきです。

スタックオーバーフローなバッファオーバーランなどのバグはセキュリティホールにもつながりますから、関数の実装形態に関わらず注意しなければなりません。

引用部分がネストするとみにくいなあ。スタイルシートの変更を検討します。

FSHISOで DTさんが、プライバシーの侵害について明確な基準を設けることができないことと、その際の運用として

を比較して判断してはどうか、という発言を受けて

このような判断は現実には無理だからです。これでしたら、「声が 大きい者の勝ち」みたいなことになると思いませんか？

という発言をなさっている(10番会議室、発言番号27960より)。

実際問題というか、現実の流れとしては

声が大きいものの勝ち

というのがトレンドなので、私感としては非常に流行に乗った運営方法だと思う。

ビデオデッキもフロッピーディスクドライブも牛乳も、最終的には声が大きい方が勝っているし、それでみんな納得しているように思えるから。単に声が大きいというのが多数派であるというだけなんだけど。

雨、降りまくり。がっくし。

2000年07月16日

DirectXでModeX(320x240x8)を使う方法がよく解らない。

解らないのでOh!Xの付録CD-ROMからDirectX7SDKをインストール。

っていうか、LibrettoだとModeXを使おうとするとエラーになるし列挙してもModeXは出てこない。FIVAではうまくいっていたのでますます解らない。SEGAのSky Targetがちゃんと320x240x8で表示しているみたいなんだけど、実はVGAでStretchしているとかいう落ちなんだろうか。

320x200x8ならうまくいく。っていうかものすごく速いので感激してしまう。

Librettoだと320x240程度がゲームで使える限界っぽい。640x480だと20fpsくらいしか出せないような気がする。高々307,200バイトの転送が間に合わないとは思いたくないのだけど。

まあ320x200で作るとして、何を作るか。

昨日のメールの返事が届く。

再帰呼出しでスタックオーバーフローを起こしますか?

一般的に言ってまずい再帰呼び出しでスタックオーバフローを起こすはずです。たぶんアセンブラにコードをうまく書けば（関数内でスタックを使わないよう、push,pop関数等）問題ないと思いますが。Ｃで書く限り（スタックを使わないコンパイラオプションがあれば別ですが、あるのかな？）関数を呼び出す際に必ずスタックを使います(void渡しvoid リターンでも）。disassebleをしてみれば関数を呼び出す前にかなりの数のpush命令が見れるはずです。私個人的な想像なのですが、Ｃで書く限り関数呼び出し以外にスタックを使うことはあまり見受けられないと思います。という事は帰納的に考え再帰を繰り返す事が一番スタックメモリーに影響を及ぼすということになるため注意が必要だと考えたのですが。

スタック消費量が大きければ1回の関数呼出しでもスタックオーバーフローは起こります。 つまり、問題は再帰呼出しを行うからではなく、スタックを消費するからです。

それは確かです、ただスタックの消費量が大きいとは再帰呼び出ししを繰り返したか らとしか考えられないと思います。例えばlocal変数はstackに積まれますが、スタッ クの消費量が多いほどのローカル変数を持つことはあまり現実的とは思えません（も しあったとしてもそれはポインタ渡しするべきですし）。と考えると"スタックを消 費する"=”再帰呼び出し”という構図になると思うのですが？

「関数からの関数呼出しを禁止する」

という非常にナンセンスな制限を行うしかありません。

ナンセンスかナンセンスでないかは言及するのは難しいです。ソフトウエアの品質を考えた場合、再帰呼び出しをテストをする技術はまだ確立されていないともに、コードの品質が高められるとも低くなるともまだ定説がないからです。さらに現実的にそういうことしている開発会社もありますし。

てな感じですがどんなものでしょう？

なんか話が通じていないというか。頭が痛くなってきたので再反論は後日。

2000年07月15日

あぢー。

DDR3rdMIXPLUSでdouble練習。ANOTHERのばんぶるびーとか。

MANIACのばんぶるびーは少し上達。

ほほう、こんな公式がありましたか。うるう年で日付がズレていくのは2月以降なので2を引くというところまでは思いつきましたが、((13*$month+8)/5)は思いつきませんでした。昔からテーブル引いて計算していたのでこれ以外考えようともしていません。悪いくせです。

倉木麻衣と宇多田ヒカルってそんなに似てますか? プロモーションは似ているかもしれないけど、声は全然違うような。FM音源で言うところの(余計判らん)アタックレートとモジュレータのレベルが全然違うような感じがします。フレンチホルンとトランペットくらい違う感じが。ホルンが倉木麻衣で、トランペットが宇多田ヒカル。

っていうか、コナンのエンディング、てっきりコナンの声優さんが歌っているのだと思っていたくらいです。

Programmer's checkをぷるうぇい。プログラマ指数100とか出てちょっちショック。たけしの挑戦状、プレイしたことはあるんだけど、アレは「遊んだ」と言っていいのだろうか。

まぐまぐのID26638、ソフトウエアの開発手法というメールマガジンで、

実は私は”再帰”を使用することについてとっても反対してました、もし使うような 部下がいたらサンダルを投げたりして叱咤しちゃいました（森川君ごめんなさい、 反省してます）。なぜなら再帰は一歩間違えるだけで、スタックオーバーフローで ＯＳが死んじゃいます。それに例えうまく動くプログラムでスタックメモリーかなり 浪費させます。

なんて書いてあったので思わず反論のメールを書いてしまう。

スタックオーバーフローを起こしてしまうのは、再帰させるからではなくて、単にスタックを使いはたすからでしかない。

スタックを消費するから再帰呼出しをしてはならないのであれば、

関数呼出しをしてはならない。

なぜならスタックを消費するからだ。

2000年07月14日

朝、FGALTLAとFWINALのデータライブラリを確認。おお、DFが公開されている。すでに何度かダウンロードされている模様。

んがー、最高気温30度ですかぁ(/_;)。泣いててもしかたがないので出勤。

既存の携帯電話の画像形式を教えてもらう。こんな作りになってんのかあ。独創的な感じがする。

えーと、これで火曜までに設計書を作って金曜までに実装すると。予定としては。っていうか完了済み。データさえ抜き出せばBMPファイルになるぜい。上下反転してるけどね。

昼、FGALTLAとFWINALのダウンロード数を見てみる。割といい線行ってるんじゃないか。

2000年07月13日

とりあえずDFをアップロード。

話題になっているAsahi WONDA Hawaiian ICE、割と味はいいのではないかと。

で、このカンに書かれている名文を紹介。

ハワイカウアイ島の高度にシステム化されたプランテーションで、世界でも有数な大量の水を使用する灌漑設備により、コーヒーの苗木からコーヒー豆ひと粒ひと粒まで丁寧に生産・品質管理された「香りが良く適度な苦み」を持つ、アメリカでNo.1の生産量と品質を誇るカウアイコーヒーを100%使用しました。

主語はどれだ。

天気予報で雨とかいう予報。家を出て3分くらいしたところで傘を忘れたことに気付く。まあ、湿度はあるものの青空なので予測が外れる方に賭ける。

バスから降りたらなんか曇り空。やはり傘を持ってくるべきだったかとか思ったところで雨が振り出す。

ちぇっ。

携帯電話の画像をBMP形式に変換する必要があるらしい。とりあえず出来るのでやる。これで1週間くらい時間が稼げる(極悪)。こんなことならあと1週間くらいDFの改造をしててもよかったかも。

O.S.R.に登録。

2000年07月12日

Libretto 100とFIVAとではどちらの液晶がきれいかなんていうことを訊かれてしまう。多分に個人の趣味に依存してしまうような気がするがこだわらない。

私としては、劣化を考慮しなければFIVAの方が好み。

面倒なのでDFはそろそろこのあたりで@niftyとかVectorで公開してしまおうかとか計画中。

2000年07月11日

ちょっち寝坊する。あたふた。

FIVAPMについてメールを頂く。各種ボタンが解りにくいということなのかツールチップを付けてくれないかという感じ。確かに解りにくいことこの上ない。

どの位解りにくいかというと…あっ画像が無い。ちょっち古いけどこんなの。

FIVAPMのインジケータ

この右側のアイコン、●■×が何の動作をするのか、初めて見た時に解る人はいないのではないか。そのくらい良くないUIだ。しかも、このアイコンの下の隙間。ココをクリックすると省電力設定ダイアログが開くという無節操さだ。もう、想像しろといわれても無理だ。

最初は●■×の代わりに漢字一文字で書くとかいうのはどうかとか思ったのだが、書けませんでした。ごめん。

下をクリックしたら…というのは、省電力設定ダイアログを簡単に呼び出せないか、という話があったのでさっそく追加仕様…って誤変換なのか正しいのかよく判らないけど、まあ、とにかくどこかクリックするだけでダイアログを表示できる用にしてくれという話があったの。タスクトレーのアイコンをクリックして、メニューから省電力設定を選ぶのではうっとうしいのだそうだ。でも、私としてはインジケータが大きくなるのはイヤだ。だからボタンは追加したくない。このように返答した。だったら、今のアイコンの下の隙間でもいいからなんとかしてくれと言われてしまった。確かにこれなら大きくならない。

そういう経緯があってこのようなUIになっている。どうやって使うか、というのが徹底的に後回しになっているという、ユーザのことはまるっきり考えちゃいないすばらしいプログラムだ。

で、ツールチップを簡単に付けられるのなら付けてもいいんだけど…と思ってSDKで簡単に作れるか調べる。MFCだとCToolBar系なら勝手にやってくれたりするんだけど、FIVAPMはただのフレームウインドウだったりするので。

で、CreateWindowEx()でツールチップウインドウを作って…

CreateWindowsHook()で、メッセージループにフックを仕掛けて、

自分でマウスイベントを検出してツールチップウインドウにメッセージを送る。

自分でウインドウ作るのと何も変わらないじゃん。

2000年07月10日

テレコンワールドみたいなノリで、アニメのLDとかの通販やると結構売れるのではないだろうか。

DDR3rdMIXPLUS、ばんぶるびーのMANIACで16分が踏みきれない。くぅ〜。

晩ご飯はココいちで4辛。

2000年07月09日

FIVAを修理に出す。症状を説明しようかと思っていたけど、見た途端に異常があると言うことは解ってくれたみたい。ただこれは液晶のフレキシブルケーブル、ここにあるんですが(といいつつ、液晶のヒンジを指差す)、これが抜けてるんですよという話。

いや、ソコは多分関係ないと思うぞ…。

とにかく預けておく。なるべく早くねー(^^)/。

コナミのGUN MANIAをぷるうぇい。なかなかいい出来…なんだけど、イマイチ。

まあ、これだけの欠点があっても弾道が確認できるのは結構楽しい。でも、ドコに着弾するか予想できない銃でクレー射撃するのは無謀だとつくづく思った。

全体的に、難易度は最初だけ低め。後からがんがん上がる。右側のモードは最初から割と高め。

いつものようにドトールでコーヒー。目の前にトイレがある席に座る。いや、正面に扉があるだけで、90度ズレているので扉が開いていても中が見えるわけではない。っていうか、ここのトイレ、使用したことがないので内部構造がどうなっているのか知らない。

おばさんがトイレに行く。いや、行くなとは言わないけど。で、出てくる。

扉くらい閉めとけ。

私からは扉しか見えないので気にならないけど、入り口に対して正面に座っているような人だと吹き出してしまうのではないだろうか。幸い、そこには客がいないと言うか、もともとあまり客がいないので問題ないのかもしれないが。

そのおばさん、帰るし。にこにこしてないで、扉くらい閉めてくれ。

2000年07月08日

就職活動のためにパソコンを買わないといけないなんて…とかいう話が。

就職活動のために大学に入るのに比べればはるかに安上がりだと思うんだけど。パソコンを買うのがイヤなら別の会社に就職すればいいし、なにも会社に就職する必要もないような。

何かしたかったら、何かしてほしかったらそれなりの代価を支払うという感覚が今の学生には無いのかもしれない。そごうも借りた金返さないみたいだし。

2000年07月07日

あ゛ぢー。

昨日のアレ、WATCOM C++でコンパイル。

int main(void){
    volatile char a;
    volatile unsigned char u;
    volatile int i;

    u=0x80;
    a=u;

    i=(unsigned)a;

    printf("%d\n", i);
    i=u;

    printf("%d\n", i);

    return 0;
}

コンパイル結果。wcl -s -osrhでコンパイル。

    ENTER     0000000cH,00000000H
    MOV       byte ptr [EBP-8H],80H
    MOV       AL,byte ptr [EBP-8H]
    MOV       byte ptr [EBP-4H],AL
    MOVZX     EAX,byte ptr [EBP-4H]
    MOV       dword ptr [EBP-0cH],EAX
    MOV       EAX,dword ptr [EBP-0cH]
    PUSH      EAX
    PUSH      offset FLAT:L$1
    CALL      near ptr FLAT:printf_
    ADD       ESP,00000008H
    MOVZX     EAX,byte ptr [EBP-8H]
    MOV       dword ptr [EBP-0cH],EAX
    MOV       EAX,dword ptr [EBP-0cH]
    PUSH      EAX
    PUSH      offset FLAT:L$1
    CALL      near ptr FLAT:printf_
    ADD       ESP,00000008H
    XOR       EAX,EAX
    LEAVE
    RET

期待通り、movezxを生成してくれる。

とりあえず手元にあったVisual C++4.2でコンパイル。cl /nologo /MLd /W3 /Gm /Zi /O1 /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /Fp"Debug/CAST.pch" /YX /Fo"Debug/" /Fd"Debug/" /c してみた。

    PUSH      EBP
    MOV       EBP,ESP
    SUB       ESP,0x00000008
    MOV       byte ptr [EBP-0x1],0x80
    PUSH      ESI
    MOV       AL,byte ptr [EBP-0x1]
    MOV       ESI,`??_C@_03HMFC@?$CFd?6?$AA@`
    MOV       byte ptr [EBP-0x2],AL
    MOVSX     ECX,byte ptr [EBP-0x2]
    MOV       dword ptr [EBP-0x8],ECX
    PUSH      dword ptr [EBP-0x8]
    PUSH      ESI
    CALL      near ptr j^_printf
    MOVZX     ECX,byte ptr [EBP-0x1]
    ADD       ESP,0x00000008
    MOV       dword ptr [EBP-0x8],ECX
    PUSH      dword ptr [EBP-0x8]
    PUSH      ESI
    CALL      near ptr j^_printf
    ADD       ESP,0x00000008
    XOR       EAX,EAX
    POP       ESI
    MOV       ESP,EBP
    POP       EBP
    RET

私としてはWATCOMの挙動のほうが素直に思える…。

2000年07月06日

東芝のページからLibretto SSのBIOSアップデータをダウンロードする。Version 7.40。このLibrettoの方が新しいや。捨て。

コンパイラにもてあそばれる。

nifty:FGALEL/MES/2/11979 のぐーさんの発言にあった、

(unsigned)str[0]*256+(unsigned)str[1]

が、Visual C++でうまく動かないような気がした。

char c;
int a;

c=0xff;
a=(unsigned)c;

とか書いた時、aには何が入るか。-1だった。

それはchar→int→unsigned intという順番で型変換されているのだろうから、まあこだわらない。(unsigned char)でキャストすればよいだけの話だし。

ただ、この時のVisual C++の生成コードには大いに不満がある。

a=(unsigned)c;

の時には

mov al, byte ptr [c]
movsx dword ptr[a], al

と、符号拡張転送を使っている。

a=(unsigned char)c;

の時だと

mov al, byte ptr [c]
and eax, 0xff
movsx dword ptr[a], eax

と、and演算が入ってしまう。

なんでmovzx(ゼロ拡張転送)を使わないんだぁ!

日付から曜日を知る方法は無いか、と訊かれた。3分後にこんなのをメールしておいた。

int week(int yyyy, int mm, int dd){
    int day[]={
        0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334
    };
    int y;
    int add;
    int date;

    y=yyyy-1;

    add=y/4 - y/100 + y/400;

    date=y*365+add+day[mm-1]+dd;

    if(mm>2 && yyyy%4==0){
        if(yyyy%100!=0 || yyyy%400==0){
            date++;
        }
    }

    return date % 7;
}

2000年07月05日

ワトソン博士ってWindows 95にはないんだっけ。結構便利なんだけどなあ。

久しぶりにアセンブラを使ったら思いっきりミスする。あまりに恥ずかしいのでここには書けない。RETを書き忘れたなんて、とてもじゃないけど書けない。

古本屋で本を6冊購入。計算が合わないので問いただすと、1冊重複して計算したらしい。危ない危ない。

2000年07月04日

device=c:\windows\emm386.exe NOEMS I=B000-B7FF I=CE00-EFFF

っとしていたらなんかDOS窓がなんか不安定になったのでやめ。キーを押しているだけでも例外出してコケ落ちるようになった。結局

device=c:\windows\emm386.exe NOEMS

とした。

モノクロ領域も取れないのだろうか。アドレス間違ったかな?

2000年07月03日

朝方、ちょっち雨。出勤する頃には止む。

Libretto SS 1000のconfig.sysを編集する。

CE00-EFFFもUMBとして使用できそうなので追加した。

device=c:\windows\emm386.exe NOEMS I=B000-B7FF I=CE00-EFFF

取りすぎか?

昼間、ちょっち雨。

ウィンドウズ・パワー９月号へDFの掲載依頼を頂く。許可する予定。

メールの返信をいくつか。

選択したファイルを外部コマンドの引数として渡すにはどうやったら出来るかというような意味合いのメールをいただく。違うかもしれない。

FDでいう外部コマンドのマクロ$M、$TはDFに存在しない。なんで実装されていないのかというと、どのように実装するのがいいのか判らないからだったりする。単純に実装すると$Tはともかく、$Mは複数のプロセスが同時に起動してしまうので、FDのような動作を期待していると残念な思いをしてしまう。

たとえば 「COPY /B $M PRN」のような登録をしていた場合、FDからなら順番に一つずつ処理していくのでうまい具合にプリンタに出力されて印刷できると思う。しかし、Windowsから実行するとDOS窓が複数開いて、印刷できるのは1つだけで他のはコピー先のオープンに失敗したりしそうだ。

あと$Tの、引数としてファイル名を10個だけ渡す、というのも中途半端な気が。どうせWindowsなら豪快にいけるところまで渡してしまってもいいような気がする。

つまり、ファイラーとしてFDの仕様と全く同じということが必ずしも使いやすいとは思っていない。そこで何らかの改良を施していきたいと思っている。この複数のファイルを選択したところの動作と言うのはまさに、改良すべきところだと思う。

と、思いつつネタが思いつかないのでそのまま何も実装していない状態ではFDより使い勝手が劣っているのは当然と言うか。個人的にはせっかくのマルチタスク環境なんだから節操無く非同期に実行したいところなんだけど、さっきも書いたとおり排他制御的な問題とかがありそうでイマイチ踏み切れない。

2000年07月02日

特訓の隠しコマンドを教えてくれというメールをいただく。教えてしまうと隠しコマンドではなくなってしまう。難しいところ。

一応、暗号化してあるつもりなんだけど実行時には復号化しているので頑張れば盗み見ることは可能。

しかし、ほんとにやられるとは思わなかった…。

DF、順調にヘルプの記述が進まない。

曇り。

DFの設定方法について問い合わせのメールをいただく。

何が悪いってヘルプの記述が解りにくいのが一番の原因。しかもヘルプを書いてから仕様が変わったところや追加された機能などもあるのに、それらの記述や説明が修正されていなかったり追加されていなかったりすると言う状態。

そそくさと返信して外出。

たこ焼きを買って近場の公園で食べる。表面がからりと揚がっていてうまい。

ハンズに行ったらRazorが6,980円だった。安くなったなあ。

フロントフォークにサスペンションがついたものがあったので思わず欲しくなる。

2000年07月01日

曇り。とりあえず出勤していろいろ。

特訓のバグフィクス。

点を修正。

実家に行って弟をRazorに乗せてみる。ハンドルに手が届かないと言うかハンドルをつかむと背伸びしないといけない状態なのでハンドルは伸ばさないで乗せる。

乗せてみても、デッキに立つことすらできない。進むなどと言うのもっての他である。

なかなか寝ついてくれないので横で狸寝入りしていたらいつの間にやら寝てくれた。

トップを狙う

Copyrigiht © 2000 びい