タイトル通り,IPv6 関連の話題を集めたサイトですね。現在私は WinMe を使っているので,OS からして IPv6 をサポートできないんじゃないかなあ? ともかく今は何もできないんで退屈な日々ですが,いつかきっと。
IP が 128 bit で表せるという事は,10 進数では・・書くのも面倒くさい程の数なわけで,本当にそんなに必要なのかと小一時間。従来の IPv4 だって,アメリカではまだまだ IP が余ってるって話ですもんね。
・・とか何とか言いながら,30 年後くらいに「まさか IPv6 が枯渇するとは誰が予想したであろうか」なんて記事を目にしたりする可能性もゼロじゃないので,まったく人間って奴ぁ。
疲労度:0
11 月 9 日午後 8 時。洗濯物を抱えて,コインランドリーへ洗濯をしに行く。200 円で使える洗濯機が 2 台あるが,1 台は現在使用中,1 台は洗濯が終了し,洗濯物の持ち主による回収を待っているようだ。今はとりあえず諦める。
午後 9 時。洗濯物を抱えてコインランドリーへ。先ほど洗濯中だったそれは既に洗濯を終えたようだが,2 台とも未だに持ち主の回収を待っている。とりあえず諦める。
午後 10 時。洗濯物を抱えてコインランドリーへ。洗濯物の持ち主は未だに回収していない模様。同一人物が 2 台とも占有しているのだろうか。人の迷惑というモノを考えて欲しい。とりあえず諦める。
午後 10 時 30 分。洗濯物を抱えてコインランドリーへ。どうも私はこの人物にナメられている気がする。今日は諦めよう。
( 午後 11 時,コインランドリーの営業が終了 )
( 11 月 10 日午前 8 時 30 分,コインランドリーの営業が開始 )
午前 9 時。洗濯物と一抹の不安を抱えてコインランドリーへ。そして不安的中。何? もしや,事件のにをいがしますか? 一線を超えたい気持ちを辛うじて抑え,家へ。
午前 10 時。洗濯物を抱えてコインランドリーへ。洗濯機が一つ空いているので,それを借りる。・・・隣を見ると,少なくとも 14 時間以上その状態を保っているモノが目に映るが,気にしないことにする。
午前 10 時 30 分。洗濯終了。今週もキレイな気持ちでがんばりましょうっ。
疲労度:67481 x 7 日分
おそらく上記 2 件の洗濯物はそれぞれ別人によるモノだと思われるわけですが,こんなにルーズな人 2 人が同時にコインランドリーを占有しちゃう確率も凄まじいですよね。つまり私が言いたい事は:リソースはきちんと確実に破棄する努力を惜しむな,と。
そういえば,ガベージコレクタの威力炸裂な Java にも,ファイルストリームクラスにはちゃんと close() メソッドが用意されているんですね。これによりファイルが閉じられるタイミングをプログラマが制御できるようになっています。一般的なファイルシステムの都合上,当然と言えば当然だけど。
って,わざわざリンクを以って紹介することもないほどに基本的なサイトですが,このサイト内のコンテンツの一つ,「C プログラミング診断室」第 4 章「キャストが好き」内の「float 型対 double 型」を読めばもう float 型を使いたくなくなります。( そう言えば AMD 製 CPU「Duron」は FPU が無いと聞いたんですが,まぁそれはそれとして・・・ )
さらに最近 VC++ML で "printf 系の関数で float を使うべきではない" とする話題も登場。その理由は,可変引数の不思議な仕様に由来するらしく。。。
可変引数部分へ値を渡す時,それら引数のバイト数合計は sizeof(int) の倍数でなければならないという決まりがあります。すなわち char や short int は両方とも int 型にキャストされます。不思議なのは float で,例えば手持ちの VC++5.0 では sizeof(int) = 4 であり,また sizeof(float) = 4 でした。おお,float は他の型にはキャストされないのかーと思っていると実はそんな簡単な話ではなく,なぜか float は double にキャストされる決まりがあるようなのです。
まだこの仕様が存在する理由を見つける事は出来ていませんが,そうならば敢えて float を使わず,最初から double を使っておくべきですよね。こうして float は歴史の波に飲まれてゆくのです。畏れ
疲労度:10
すなわち RFC2397 です。例えば IMG タグの src 属性に次のような変わった URL を記述する事で:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAIAAAD8
GO2jAAAA4UlEQVR4nO2VvQ2DMBCFn6PswASewLPY2yD2sDeA3hR01GYDFmAKUlxkkUgkd5Ip
ovgVyEj3/Pl+DGrfd1yp26W7V8B/AO5SQwhhmiYAfd9z4pX0HiilaME0ykrknBPFPw/ClLUW
AD35Rm5cjBGAMSZXpjDAGJM3JYC1lmNk9cA5tyyL955eCVasB1R0Ks4xmzIZjOM4DAOAlJLg
1Ad9uWht29Iij39JgNZ6Xdc8l1nzPG/bxiWc1a7rOryW/q0HH7xHnQY1TQMgxngJgPxnc0LJ
MQHij51Uv//DqYAKqADgAdKOZKU6j84RAAAAAElFTkSuQmCC"
alt="character A" width="32" height="32" />
↑画像が見えてますか? この URL スキームに対応しているのは,私が確認した限りでは Netscape4.78 と Mozilla でした。Opera はどうなんだろう? IE では対応していないようです。
セキュリティホールの温床にもなりそうですが,しかし案外セキュリティホールに気づきやすく,修正もしやすいような気もします。IE でも採用してみればいいのに。・・とは言うものの,使用する場面が限られてます・・かね・・。
疲労度:96
image/gif て書いてたんだけど,mozilla は PNG だと解釈して表示してくれました。・・いいの?2002-10-31 で紹介した project Dentalcare さんから,こちらにもリンクして頂けました。Google とかの検索エンジンを除いて,私がハッキリとリンクされたのに気づいたのは初めてです。いやぁもうこちらこそ,よろしくどぅぞ,ですよ <(*´Д`)
私はここで「zlib を使おうねー」と主張したいのではありません。「コードを読もうぜ gehehe」と主張するために今日の雑記を書いています。ああ素晴らしき車輪の再発明。
ver 1.1.3 にセキュリティホールが発見され,その直後に 1.1.4 がリリースされたのはもう半年くらい前の話でしたっけ? 最近はすっかり忙しくて deflate のアルゴリズムの調査から遠ざかっていましたが,今日,仕事中に何気なく zlib からソースをダウンロードしてみました。
残念ながら 1.1.3 のソースの詳しい部分は忘れてしまいましたが,しかし 1.1.4 は明らかにコードが整理され,格段に読みやすくなっています。きっと 1.1.3 のコードの整理中に free() 二重解放バグを見つけたんでしょうね。
しかし,どこがどう違うから“読みやすいと”感じたんでしょうね? Assert() があちこちで活用されているから? 1.1.3 に Assert() なかったっけ? 記憶ってのは曖昧でイカンです。
疲労度:0
技術者として興味があるのはどちらかと言えば,このサイトのコーナーの一つ「たのしい XML」ですかね。正確な説明ではないとの事ですが,楽しいイラストを交えながら要点を確実に押さえていきます。
XML を用いた表現方法やその応用,XSLT,さらには DOM にまで広く深く精通している人はそんなに多くないわけで,そのへんは私の苦手な「センス」なんだろうな。うらやましいっすわー。
疲労度:574
折角作ったんで,公開しておきます。
注意事項をよく読んだ上でボタンを押すと,ブラウザに約 90KBytes のデータを送ります。そしてそのデータをブラウザが約 20MBytes に膨張させ,ブラウザやシステムがどうなっちゃうのかを観察するのです。
しつこく言っておきますが,実験はあくまでも自己責任でお願いします。
上記の CGI にも紹介している通り,ある意味世界最強の OS "WindowsMe" + 開発途上ブラウザ "Mozilla 1.2b" ( しかも nightly!! ) ではビクともしませんでした。しかし某掲示板で協力してもらった人たちの一人,Windows2000 + IE6 + メモリ 300MBytes 強というかなり強固な環境の方が実験したところ,ブルースクリーンが出てしまったとのこと。バックグラウンドで稼動させているソフトウェアからも影響を受けるのかもしれませんが,それにしても意外な現象でした。
さて,平均的に 20MBytes 程度ではビクともしないようなので,一気に 100GBytes と逝こうか GE-HE-HE-!! とか思ったけど,やめました。圧縮データ 9bits = 展開後 258bytes なので,展開後 100GBytes = 圧縮データ 445MBytes に相当します。データを作れない事もありませんが,しかし何のためによ? その先に何が待ってるよ? こんなくだらない実験で虚無感を覚えたくはありませんよね・・・。
疲労度:65931
Mozilla はネット上のリソースを保存する時,一度リソースに HEAD リクエストを投げて Content-type の結果を見ているらしい,という話題を 2002-05-27 で扱いました。
さて我らが(?) Netscape 社は HTTP サーバも作っているらしくて・・・正式名称は何? HTTP レスポンスでは "Netscape-Enterprise" と名乗るので,このリソースではそう呼ぶ事にします。
その Netscape-Enterprise が使われている現場を探すのはなかなか大変です。既に HTTP サーバ市場は Miscrosoft の IIS と Apache で占められているんですよね。ちなみに Google は自前サーバなので萌え。Microsoft 製品は嫌いだが,無保証な Apache を使うわけにはいかないような企業と言えば Sun を思いつきます。JDK や JRE なんかをダウソするために頻繁にお世話になりますね。
そこで問題発生。私が JRE をダウソしようとした時,Mozilla はいつものように HEAD リクエストを Netscape-Enterprise に投げました・・
・・Mozilla 硬直っ!
即座に“プログラマの勘”発動,試しに私自身で,簡単な HTTP クライアントで Netescape-Enterprise に HEAD リクエストを投げてみました。するとレスポンスヘッダのみならず,本体までもがゾロゾロと。JRE のサイズはおよそ 9MBytes。このすべてのダウンロードが終了しサーバから切断されるまで,Mozilla はだんまりを決め込むのでしょう。
というか,なぜこんな事が起こったのでしょうね。Sun がそのような設定をしたから? それとも Netscape-Enterprise は HEAD リクエストに対応していないとか? 何はともあれ Mozilla には HEAD リクエストへのレスポンスに本体部分まで返って来てしまうケースも踏まえるように要望を出してみたいんだけど,既に Bugzilla に登録されているかどうかを調べるのが億劫でイカンですな・・・。
とりあえず私は Iria/OpenIrvine を応援しています。じゃないと JRE がダウソできないし。
疲労度:774
今日はアンチエイリアスの真似事をしていました。
アンチエイリアス ソースコード ->aa01.h; ->aa01.cpp;
でも実は,これはまだダメな部分もあったりします・・・詳細は明日ということでっ。
疲労度:290
Painterly Rendering with Curved Brush Strokes of Multiple Sizes
面白い 2D 画像レンダリングアルゴリズムです。DAKIN's 3D Collection さんはいくつかの面白い論文や資料を紹介していますが,その中の一つですね。
いくつかの太さのブラシを使う事とし,太いブラシから順に用いていきます。スプライン曲線などでまずは大まかに色をぬりたくり,徐々に細いブラシを使って細かい部分を描画してゆくと見事に油絵がレンダリングできるわけですね。
改良するとしたら,ブラシを描画する曲線の向きに合わせて既にキャンバスに配置描画されている色を "かすらせる" ようにシミュレートするとか。処理速度などにかなり影響すると思いますが,やってみたいなー。
疲労度:34
10 月も終わったし,そろそろこの雑記も 200 回を迎えるはずなんだけどもう数えていません。正直,なんでこんなに続いてるんだろうね。。。
最近,こんな感じのサーチエンジン代行登録スパムがあるんですよね。日本語訳するとこう:
あなたのサイト見たんスけど,あれだ,サーチエンジンに登録されてないでしょう。私んところのサービスは効率よくサーチエンジンにアレしますよ?
こんなスパムのほとんどは,よせばいいのに「あなたのサイトを見た」という証としてサイトの画像をつけてくれています。ナメてんのか。
その画像をよく見ると。。。私のサイトじゃない。。。でもこれは見覚えがあるんですよ。。。そう,これは我が心の師匠のサイト:
"project Dentalcare"(註:元々 www.dentalcare.jp にリンクしていましたが,外しました)
管理者は鳩羽狩行さん。サイトを見れば一発で分かりますが,DCT,MDCT,AntiAlias の解説は ( まだよく分かってない人には ) 必見。それから以前はアルファブレンドの実験もやってたと思ったんだけど,あの文書はどうしたんだろう?
しかし,なぜ project Dentalcare さんのサイトの画像がよりにもよって私のメールアドレスに送られてきたのかが最強の謎。project Dentalcare さんのサーバには確かに私が使った IP は残っているでしょうが,しかし私のメールアドレスと project Dentalcare さんを結びつけるモノは何もないはずなのです。
結論は全くの偶然。その確率を計算するには,天文学的数字が登場します。
確率:およそ 1 / 5494t@4083@&ta[23ぬん9
心の師匠はとっくの昔にサイトを閉鎖し,www.dentalcare.jp というドメイン名を手放していました.今の www.dentalcare.jp はドメイン名の額面通り,歯科医院さんのサイトです.皆さんもぜひ歯は大切に.……本当に,歯だけでも大切に(;´Д`)
しかしまあドメイン名とは流転するもの.手放されたドメイン名は,存在しなくなるのみにあらず,新たな人の手に渡る事もあるんすねー.
この時代にあります私はぜひ,一つのドメイン名と生涯を共に.
今日はちょっとメモのつもり。そういえば,こんな感じで fopen() を整理した事はなかったような気が。ファイルを開くオプションを表にまとめておけば,今必要なものが一目瞭然です。
"ra+" などというファイルの開き方。初めて知りましたとも ( 非推奨だけど )。
疲労度:0
かなりマイナー且つ揮発性抜群のネタですが気にすんな。Prohosting と言えば昔は広告表示義務のない,異常なまでに寛容なレンタル Web スペース屋さんでした。残念ながら既に運用ポリシーが変更され,無料で使用する間はややうざったい広告が自動で挿入されます。多くの場合 HTML の記述は一部を破壊され,少なくとも strict な xhtml とは呼べないドキュメントの完成です。
最近の出来事ですが,Prohosting サーバがヘッダとしてこんな値を返すようになりました。
Content-Type: text/html; charset=ISO-8859-1
自力で Content-type を出力していない限り文字コードは ISO-8859-1 が仮定され,Shift_JIS や EUC-JP をブラウザが正しく解釈できずに「化け」てしまいます。
これの解決法はなかなか厄介。CGI ならば自前で charset を含んだ Content-type を出力してやるべきです。
print "Content-type: text/html; charset=Shift_JIS\n\n";
CGI でない場合は HTML 要素の一つ "META" で指定する事も考えられますが,少なくとも Mozilla では効果がありませんでした。.htaccess ファイルを記述することでどうにかならないかとも思ったんですが,prohos って .htaccess 使えたっけ? ちなみに coara さんは .htaccess を使うと Internal Server Error になるので萎え。
結論としては,prohos に日本語サイトを作る事は出来ないと考えてよいかと。。。
疲労度:4982
いい加減に 64 ビットのコーディングに馴れるべきだと思いました。さもなければわずか 40 億の数字を扱おうとした時点で敗北に迫ります。わずか数ギガバイトのディスクの容量も求められません。約 30 年後にはパソコンの時計を信用したくなくなります。
ただし,まだまだそれぞれのコンパイラはそれぞれの実装のようです。
VC++5 自体すでに過去のコンパイラですが,きっとこのあたりの仕様にはあまり変化はないと思います。
__int64 i = 9223372036854775808;
printf( "%I64d\n", i ); // -9223372036854775808
printf( "%I64u", i ); // 9223372036854775808
ちなみに次のコードは「error C2593: 'operator <<' があいまいです。」というエラーによりコンパイルできませんでした。ostream::operator << (__int64) が定義されていないんですね。
__int64 i = 9223372036854775808;
cout << i << endl;
・・実は持ってはいないんだけど,ネット上に落ちている情報ではこんな感じでした。フリーのをダウソするのは億劫なんですよね。通常 Win アプリを作るなら VC++ を持ってるし,より ANSI 標準に準拠した C++ を勉強したいなら gcc on cygwin があるし。
面倒がらずにダウソしろって? いやです。
__int64 i = 9223372036854775808;
printf( "%Ld\n", i ); // -9223372036854775808
printf( "%Lu", i ); // 9223372036854775808
printf() による出力時,特別なキーワードは用意されていないようです。
正確には g++ と言った方がいいんですか? このあたりの用語の使い方がいまいちよくわかりませんが,そのうちなんとかなるでしょう。笑い
long long s = -9223372036854775808;
unsigned long long u = 9223372036854775808;
printf("%lld\n", s );
printf("%llu", u );
ただし,上記のコードをコンパイルすると "decimal constant is so large that it is unsigned" というウォーニングが出るのでウザいかも。それから gcc 2.7.2.1 on FreeBSD ではクラッシュするという情報があります。次のような書き方が紹介されています。
long long s = -9223372036854775808;
unsigned long long u = 9223372036854775808;
printf("%qd\n", s );
printf("%qu", u );
なお g++ は ostream::operator<<(long long) を実装しています。さすが,ナイスでイカスなコンパイラ。
long long s = -9223372036854775808;
cout << s << endl;
疲労度:0
そういえば Delphi でも同じ事を言われた気がしないでもない気が。究極的には,時間と根性さえあれば手持ちの VC++ で C# の上等な IDE だって作ることが出来るんですよね。でも一般人が C# を実装するには MS の特許が絡むらしいという情報を入手っ。MS は C# を普及させるのを嫌がっているとしか考えられませんよ?
ちなみに Perl で perl を作るには? ・・・ eval 一発ですか。笑い
疲労度:0
型キャスト,好きな時に適当に使ってればいいやと思っていたのですが,実はまれに重大な値の操作も行うんスね。私はすっかり型キャストをナメていました。・・ほとんど仕様書を読んだ事がないのも問題なんですが・・・
とりあえずこんなコードを組んで見ます。
#include <stdio.h>
int main(int c, char *v[]) {
int i = 128;
int k;
for (k=0; k<256; ++k) {
char c = k;
if (i == c) puts("eq");
}
return 0;
}
とりあえず何かあれば文字列 "eq" が出力されるように見えますが,実際には何も表示されないまま終了します。
さて,上のコードに 1 行だけ付け足してみます。
#include <stdio.h>
int main(int c, char *v[]) {
int i = 128;
i = (char)i; // <- これ
int k;
for (k=0; k<256; ++k) {
char c = k;
if (i == c) puts("eq");
}
return 0;
}
コードをコンパイル,実行すると,なんと "eq" が表示されたじゃないスか。これが「型キャスト」の特異な機能を表す例の一つ。なぜこれが起こるのかを考えるのは,ちょっと大変かも。。。
疲労度:12
ひとまず,MSDN でも読んでみることにします。日本語訳をつらつらと書き連ねてもよさそうでしたが,それっていわゆる日本語 MSDN なので却下。
結局コンソールを表示させずにプログラムを動作させるには DETACHED_PROCESS というフラグが重要でした。このフラグの意味するところはつまり,これから起動する子プロセスは,自力で ::AllocConsole() を用いない限りコンソールへのアクセスは不能であるという事。逆に自力で ::AllocConsole() を行うプログラムはどうしてもコンソールが表示されてしまうという事でもあるので注意が必要なんですね。
また,ここで同時にプロセスの優先順位を示す NORMAL_PRIORITY_CLASS とも OR をとるべきだったとも思います。特に明示しなかった場合は自動的に NORMAL_PRIORITY_CLASS が仮定されるようですが,後でこのコードを見た時に「そういえば,ここで優先順位の指定が可能だったなあ」と思い出すことが出来た方が良くありませんか?
それから重要な事:ハンドルはすぐに閉じるべきです。::CreateProcess() はプロセスのハンドルとスレッドのハンドルを作成しますが,それらの終了を検出したりしたいワケでない限り,ハンドルはすぐに閉じてしまって構いません。さもなければプロセスはシステムに残留するようです。
というわけで,2002-10-25 のコードを改良するとこんな感じ:
#define STRICT
#include <windows.h>
#include <stdio.h>
int PASCAL WinMain( HINSTANCE, HINSTANCE, LPSTR cmd, int ) {
PROCESS_INFORMATION pi;
STARTUPINFO si;
::ZeroMemory(&si,sizeof(si));
si.cb=sizeof(si);
BOOL r = ::CreateProcess(
NULL, (LPTSTR)cmd, NULL, NULL, FALSE,
DETACHED_PROCESS | NORMAL_PRIORITY_CLASS,
NULL, NULL, &si, &pi );
if ( r ) {
::CloseHandle( pi.hThread );
::CloseHandle( pi.hProcess );
}
return 0;
}
見た目では大したコードではありませんが,これが必要な人にとってはよく効く ( 利く? ) コードです。
あ,もう一つ重要な事:あなたが ::CreateProcess() の解説ページを作るとき,掲載するソースコードを必ず見直して下さい。PROCESS_INFORMATION 構造体のインスタンスのポインタを求める時に HTML 内で "&pi" と書いちゃったりすると,少なくとも mozilla ではきちんと "π" が表示されてしまいます。忘れずに "&pi" と実体参照文字に置き換えるべきですね。
疲労度:141