2006/12/30

第17版公開

だいぶ遅くなったが、ようやく「主筆」第17版を公開しておいた。 本当ならもう少しテストをしてから公開するようにしたかったのだが、あまりにもやる気がなくて、かつ、できれば年内に公開しておきたかったから、とうとう公開してしまった。

今のところ、配布用パッケージはリリース用にビルドすると自動的に生成されるようにしてある。要はMakefileにパッケージ生成から圧縮・md5の署名の生成までを行うスクリプトを記述してあるのだ。だが、それは実行バイナリに対するものだけでああって、ソースコードの配布用のファイルは生成してくれない。毎回必ずソースコードも配布している現状を考えれば、上記の対処は片手落ちだといわざるを得ない。ソースコードの配布用の圧縮ファイルまで自動生成してくれるスクリプトを、どこかのタイミングで作成した方が良さそうだ。

配布用ファイルのmd5の署名は、上に書いたとおりMakefile内で自動生成している。そしてそのために、署名を生成するためのプログラムを作成して、署名時にそれをコンパイルして実行するようになっている。

md5のソースコードはRFCの何番だったか忘れたが、公開されている。今まで俺はそれをそのまま流用して使用していたのだが、ソースコードを配布することを考えると、著作権的に問題があるのではないかと思い、使うのをやめた。

とは言っても、自分でmd5のアルゴリズムを実装するのもあほらしいから、そこまではやらなかった。結局、Solarisがmd5のAPI関数を提供していたから、それを使うようにしただけだ。手抜きなのも甚だしいが、まぁいいだろう。

第16版から第17版にかけて、約200KB程度容量が増えているが、これは別に、その分だけ機能が増えたと言うわけでもない。確かにいくつか機能を追加しはしたものの、圧縮した状態で200KBも増えるような追加はしていない。容量が増加した原因は、添付しているアイコンが増えたことと、より強力に最適化を行うようにしたことだ。

Sun studio 11には、binoptという実行バイナリの最適化を行うツールが添付されている。今まではそんなものの存在を知らなかったから使わないでいたのだが、せっかく付いてくるのなら使っておこうかという事で、採用することにした。そしたら実行バイナリの容量が多少増えてしまったようだ。だがまぁいいだろう。

古い話になるが、第15版から第16版にかけて、配布ファイルの容量が約1MBも増加しているのだが、この原因は配布形式の変更にある。今までは、インストーラーをShellスクリプトで自前で記述していたのだが、それをパッケージに変更した。

パッケージにしたからと言って、直接的に容量が増加する原因にはなり得ない。だがしかし、パッケージにすると、中のドキュメントがインストールするまで参照できなくなってしまうという問題がある。そのため、ドキュメント(pdfファイル3つ)は、パッケージ内に含めるのと同時に、圧縮ファイル中にも重複して持たせるようにしている。そのため、容量が極端に大きくなってしまった。

だから、実を言うと配布ファイル2MB中の約75%程度がドキュメントだったりもする。配布するファイルの形式や構造を何とか工夫して、ドキュメントを重複して持たなくてもいいようにできれば、容量はだいぶ削減できるのだが。

2006/12/22

気力

「主筆」第17版を公開しようと思って、ドキュメントを整備してパッケージを作成するまではやってみた。だが、そこから先を進める気力が出ない。

プログラムを作成し終わった後、リリースまでにしなければならない作業には、以下のようなものがある。

  1. ドキュメントの作成

  2. 配布パッケージの作成

  3. Webサイトの更新

  4. リリース


どれも大した作業ではないように思われるが、実際やってみるとそれぞれ相当な工数を要する。

ドキュメントの作成には大変な労力を要することは今更言うまでもない。また、Webサイトの更新も、本質的にはドキュメントの作成と同じであって、それ相当に労力がかかる。

意外と負荷が大きいのはパッケージの作成だ。Solarisの配布パッケージの作成自体はmakeで自動化できる。だが、パッケージの内容を更新するのが大変なのだ。

パッケージの作成に含まれる作業には、配布するリソースファイルやその他のデータの準備、配布先フォルダの決定、パッケージ作成用のPrototypeファイルなどの作成、パッケージ作成用のコマンドの作成、makeファイルの作成、圧縮などがある。

そういったものを一つずつこなしていき、パッケージを作成した後には、正しくパッケージができているか否かテストしなければならない。

特にパッケージのテストは、最も欠かすことができない作業の一つであると同時に、最も手が抜かれやすい作業でもある。プログラミングも含めた開発工程全般から見れば、パッケージの作成に要する期間は短い。そのため何となく軽視しがちだ。だが、この作業に由来するバグは思いの外多いし、また、パッケージの作成で失敗した場合は、リリースされたソフトがまったく動かないとか、そもそもインストールできないとか、そういった致命的なものになりがちで非常に目立つ。だから、パッケージのテストは重要である。

また、パッケージ作成後にパッケージのテストだけを行うというのは、常識的に言っておかしい。普通に考えれば、この時点で総合テストを行うことになるだろう。

つまり、できたばかりのソフトをインストールして、実際に使ってみて、最後にアンインストールするまでを通してテストするのだ。それでようやく完成したと言うことができる。

配布するものができてWebページも作成したら、ようやく一般に公開することができる。だが、ここで気を抜いてはいけない。人間というのはよくしたもので、隙あらば間違いを犯すようにできているらしい。

ファイルの移動やコピーなどといった作業は、普段いくらでもやっているような作業であるはずなのに、なぜかソフトのリリースの時に限って間違えるのだ。リリースしなければならない新しいバージョンのファイルを古い奴で上書きしてしまったり、違うところにおいてしまったり、ファイル名を間違えたり、ありとあらゆる間違いが起こりうる。

だからここでもテストが必要である。つまり、リリースしたファイルが正しくダウンロードできることを確認して、なおかつ、ダウンロードしたファイルの内容が正しいことを確認しなければならない。

そこまでやって、ようやくリリースが完了するのである。

その行程を考えると、作業を進める気力が失せる。そもそもいったい何でこんなことをしているのか。これをやって一体何のメリットがあるのか。

プログラムの作成は、まだそれ自体に面白みがあるからいいようなものだが、この辺の作業はまさに雑用意外の何者でもないし、本当につまらない。

いくら物好きな俺でも嫌気がさす。

2006/12/17

ドキュメントの書き方

主筆」第17版の公開に向けて、ドキュメントの整備を行っている。ところで、このドキュメントはどういった体裁にするのが良いのだろうか。他のマニュアルなどを参照しながら、自分なりに考えてみた。

1.表紙

主筆マニュアルの表紙はSunのマニュアルを模倣している。右上にロゴをおいて、ページの中程に右揃えで表題を書き、下線を引いてある。

格好のいい絵でも描ければいいのだろうが、何分俺にはそういった才能がないので、できる限りシンプルなものにしておいた。

2.目次

今のところ、ページ数はそれ程多くないため、目次の体裁については余り考えていない。とりあえず書いてあるだけだ。

3.分類

さして長くないとはいえ、十数ページに渡ってだらだらと文章で書きつづるわけにも行かないから、ある程度の単位で区切らなければならない。

とりあえず俺は、大分類を「1」「2」「3」……、中分類を「1.1」「1.2」「1.3」……、小分類を「1.1.1」「1.1.2」「1.1.3」……、とする章立ての方式をとっている。

他のマニュアルを見た場合、大分類以外には明示的に番号を振っていない物もあるようだ。また、マニュアルが長くなってきた場合、上記の方式だけでは分類仕切れなくなってくるのだが、その場合にはマニュアル自体を複数に分けたり、あるいは大分類の上にさらに「1」「2」「3」……という区切りを設けるなどして対処している物もあるようだ。

4.大分類

一つの大分類の始まりで改ページするか否か。

大概のマニュアルでは改ページしているようだ。さらに物によっては、大分類の区切りに白紙のページを設けているものもあるようだ。

また、多くのマニュアルでは、大分類の始まり(大分類のタイトルの後)に、その大分類では何の説明をしているのかを、短い文章で記述しているようだ。

大分類のタイトルのページを一個独立で用意するか、あるいはタイトル(と短い説明)の直後に改ページしないで中分類のタイトルを続けるかは、物によるようだ。だが、どうやら長大なマニュアルでは、大分類のタイトルのページを用意する(つまり改ページする)方式を取っている様な気がする。

5.中分類・小分類

中分類・小分類の区切りで改ページすることは余りないようだ。

6.インデント

これが一番難しい。

他のマニュアルを参照すると、下記のような方針でインデントを行っていることが多いようだ。
インデント無し
・大分類のタイトル
インデント1段
・中分類のタイトル
・中分類の本文(中分類に関する説明書きなど)
・小分類のタイトル
・本文
インデント2段
・何らかの特殊な説明書き

本文中に箇条書きが出てくる場合にも、通常は本文と同じレベルのインデントにしているようだ。俺は箇条書きは一段下げたくなるのだが、どうもそれは間違っているようだ。

また、中分類と小分類のタイトルが同じレベルにくるので、インデント以外の方法で区別できるようにしてやる必要がある。文字の大きさを変えるのが一般的だが、それ以外の方式も組み合わせて使われるようだ。多いのは、中分類と小分類のタイトルの右側に何らかのアイコンを配置する方法だ。

これは、文字の大きさの違いだけだと区別が付きにくいからだ。実際、10.5ポイントと12ポイント程度の違いだと、本文中に紛れて区別が付かない。だから、かなりはっきり判るようにしてあげなければならない。


図や表の入れ方にもいろいろと工夫すべき点があるのだろうが、とりあえず以上の工夫ぐらいは取り入れて、多少なりとも読みやすいマニュアルになるよう努力しておこう。

2006/12/09

Jsvzの更新

何となく「主筆」をいじる気がしなかったから、Jsvzを更新してみた。

まず、プレイヤーが攻撃しているときに、敵が攻撃するときの音が再生されない問題を解決しておいた。

Jsvzでは、音声データは細切れにしてリストに格納し、リストの先頭の方から順番に再生していくようにしている。これは、WindowsAPIのwaveOutWriteの制約によるものである。

ある程度の長さの音声データをwaveOutWriteで再生しようとした場合、その再生中のデータは途中で変更することができない。そのため、プレイヤーの攻撃や敵の攻撃、敵の崩壊などといったイベントが複数重なった場合は、あらかじめ音が重なった状態の音声データを合成して、その音声データをwaveOutWriteで再生するようにしてあげなければならない。だから細切れにして再生する必要がある。

ポトが再生されない問題は、再生するデータをリストに追加する処理に原因があった。リストの先頭の方には再生中のデータがあり、その後ろに未再生のデータが並ぶ。そういう状態で音声データを新たに追加しようとしたとき、リストの先頭のデータに対しても、音を重ね合わせる処理を実施していた。

ところが、再生中のデータに対して変更を加えたところで、実際に再生すされる音には変化は生じない。そのため、結果として再生するデータの先頭部分が再生されなくなっていた。また、再生しようとする音が短い場合には、全く再生されなくなっていた。

だから、再生中のデータに対する音の重ね合わせ処理を実施しないようにすることで、確実に音が再生されるようにしておいた。

また、バグ対策以外にもいくつか仕様変更も行った。

一番大きく変更されたのは、敵の攻撃方法だ。今までは、プレイヤーがいる方に向かって一つずつ弾を撃つだけだったが、それを、ある程度まとめて撃つように変更した。また、敵が撃った複数の弾が一点に重なっていても仕方がないので、ある程度ばらけるようにしておいた。

世の中のシューティングゲームというものを思い浮かべるに、どうやら敵は、プレイヤーに対して的確に攻撃を加えてはいけないようだ。敵はプレイヤーがいる方向に向かって、無駄弾を大量に撃ちまくるようにしなければいけないようだ。

どうしてそれが良いのかは行く判らないが、どうやらそういうものらしい。だから俺も、そういう「業界標準」に合わせておくことにした。

そしてそれに合わせて、ステージの構成も変更しておいた。何せ、弾の数を増やしたため難易度が大幅に上がってしまったのだ。だから敵の数を大幅に減らしておくことにした。そもそも、敵の数が多いと処理が重くなる。処理速度維持のためにも、簡略化は必須だった。

だが、これだけの労力をかけて物を作ったとしても、ほとんど報われることはないようだ。vectorでの順位も、順調に下がり続けている。Webサイトのアクセス数には目立った変化はない。

やはり俺には、こういう方面に対する才能は無いのだろうか。

2006/12/03

CDEでの背景画像の設定

CDEで背景画像を設定することを考えてみる。

背景画像は${HOME}/.dt/backdropsに格納したxpm形式のファイルが使用される。だから、背景に設定したい画像を何とかしてXPM形式に変換して、然るべきディレクトリに格納してあげれば、背景として使用することができるようになる。

問題はここで使用するXPM形式である。通常XPM形式は256色であると言われるし、俺も最近までそう思っていた。だが、XPM形式のファイルフォーマットを考えれば、必ずしも256色に限定されないことに気が付いた。

XPM形式のファイルフォーマットは、下記のようになっている。


/* XPM */
static char * 名前[] = {
/* width height ncolors cpp [x_hot y_hot] */
"幅 高さ 色数 1ピクセル当たりの文字数 x位置 y位置",
"カラーテーブル1",
・・・
"カラーテーブルn",
/* pixels */
"画像データ1",
・・・
"画像データn"}


カラーテーブルの部分は、
"文字列 <TAB> c #色",
となっており、画像データの部分は、カラーテーブル中の"文字列"の値を使用して、各ピクセルの色のインデックスを指定するようになっている。

つまり、XPM形式はインデックスカラーを使用するフォーマットであるということだ。だがしかし、1ピクセルを表現するのに使用する"文字列"の長さを長くしてあげれば、必ずしも256色である必要はないということだ。極端なことを言えば、24bitカラーの画像を減色せずに、直接XPM形式に変換することもできるというわけだ。

そういうことで、やってみた。

上でも書いたが、通常XPM形式のファイルを出力するソフトは、256色で出力する仕様になっている。だから俺は、ビットマップファイルを読み込みXPMを出力するプログラムを作ってみた。とは言っても、XPM形式のフォーマットは単純だし、ビットマップ形式のファイルを読み込むプログラムは、すでに作り込んだやつを持っているので、さして時間はかからなかった。(そんなことをしなくとも、GIMPなどでは色数の多いXPMファイルを出力することができるようだが。)

それで、生成したXPMファイルをSolarisで開いてみた。が、いかんせんファイルを開くのに時間がかかってしまい、到底背景画像としては使用に耐えないことが判明した。

まぁ、当然といえば当然の結果だろう。なにせ24bitカラーの画像を直接XPMに変換したのだから、使用されている全ての色をカラーテーブルに登録して、その色を参照するという形になっている。それでは開くのにも時間がかかるというものだ。

ならばということで、色数をある程度落としてからXPM形式に変換してみることにしてみた。だが、256色に変換したのでは今までと全く同じになってしまうので、もっと色数を多めにしてみることにした。

しかし、ちゃんと探したわけではないのだが、中途半端に1024色や4096色などに変換できるツールというのは、余り無いようだ。だからこれも自分で作ることにした。元々作ってあった減色プログラムを転用して、任意の色数に変換できるよう拡張しただけだから、これにもさして時間はかからなかった。

著作権の問題があるため、変換した画像を公開するわけにはいかないのだが、しかし、かなり良い結果が得られた。実用的な時間範囲内で開くことができ、なおかつ256色よりもは画質の高い絵が得られた。

俺の今の環境はFire v250(CPU:Ultra SPARC IIIi 1GHz × 2、メモリ:1GB、G/B:XVR-100)で、1280×1024の画像であれば、1024色や2048色程度なら普通に開くことができる。しかし、それ以上となると厳しいようだ。

また、これは絵の内容にも依るのだろうが、俺が背景に設定したい絵では1024色程度であれば画質的には十分で、4096色だと原画とほぼ区別が付かないようになる。だから最終的には2048色に落として背景として使っておくことにした。

しかし、いくら背景にこだわったところで、一文の価値にもなりはしないのだが、まぁいいだろう。

2006/12/02

スクロールバー

しばらく前に書いたが、今俺は通信制の大学とか言うものをやっている。これ自体にはそれ程意味はないのだろうが、長期的計画に基づく活動の一つとして取り組んでいる。

大学を卒業するには、スクーリングなる方式での単位をいくつか取らなければならないらしい。そしてそれを取るためには、現地に行って授業を受けてこなければならないらしい。そういうことで、12月中に3日ばかり授業を受けに行くことに決めた。

行くと決めたのはいいが、一体どこに行けばいいのか。簡単な地図は与えられてはいるのだが、当日の朝にそれだけを頼りに現地に赴くのはあまりに危険すぎる。道に迷って遅刻でもしたら目も当てられない。そういうことで、今の内に経路と所要時間・必要経費について調べておこうと思い、実地で行ってみた。まぁ行ってみただけで、そのまま何もしないで帰ってきただけなのだが。

しかし、本題はそのことではない。今ここに書くべき事は、行き帰りの電車の中で考えたことだ。

電車の中で、手持ちの本を読み終えてしまい暇になったから、主筆の今後の開発方針について考えてみた。とりあえず、前に書いたように「主筆マネージャ(仮題)」の作ってみるのも良いだろうし、あるいは、通信基盤を整備するのも良いだろう。だが、それをやるには大分時間がかかりそうだ。

もうそろそろ第17版を公開しようかどうか考えている状況下では、そういった大物に手を付けるほどの気力はない。だが、何となく現状のままで第17版とするのは、何か気が引ける。他に何か手を加えられるところはないだろうか?

そんなことを考えていたら、ふっと思い出した。よく考えてみれば、スクロールバーの挙動が奇妙なまま放置されていたのだ。それを早いうちに対処しなければならない。以前。とりあえずそれっぽく動くようにしておいて、細かいところは後で修正しようと思ってずっとなおし忘れていたのだ。

具体的には、スクロールバーのPageUp(PageLeft)とPageDown(PageRight)の挙動だ。

通常スクロールバーは、ツマミの部分以外の所をクリックすると、クリックした方向に1ページ移動するようになっている。ところが、主筆ではそうはなっていない。

Motifのスクロールバーは、どこにどういう操作が加えられたらどういう動きになるのかを全て自前で記述しなければならない。ところが、そのインターフェースがどうにも理解しづらく、理想通りの動きをさせようとすると、標準エラー出力にエラーメッセージが表示されるのだ。

意味不明なメッセージがでるのは気分が悪いため、うまくいかないところは適当にごまかしてしまってお茶を濁してあるのだ。だから微妙に挙動がおかしいことになっている。

明白なバグをいつまでも放置しておくわけにはいかない。このバグは、第17版を公開するまでには修正するようにしよう。

2006/11/28

通信機構の方式

現行の主筆の構造だと、各プロセス間の通信はサーバを経由して行うようになっている。それはつまり、サーバプロセスが通信基盤として働いていると言うことではないだろうか。

サーバプロセスの主たる業務は、同じファイルを同時に編集して、編集内容が失われることがないように調整することである。だが、今まで俺は、各プロセス間の通信を行う専門のモジュールを用意することは考えてこなかった。そのため、試行錯誤した結果としてサーバプロセスが通信基盤としての役割も担うことになってしまった。

だが、通信を司る役目と、主筆間の排他制御とには、本質的な関連性は何もない。であれば、この二つは分割するのが筋であるはずだ。つまり、独立した通信基盤を用意するのが良いのではないか、サーバはその上で動く一つのプロセスにしてしまうのが良いのではないか、ということに思い至った。

まぁ、気が付くのが遅いと言われれば返す言葉はないのだが。

では、独立した通信基盤というものを作るとした場合、それは一体どういう作りにするのが良いのだろうか? つまり、インターフェースをどうするべきなのか?

この通信基盤に乗っかって相互に会話を行うプロセスは、現状では三種類ある。クライアントとサーバと主筆本体だ。この三種類のプロセスは、それぞれまったく違ったパターンで通信を行う。

クライアントは、ユーザから入力された指示をパケットにしてサーバに送りつける。そしてサーバからの応答を受け取る。つまり、一問一答の形式で通信を行い、そしてそのままプロセスを終了してしまう。

サーバはクライアントとはまったく異なり、起動したら常に受信可能な状態で待機しており、誰かから何らかのパケットを受信したら、それに応じた処理を行い結果を返している。また、サーバは明示的な終了の指示が来るまでずっと存在し続ける。

主筆本体はサーバと似ているが、求めるインターフェースが大分異なる。パケットを送信する部分は他の二者と同様なのだが、データの受信はディスクリプタからの読み込みでなければならない。これはXはMotifの仕様によるものであり、曲げるわけにはいかない。

だから、主筆で使用する通信基盤は、それら三種類のプロセスが期待する通信形態を全て満足するような機能を提供しなければならない。

また、プロセスの起動を誰がやるのかという問題もある。サーバや主筆本体の起動は、通信基盤で責任を持ってやるのだろうか。あるいはクライアントやサーバプロセスで行うのだろうか。そもそも、通信基盤のプロセスは誰が起動するのだろうか? クライアントだろうか?

さらに、通信基盤のインスタンスはシステム全体に一つだけ用意するのか、各ユーザごと用意するのか?

通信基盤の構造はどうなるのか? 通信関係を司るプロセスを用意するのか、独立したプロセスは用意せず、各プロセスにリンクされるライブラリとプロトコルだけにするのか?

単純に通信基盤だけ独立させると言っても、決めなければならないことは多数ある。だが、ここを独立させることが出来れば、大分構造を明瞭にすることができるのはないだろうか。一考の価値はあるようだ。

2006/11/25

通信機構

主筆」は、クライアント・サーバ・エディタ本体の三つの部分に分かれている。ユーザはクライアントのコマンドを起動し、クライアントはサーバに指示を出し、サーバがエディタ本体を制御する機構となっている。

クライアント-サーバ間、エディタ-サーバ間の通信には、Solaris特有のdoorを用いている。サーバプロセスがdoorのサーバとなり、クライアント及びエディタ本体はdoorの手続きを呼ぶようにしている。また、サーバからエディタへの通信には名前付きpipeを使用している。

doorはSolaris特有の機能だ。そのため、現状では「主筆」をそのほかのOSに移植することはできない。しかし、市場のパイの大きさを考えれば、SolarisだけではなくLinux等の他のOSでも動作できるようにした方が、「主筆」の利用者数増加のためには良いと思われる。

他のOSに移植するには、door以外の他の通信手段を使用するよう変更しなければならない。何にするのが一番良いのだろうか? 前も似たような検討をしたことがあるような気もするが、暇だからもう一度考えてみよう。

やや古いが、Solaris インターナルという本がある。それによれば、Solarisで利用可能なIPC機構には下記のものがあるらしい。

  1. 共有メモリ

  2. メッセージキュー

  3. door

  4. ソケット

  5. シグナル


また、同期オブジェクトとしてセマフォやnutexを使用することができるようだ。

とりあえず、door以外の共有メモリ・メッセージキュー・ソケット・シグナルについて、利点・欠点について考えてみたいと思う。だがその前に、まずはIPC機構に求められる要件を明らかにする。

  1. 、「主筆」の通信はローカルマシン内に閉じている。NFSやsamba等の存在を考えれば、複数マシン間での排他制御を実現することには意義があるかも知れないが、しかしそれには非常に難しいものがあると思われる。とりあえずはローカルマシン内に限定して考えたい。そうすると、セキュリティ上の観点から、他のホストからは主筆サーバにアクセスできないようにする仕掛けが必要になる。自分で他ホストからのアクセスを禁止する仕掛けを作り込んでも良いが、そもそもの初めからIPC機構に他ホストからの通信を受け付ける機能が備わっていなければ、余計な心配をする必要が無くなる。

  2. 通信の速度はほとんど気にする必要はないようだ。通信に使用されるデータ量は余り多くなく、通信回数も、ユーザの操作に応じて数回発生するという程度なので、よほど遅いとか、あるいは極端にレイテンシが低いとか言うのでなければ問題はない。

  3. サーバは複数プロセスからのデータを受信する。そのため、各プロセスからのデータをひとかたまりで受信できるようになっていると良い。単一のデータストリームとして受信する形式になっていると、各プロセスからのデータを自力で分割するロジックを作り込む必要がある。

  4. サーバへは、複数のプロセスが非同期にデータを送信してくる。だが、サーバの処理はシリアルに行う必要がある。必ずしもシリアル化する必要があるというわけではないのだが、内部で状態管理を行っている都合上、いくつかの処理では排他制御を行う必要がある。そのため、ロジックを単純化するために、全面的に処理要求をシリアライズして実行するようにしている。非同期にデータを受信するIPC機構を用いた場合、サーバ側での排他制御処理を自前で作る必要があって面倒だ。

  5. サーバで処理を行ったら、サーバの呼び出し側(クライアントやエディタ本体)に対して、処理結果を返す必要がある。一方通行のIPC機構を用いた場合、逆方向のコネクションを自前で構築しなければならない。

  6. 当然だが、サーバにとってはイベントの受信は例外的事象ではない。むしろ、主たる業務なのである。そのため、受信用のハンドラ内で行うことのできる処理に制約があるような機構は使用することができない。


以上の要件を基に、各IPC機構について評価を行ってみたいと思う。

項番IPC機構評価/td>
1共有メモリ共有メモリで今回求められる機能を実現するのは難しそうだ。セマフォなどを駆使してうまく排他制御をかければ実現できなくもないだろうが、余りメリットはなさそうだ。そもそも、共有メモリは大量のデータを複数プロセス間で共有する際に真価を発揮するようだが、残念ながら今回はそれ程大量のデータをやりとりする必要性はない。
2メッセージキューメッセージキューを使えば自前で排他制御を行う必要はなくなるようだ。また、データはメッセージという単位で送受信されるため、各プロセスからのデータを自前で切り分ける必要性や、複数プロセスからのデータが入り交じる心配などはないようだ。だが、クライアントやエディタ本体がサーバからのレスポンスと受け取る方式については、別途考える必要性がありそうだ。メッセージキューの機構をそのまま使うと、サーバからのレスポンスを受け取るために待機しているクライアントなどに対して、他のプロセスが不正なメッセージを送りつけることが可能となってしまうのではないだろうか? まぁ、そこまで考える必要はないといえばそれまでなのだが。
3door現在使っているのが、このdoorである。サーバ側で排他制御処理を自前でやらなければならないということ以外には特に問題がないため、今回の目的にもっとも適合していると思い採用した。だが、Solarisに依存することになるのが最大の難点である。
4ソケットここで挙げた五つの中では、おそらく一番自由性が高いのではないかと思われる。少なくとも、今回の目的において必要とされる機能は全て実現することができる。だが、強いて難を挙げるとすれば、他ホストからの通信をブロックする処理を自前で作らなければならないことや、通信処理を記述するのが面倒そうだということがある。
5シグナルシグナルはハンドラ内で実行できる処理に限りがある。また、ハンドラ内でシグナルのマスクだの何だのという処理を自前でやらなくてはならず、さらにはマスクしている間に送信されてきたシグナルは無視されるというのだから、今回のような目的には使えた代物ではないと思われる。そもそも、俺はシグナルは好きではない。


こう考えると、候補としてあげられるのはソケットかメッセージキューであるといえる。中でもメッセージキューが一番目的に適合しているのではないだろうか? サーバ内での排他制御処理を実装するのは、実は結構面倒だったりもするからだ。

あるいはSolaris依存であることを受け入れてdoorを使い続けるか。

まぁ、Linux上でのdoorの実装というのも無いことはないようだし、どうしてもdoorを捨てなければならないというわけではないのだが、しかし、移植の容易性や市場のパイの大きさを考えれば、通信機構を作り直すのも悪くはないと思われる。

今後、気が向いたら手を入れてみることにしよう。

2006/11/24

中断機能の拡張

昨日の考察を基に、エンコード変換処理のプロセスを停止する機能を実装しておいた。難しいのではないかと思ったが、存外困難もなく終わった。

何か処理をやらせたら応答が返ってこなくなり、にっちもさっちもいかなくなって最終的にはプロセスを殺さざるを得なくなる。そういう経験は誰しもあるだろうが、「主筆」ではそんなことは起こらないようにしたい。せっかく自分で作るのだから、細かいところにもこだわって作りたいと思う。

そういうことで、処理がかかるであろうと思われる部分、テキストの検索・置換処理やファイル入出力の処理は、途中でキャンセルできるようにしてある。また、処理にほとんど時間がかからなかった場合、処理中ダイアログが一瞬だけ表示されて、表示された直後に消えるということが起こってしまうが、「主筆」ではそれを防ぐために、処理が開始されてから処理中ダイアログが表示されるまでにある程度の遅延時間を持たせてある。そうすることで、ダイアログの無意味な明滅を防ぐことができる。

だが、それ程思い入れのある中断機能も、現在は検索・置換とファイル入出力にしか実装されていない。一般的にはこの二つが重くなりがちな機能ではあるのだが、これ以外にもコピーや貼り付けも重くなる要因を含んでいる。長大なテキストを選択してクリップボードにコピーしようとしたり、逆に長いテキストを貼り付けようとした場合には、マシンのスペックにもよるが、かなりの時間がかかる可能性がある。

また、プラグインの処理も時間がかかる可能性がある。プラグインの本来の目的は、第三者作成のプログラムを組み込む機能を提供することにある。そのため、プラグインは自分以外の人間により作成されるものと想定しておかなければならない。つまり、プラグインの処理にどれぐらい時間がかかるか、あらかじめ決めてかかるわけにはいかないと言うことだ。(実態としては、全てのプラグインは自分で作っているのだが。)

だから、プラグインを呼び出してしばらくの間応答がなかった場合には、処理中ダイアログを表示するようにしておいた方が良いと思われる。

だが、この機能を闇雲に実装するのもまた考え物である。

まず、昨日書いたとおり、この昨日の実装のためには、UIのスレッドと実処理のスレッドとを分けなければならない。今まで単純安直にシングルスレッドで実装していたものをマルチスレッドにしなければならないのだから、面倒な事この上ない。

スレッド分割には、面倒だという以外にも嫌な問題が腐るほどある。特に嫌なのが、テキストの描画(UIスレッドで行う)と、テキストの編集(実作業を行うスレッドで行う)とが競合することだ。同じものを複数のスレッドで同時に編集しようとすれば、当然の事ながらやばいことになる。

だから「主筆」、スレッドを分割するときに空のドキュメントを作成して、UIのスレッドには生成した空のドキュメントを参照させるようにしている。そうすることで、処理中には画面が真っ白になってしまうという問題はあるが、宇宙の果てまで飛んでいく様なことにはならずに済む。
だが、この処理には時間がかかるという問題がある。

通常であれば、編集対象のドキュメントに対して排他制御を行うということになるのだろうが、ドキュメントクラスが持つメソッドの個数や、その他諸々の状況を考えると、排他制御をかけるのは困難だと判断した。そのため、空のドキュメントの作成という力業に頼るしかなかったのだ。

作業工数やロジックの複雑性の増大、処理速度の低下などを考えると、中断機能を連発するのも危険なのだ。だから、当面は現状のままおいておくものとして、拡張については追々考えていくようにしよう。

2006/11/23

子プロセスの停止

以前、「処理中」ダイアログが表示される待ち時間のうちには、ファイル入出力時に実行されるエンコード変換処理は含まれていないと書いたが、よく見直してみるとそうではなかった。一応、エンコード変換処理に時間がかかった場合にも「処理中」ダイアログは表示されるようになっていた。

しかし、「処理中」ダイアログにある停止ボタンを押下しても、エンコード変換処理が途中で停止されることはない。それは、エンコード変換処理が外部プロセスとして実装されており、主筆は単純にエンコード変換処理が終了するのを待ち合わせるだけだからだ。だから、中断を指示されても、そのことを検知して処理を中断するような作りにはなっていない。

だが、それでは「処理中」ダイアログの意味がない。中断できない中断ボタンならない方がいい。そういうことで、エンコード変換処理を途中で中断させる方法について考えてみたいと思う。

上でも書いたが、エンコード変換処理は別プロセスとして実装されている。また、「主筆」内の入出力処理は別スレッドで処理されるようになっており、「中断」ボタンが押下されたときには、変数「InterruptFlg」に真を設定することで中断指示を伝えるようにしている。つまり、入出力処理を行っているスレッドでは、変数「InterruptFlg」を随時チェックして、真が設定されていたらその時点で処理を中断するようにしているのだ。

ここで、エンコード変換処理のプロセスを停止することを考える。外部プロセスを停止する方法はいろいろあるだろうが、汎用的な方法としてはシグナルを使う方法がある。エンコード変換処理を行うプログラムの仕様を考えると、おそらくシグナルを使うのが最も簡単だろう。

変数「InterruptFlg」に真が設定されたタイミングで、エンコード変換処理プロセスにシグナルを送るためには、「主筆」側に変数の値を監視して然るべき時にシグナルを送信するスレッドが必要となる。

では、どのスレッドで監視処理を行うのか。

今の仕様では、入出力処理中に動いているスレッドは二つ。「処理中」ダイアログを表示しているスレッドと、入出力処理を行っているスレッドだ。

「処理中」ダイアログを表示しているスレッドは、「中断」ボタンが押下されたタイミングで変数「InterruptFlg」に真を設定するのだから、その延長でエンコード変換処理プロセスにシグナルを送出することもできる。だが、せっかくUI用のスレッドと実処理を行うスレッドとを分割したのに、その設計に逆らってUI用スレッドで中断処理をやらせるのは気分が悪い。また、「中断」ボタンはエンコード変換処理中のみならず、その他の処理、たとえばテンポラリファイルへの出力処理やエンコード変換後のテキストを実際に読み込む処理などでも押下される可能性がある。そのため、「中断」ボタンが押下された時にシグナルを送出するようにするのは、何かと難しいのではないかと思う。

だったら、入出力処理を行っているスレッドでシグナルを送出するようにすればいいのか。だが、それも難しいような気がする。現在の実装では、エンコード変換処理中には入出力スレッドはプロセスの処理待ちで停止するようにしている。そのため、変数「InterruptFlg」に真が設定されたか否かの監視を行うことができない。当然、シグナルを送出することもできない。

入出力処理を行っているスレッドでシグナルを送出するためには、単純にプロセスの終了を待ち合わせるのではなく、スピンウェイトを行い、その中で子プロセスと変数「InterruptFlg」の監視を行うようにしなければならない。

無論、スレッドは全力でスピンウェイトしなければならない理由はないので、おそらく100ms程度の待ちを入れることになるのだろうが、それでもスピンウェイトに対しては抵抗を感じざるを得ない。まぁ、入出力スレッドで監視を行う場合には、スピンウェイトする以外に選択肢はないし、おそらく実用上も問題はないのだろうが。

それと、もう一つ方法がある。監視用のスレッドを別に一つ作るという方法だ。プロセス生成時に監視用のスレッドを作り、そのスレッドでスピンウェイトを行い変数「InterruptFlg」の監視とシグナルの送出を行うのだ。

だが、この方法でも結局スピンウェイトからは逃れられないし、おまけに新たにスレッドを作らなければならないため、処理が複雑になるというデメリットがある。入出力用スレッドでの監視に比べてメリットが少ない。

そういうことで、エンコード変換処理プロセスを中断させるには、入出力処理用スレッドで監視を行うのが一番いいのではないかと思う。

残る問題は、エンコード変換処理プロセスの実装だ。シグナルを受信したら、何か処理を行わなければならないのだろうか?

プロセスが終了すれば開いたファイルや確保したメモリの後始末はOSが全部やってくれるし、ファイルの出力が完了せず中途半端な状態になるという問題はあるが、これはそもそも中断するのだから当然のことだし、特に何か必要なことがあるとも思えない。

強いて問題としてあげるのであれば、OSの機能でプロセスを殺すことを通常処理の一部に組み入れることに対する抵抗感だけだ。

この気持ち悪さに目をつぶれば、少なくともユーザから見た仕様を本来あるべき姿にする事ができるだろう。

2006/11/19

次の機能

主筆」のHTML対応を終えた。ついでに、構文強調表示に使用するキーワードを外部のファイルから読み込むようにも変更しておいた。

次の何の機能に手を着けるのがいいだろうか?

行折り返しやマネージャー機能など、いろいろと思いつきはするが、どれも大変そうだ。第16版を公開してからだいぶ経つから、そろそろ第17版として公開しても悪くはないのではないだろうか。そんな気がしてきた。

いつ新バージョンを公開するとか、どれぐらいの規模の改修が行われたらバージョンをあげるとか、そういった決め事は一切ないのだし、自分の好きなときに公開すればいいだけなのだが、それだから逆にいつ公開するのかが迷う。

第16版から比較して、あまり機能が向上しているとも思えないが、まぁいいか。そろそろ第17版を公開する事にしよう。

2006/11/17

高速化

何日ぶりかに「主筆」の開発に戻ることにした。

とりあえずは、途中で放置していたHTML対応を終了させておいた。構文強調表示のロジックは作ってあったのだが、強調表示を行うキーワードの一覧の作成が滞っていたのだ。だから、MSDNからHTMLのキーワードとおぼしきものをリストアップして、使っておくことにした。

その作業が終了して動作を確認している時に気が付いたのだが、なぜか処理速度が遅い。それ程大した量でもないファイルを読み込んだだけで、構文強調表示処理に結構時間がかかる。

なぜだろうかと思って間tなんいしあべてみると、すぐに原因が分かった。

キーワードのリストは、今後の検索に備えて並び替える処理を行っているのだが、その並び替えの処理を、キーワードを検索するたびに行っていたのだ。

この負荷の重い処理をやりたくないがためだけに、構文強調表示処理を行うクラスのインスタンスを使い回すようにしたり、メンバをstaticにしたりだのといろいろと小賢しいことをやっているのに、最後の最後に検索を行う関数で、キーワードのリストを保持するクラスのインスタンスを生成して検索処理をやっている。

我ながらあきれるほど馬鹿だとしか言いようがない。しかも、よく見てみれば、同じ事をCOBOLの構文強調表示でもやっていた。

とりあえずそれを修正したら、かなり高速化された。

2006/11/13

ディスプレイ

今朝起きてPCの電源を入れたら、ディスプレイが写らなかった。

ディスプレイの設定やケーブルの接続、PCの操作(電源ボタンを押すだけだが)など、いろいろと思い当たる節をいじってみたが、どうにも写らない。

ディスプレイ関係で何か壊れる原因となるようなことをやったのだろうかと自問してみると、どうにも思い当たる節は一つしかない。

おとといリリースした糞ゲームJsvzのテストをやるために、いろいろとディスプレイの設定を変えて動作させてみたから、壊れたとしたらそれしかないだろう。

ということは、おそらく故障の原因はソフト的なものだろうから、その設定をいじってやれば元に戻る可能性が高い。だが、どうやっていじるのだろうか?

現在のPCの設定では、外部からアクセスして操作できるような方図は用意していない。telnetも有効にはしていない。正直、お手上げ状態だ。

そこまで考えたときに気がついた。

よく見てみると、BIOSの画面すら表示されていない。ソフト的な故障であれば、BIOSの画面は表示されてしかるべきだ。そうすれば、せめてセーフモードで起動することぐらいはできるだろうし、セーフモードでも起動すればディスプレイの設定ぐらいなら何とでもなる。

だが、BIOSの画面すら表示されないのであれば、故障の原因はハード的なものに他ならないのだろう。では何が原因か。

最近あった影響を与えそうなイベントといえば、やはりグラフィックボードの設定を変更したことだ。だから、それが原因でグラフィックボードがいかれたのだろうか?

そう考えると納得がいく。何せ今使っているPCは6年前に買ったものであり、グラフィックボードは5年前のものだ。さすがにそろそろ壊れてもおかしくない。

もうPCの買い換え時だろうか。仕方がない、とりあえず今日のところはBlade100のやつで用を足しておくことにしようか。

そう思って、配線をつなぎ変えてBlade100の電源を入れてみたが、それでもディスプレイが写らなかった。

どうやら、犯人はPCのグラフィックボードではなかったようだ。これは単純にPCが壊れただけのようだ。

だが、それは最悪の結論ともいえる。半年ほど前にもディスプレイ損壊の危機が訪れたが、そのとき以来状況は何も変化していないから、ディスプレイに故障されると俺の生活に非常に多大な影響を及ぼすことになる。

今使用しているディスプレイは、俺の日常生活においてはクリティカルな機器の一つなのだ。

マジでどうしようか。どうやら、写らないのはPCの映像だけで、ビデオなど映像はちゃんと映っているから、どうにかすればPCの映像をテレビ入力に接続することもできなくはないだろうが、そんな運用では長期間の使用には耐えそうにもない。

どうにかして写るようにすることはできないだろうか。そう思っていろいろといじっていたら、ふとあることに思い至った。

昨日、電源系統をいくつかつなぎ変えたが、そのときディスプレイ切り替え機の電源をつないだだろうか?

とりあえず、切り替え機の本体に目をやると、スイッチの状態を表示するランプはちゃんと点灯している。だが、なんだかいつもより暗いような気がするが、しかし電源はきているようだ。

とりあえずだめ元で電源を調べてみると、コードはちぇんとテーブルタップにつながってはいるのだが、そのテーブルタップについているスイッチが入っていなかった。

結局、これが原因だった。

電源が入っていなくてもスイッチのランプが点灯していた原因はよくわからないが、おそらくPCからの映像出力の信号から電源を得ていたのだろう。それで薄暗く光っていたのだろう。というか、それしか考えられない。紛らわしいことだ。

とりあえず、グラフィックボードとディスプレイは冤罪だった。まぁ、よかったといえばそれまでなのだが、しかし、朝から心臓に悪い出来事だった。

2006/11/11

Vectorに投稿

ここ一月ばかりかけて作った糞ゲームをVectorに投稿しておいた。これで多少はアクセス数が増えるだろうか?

一応、曲がりなりにも撒き餌を撒いたのだから、その受け皿となるWebページの方も用意してやらなければならないだろう。

まったく、面倒なことだ。

2006/11/04

微調整

工数をつぎ込んだお陰で、とりあえずゲームとして成立するだけの機能はそろった。

ステージがあって、その中をプレイヤが移動することができて、敵がいて、敵はプレイヤに向かって攻撃してきて、プレイヤは敵に攻撃してそれを倒すことができる。また、敵や敵の攻撃に触れるとゲームが終了し、あるいは、穴に落ちた場合もゲームが終了する。ステージの最後にはボスキャラがいて、そいつを倒すとゲームが終了する。

一般的に、ゲームオーバーになった場合は素っ気ない終わり方で、ゲームをクリアした場合には豪勢なエンディングを見せるのだろうが、実装するのは面倒だから、とりあえずクリアしたと言うことが分ける程度のエンディングにしておいた。というか、単に画面が暗転するだけだが。

残作業としては、音を出す、細かい微調整、ゲームそのものを出す、配布できるようにする、等が残っている。今週中には公開できるようにするつもりだったが、おそらく無理だろう。

2006/10/28

ゲーム制作(続き)

Vectorのレビューが付いているやつをチラチラとみてみると、どうやら見てくれが派手なもののが選択されているような印象を受ける。あるいは、単に俺が今作っているやつと比較すると派手に見えると言うだけのことなのかも知れない。

いずれにせよ、今の段階で外に出したら、他に埋没して無名の糞ゲームで終わってしまう。これでは本来の目的であるところの、webサイトのアクセス数向上に結びつかなくなってしまう。

アクセス数を増やすためには、何が何でも目立たなくてはいけない。ゲーム的なおもしろさは問題ではない。とにかく目立つことだ。そしてその為には、エフェクトが派手である方が良いらしい。

意味なんて無くたっても良い。とにかく派手でありさえすればそれでいいのだ。

だが、グラデーションの効いた派手なエフェクトというのはどうやったらいいのだろうか? そもそも、俺が使っているPCは性能が低いため、余り手の込んだ難しいことはできない。動きがガクガクになってゲームどころではなくなってしまう。

そう考えると、だんだん面倒になってきた。主筆の開発もいつまでも止めておきたくないし。

なんか、手っ取り早く派手にするための、良い方法はないものだろうか?

2006/10/22

ゲーム制作の続き

先週に引き続いて、クソゲームを作り続けている。とりあえず、今のところはまだ飽きていない。



画面を見る限りでは、先週の時点からそう大きく変わったようには見えない。しかし、敵を表示する機能、穴に落ちたときや敵に触れたときにゲームオーバーになる機能を実装しておいた。また、画面の向きを変える機能も付けておいた。

初めは向きを自由自在に変えられるようにする予定だった。だが、そうすると操作がもの凄く難しくなってしまい、ほとんどゲームとして成立しなくなってしまうから、途中でこの機能は切り落とすことにした。
しかし、それではやはり面白くないと言うことで、少し方式を変えて実装することにしておいた。

後はとりあえず、弾を撃ち敵を倒す機能、敵が弾を撃ち攻撃してくる機能、ゴールしてゲームを終了する機能を実装する必要がある。

まぁ、余りこれには労力をかけるつもりはないから、適当にやって早いうちに片付けてしまおう。

2006/10/15

浮気

ちまたの噂によれば、ゲームを作って公開すればアクセス数を稼ぐことができるらしい。やはり、絶対的なユーザー数の差がものを言うのだろう。

あるいは、客層の違いだろうか。確かにアクセス解析を見ていると、アクセス元の多くが各種のコンピュータ関連企業であることが解る。

つまり、そういったユーザは仕事中にアクセスしてきているのであり、余分なページを見て回ったり、広告をクリックしたりする事は少ないのだろう。

そういうことで、アクセス数増加と客層の変化を付けるために、少しばかりゲームでも作って公開してみることにした。それに、アクセス数の増加だけでなく、頭の悪い連中に「ゲームの一つも作れないのか」と罵られるのがしゃくに障るから、それを封じるためにもここで一発かましておいた方が良いかと思って、作ってみることにした。

作る目的が上記のような理由であるため、それ程凝るつもりもない。とりあえず見た目が派手で、ゲームの形式が整っていれば、それでいい。

だから、何となく簡単に作れそうなシューティングゲームにしておくことにした。ついでに、2Dだと見てくれが悪いから3Dにしておくことにした。

それで、適当に先週の日曜当たりから作業を進めて、今は画面中をプレイヤが移動できるというところまではできた。




上の画面からでは解らないが、一人称視点である。プレイヤは画面中をぴょんぴょんと跳びはねながら移動する。

後は、ゲームオーバー・ゴールの処理と、敵や弾などを作り込んでやればいい。そうすればとりあえず形だけは整うから、Vectorか何かに登録することができるようになるだろう。

2006/10/08

カーソルの挙動

主筆」のカーソルの挙動を変更してみた。

今までの状態でも、大体その他のエディタと同じ様な動きをするように作ってはあったのだが、一部業界標準とは異なる動きをする部分があったからそれを修正しておいた。

具体的な内容は下記の通り。


  1. 一番末尾の行で下矢印キーを押下した場合に、カーソルをテキストの末尾に移動するようにした

  2. テキストの先頭行で上矢印キーを押下した場合に、カーソルをテキストの先頭に移動するようにした

  3. 矢印キーが押下されたがカーソルが移動できない場合(たとえば、テキストの先頭で上や左矢印が押下された場合)で、かつ、範囲選択されており、かつ、矢印キーが押下されたときにShiftが押下されていなかった場合には、範囲選択を解除するようにした



非常に細かいところではあるが、使っていて気になったので修正した。

また、第16版から、カーソル位置を記憶する機能を実装したが、その機能を停止する機能も付けておいた。まぁ、一般的にこの機能を停止するという需要があるとも思えないが、ありとあらゆる機能は停止することができるようにするべきである、というのは俺の信念でもあるので、とりあえず実装しておいた。さしたる手間がかかることでもないし。

2006/10/07

主筆のHTML対応

水曜日は仕事が速く終わったから、「主筆」をいじってHTMLの構文強調表示に対応しておいた。

ところで、こうやって単なる事実を書き連ねてもあまり面白みがないから、中でどうやっているのかを書いてみるのもいいかもしれない。

まずは、HTMLのソースが与えられた場合に、各文字の色をどうやって決定するかについて考えてみる。

まず大前提として、テキストは先頭から順番に処理していかなければならない。当然のことのように思えるかもしれないが、これは単に当然と言うだけではない。文法の制約上必ず必要なことなのである。

HTMLに限らず、テキストのとある一部分だけを見て、それが文字列(ダブルクォーテーションなどにより囲まれた文字列)の一部なのか、キーワードの一部なのか、それ以外の文字なのか、を判断することはできない。判断するためには、その前後の文字も参照する必要がある。また、指定された文字がダブルクォーテーションにより囲まれた文字列なのか、HTMLの場合であればタグの中なのか外なのかを判断するためには、その前の文字がどのようになっているのかを知ることが重要である。たとえばHTMLであれば、指定された文字の前に<があれば、そこはタグの中であるといえるが、そうでない場合はタグの外と言うことになる。

よって、テキストは必ず先頭から順番に読み込んで処理していかなければならない。

話を戻すが、最初にHTMLのソースが与えられたときの色決定処理だが、大まかに書けば下記のようになる。

  1. <が出現するまではタグの外であるため、全部黒にする。

  2. <が出現して、次に>が出現するまでは、タグの中であるため全部青くする。

  3. ただし、<!--が出現した場合はコメントであるため、-->が出現するまでを全部緑にする。

  4. タグの中でダブルクォーテーションもしくはシングルクォーテーションが出現した場合は、そこから対応する記号が出現するまでを文字列として、暗い赤にする。

  5. タグのなかにある単語(非英数字で区切られる)が、キーワードとして登録された単語であれば、それを赤くする。



ここまでは特に難しいことはない。だが問題は、テキストの一部が変更された場合にどうすればいいか、ということだ。

たとえば、テキスト中に下記のような記述があったものとする。

あいうえお<!-かきくけこ

上記のルールに従えば、「かきくけこ」の部分はタグ内の文字列であるものとして、青く描画されることになる。だが、もしユーザが「か」の前に「-」を入力したらどうなるだろうか。

その場合、「かきくけこ」の部分はコメントとなり緑色にする必要がある。

ここで気にしなければならないのは、「-」が入力されたことでコメントの開始(<--)が形成された、ということを判断するためには、文字の入力位置よりも前の方を見てみなければ分からないと言うことだ。

つまり、テキストの変更時に構文強調表示を行うためには、文字の入力位置よりもある程度前の方に遡って、そこから色を更新しなければならないと言うことだ。

では、どれぐらい前に遡ればいいのだろうか。単純に考えれば、常にテキストの先頭から更新すればいいと言うことになるのだが、それはあまりにも非効率というものである。

だから俺は、下記のようなルールで更新開始位置を決定することにした。(なお、「編集開始位置」というのは、テキストが変更された範囲の開始位置のことを言う。「編集終了位置」は同様に、テキストが変更された位置の終端のことをいう。)


  1. 編集開始位置の直前の文字がタグ外の文字列であれば、一文字だけ遡る。

  2. 編集開始位置の直前の文字がタグ内の文字列ないしキーワードであれば、英数字以外の文字もしくはタグ外の文字まで遡る。

  3. 編集開始位置の直前の文字がコメント開始記号であれば、コメント開始記号以外の文字まで遡る。

  4. 編集開始位置の直前の文字がコメント終端記号であれば、コメント終端記号以外の文字まで遡る。

  5. 編集開始位置の直前の文字がコメントないし文字列であれば、一文字だけ遡る。



HTMLの場合は、エスケープシーケンスにより文字列中にダブルクォーテーションやシングルクォーテーションを含めると言うことができないため、文字列に対する扱いが単純になる。もしこれがCやC++であれば、文字列中の文字が変更された場合の処理はもっと複雑になる(たとえば、「\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"」の末尾にある「"」は文字列の終端を示すダブルクォーテーションなのだろうか、それともエスケープされた文字なのだろうか)。

いずれにせよ、上記のようなルールにより更新開始位置を決定することで、更新範囲を最小限にとどめることができる。

そして次は、更新をどこまで実施すればいいのかを考える必要がある。先と同様、単純に考えればテキストの末尾まで更新してしまえばいいのだが、それはあまりにも非効率である。

だからおれは、色の更新を下記の条件が成立するところまで、と決めた。


  1. 編集終了位置を越えていること。

  2. 更新前後で文字の色(文字の種類)が変わらないこと。



これにより、色の更新を必要最小限の範囲にとどめることができるはずである。

まぁ、簡単に書けば上記のようなアルゴリズムで構文強調表示をおこなってはいるのだが、実際にはもっと生々しい問題がたくさんある。正確なところはソースコードを参照して欲しい。

2006/10/02

HTML対応

引数の半角空白を含む値を指定することができない問題は、結局、起動用スクリプト内で「主筆クライアント」を起動するコマンドに「"$@"」と指定してやればいいことが判った。

全く、何だってこんな意味不明な記号を駆使するのか。「$@」という記号からは、与えられた引数を全て展開するという機能を全く予測することができないではないか。こういった、恣意的な記号の割り付けや、マジックナンバーを駆使するような仕様は、ユーザビリティという観点からすれば最悪といわざるを得ない。

だがまぁ、shはユーザビリティがどうのといわれる以前から存在するものだし、今更文句いっても始まらないのだが。

また、上記以外に、ファイル名に半角空白が含まれていると正常に保存・読み込みを行うことができない問題にも対処しておいた。結局原因は、エンコード変換用のプログラムを起動する際にsystem関数を使っていたことだった。「主筆」では、子プロセス起動用の「CProcStart」というクラスを作り込んである。。それを使えば、引数中の半角空白だのなんだのを気にすることなくプロセスを起動することができる。なのに、何で初めからそれを使わないのか。我ながら、頭が悪いといわざるを得ない。とりあえず、修正だけはしておいた。

そして、今現在は構文強調表示機能を拡張してHTMLに対応できるようにしている。いろいろあって、HTMLのソースに対する色づけを行うプログラムは作ってあったから、それを転用すれば簡単にできるかと思ったのだが、そうでもないようだ。HTMLモードにして文字を入力すると、その瞬間にプロセスが落ちる。

まぁ、簡単には行くまいとは思っていたことだし、まぁいいか。ゆっくりデバッグするまでのことだ。

2006/09/30

シェルスクリプト

環境変数の引継処理を実装しておいた。これでとりあえずは、不可思議な挙動を防ぐことができる。

また、以前考察していた、「主筆」起動時に任意の引数を指定する機能も実装した。だが、ここで一つ問題があることに気がついた。

syuhituコマンドの引数で、たとえば下記のようなものを指定するものとする。

syuhitu -f "abc cde efg" -s

要は「abc cde efg」と言う名前のファイルをスタンドアロンモードで開きたい、と言うことなのだが、これは失敗する。

なぜかというと、上記のような引数を指定すると、主筆クライアントには「-f」「abc」「cde」「efg」「-s」の五つが与えられたように見え、引数の解釈に失敗するのだ。

なぜこんな情けないことになるのか。しばらく悩んだ末に、原因がシェルスクリプトでの引数の指定方法が悪いことに気がついた。

「syuhitu」と言うコマンドは、シェルスクリプトである。その中で必要な環境変数の設定を行い、最後に主筆クライアント「TaEditClient」を起動している。そして、そのときに使用するコマンドは、下記のようになっている。

${SYUHITU_CLIENT} $*

だが、これではいけないらしい。こうすると、$*の部分が「-f abc cde efg -s」に展開されてしまうのだ。

だから、どうすればいいのかと思っていろいろと検索してみたら、どうやら「$@」を使えばいいらしいと言う情報を見つけて、それを実地で試してみたが、うまくいかなかった。「$*」の時と同じ現象が発生する。とりあえず、

${SYUHITU_CLIENT} "$1" "$2" "$3"

としておけば、起動させることはできるのだが、しかし、引数の数に過不足がある場合は失敗する。いったいどうするのが一番いいのだろうか。

また、おそらく似たような理由からなのだろうが、ファイル名に半角空白を含むファイルは、エンコード変換に失敗するため、開くことも保存することもできない。それよりももっとまずいのは、指定されたファイル名の最初の単語(初めてでてくる半角空白よりも左側にある文字列)に一致するファイルが存在した場合、そのファイルに対して入出力を行ってしまう。

分かり難いが、要は既存の全然別のファイルを破壊してしまう可能性があると言うことだ。

新機能を実装しようと考えているのに、それを阻むかのごとくにバグがにじみ出てくる。なんか疲れた。

2006/09/26

環境変数の引き継ぎとHTML対応

いろいろいじって、以前問題として取り上げた環境変数の引き継ぎ処理を実装しておいた。これでとりあえず、コマンドを叩いたときの環境で主筆を起動することができるようになった。

また、引数で主筆起動時に任意の文字列を指定することができるような機能も実装している最中ではあるのだが、これについては多少ややこしい問題が発生している。

まず、現在「主筆」はシェルスクリプト経由で起動するようになっている。そのとき、主筆クライアント(TaEditClientという名前)のプログラムを起動するときの引数には、「$*」を指定している。こうすることで、シェルスクリプトに与えられた引数を全部そのままの形で指定することができるようになる、と思っていた。

だが、そうでもなかったらしい。シェルスクリプトの起動時に、半角空白を含む文字列をダブルクォーテーションやシングルクォーテーションで括ったものを指定すると、主筆クライアントにはそれらの文字列が空白の部分で区切られた状態で渡されてしまう。

当然といえば当然であり、対処法としてはシェルスクリプトをいじればいいのだが、それが面倒くさい。というより、俺はシェルスクリプトが嫌いだ。嫌な思い出しかない。

まぁ、これについては、気が向いたら直すか、あるいは機能を諦めるか、どちらかになるだろう。

また、上記以外にも、構文強調表示機能の拡張に取り組んでいる。現在のところはHTMLに対応しようとして作業を進めている。

やはり、どうしてもHTML等のマークアップ言語には対応しておいた方がいいような気がする。使用用途としてはやはり無視できない勢力として存在するように思うのだ。まぁ、余りご大層なことをやるつもりもないし、適当にそれっぽくなってればいいか。

2006/09/22

配本

通信制の大学という物をやってみることにした。それで、かなり前から入学手続きをしていたのだが、ようやく教科書一式が送り届けられてきた。

段ボール一箱分のツマラン本が大量に送られてきたわけだが、こいつらを最低でも一年間かけてやっつけてやらねばならない。まぁ、おそらく一年では片づかないのではないかとも思われるのだが。

とりあえず、中の一冊「簿記原理」とかいうやつをぱらぱらとめくってみるに、内容はそれ程難しいものでもなさそうだ。というかまぁ、簿記は高校の頃に嫌という程やらされたから、いまさらなんと言うことでもないだけなのだが。

しかし、本の内容が簡単でも、こいつを片付けるにはいろいろとやらねばならぬ事があるようだ。まずは、本の最後に挟まっているリポートとか言う奴を書いて然るべきところに送る必要がある。でもって、最後にどこかの試験会場で行われる単位認定試験みたいな奴を受けに行かなければならない。

何がいやかと言えば、リポートの提出だの単位認定試験の申し込みだのといった奴には、申込用紙やはがきの提出期間が決められていると言うことだ。別に、科目自体はどれぐらい時間をかけてやったってもいい。だが、試験を受けるには、前の月の何日から何日までに申し込まなければならない、というような決まりがあるのだ。

これがうざい。

俺に言わせれば、各科目で勉強しなければならないことよりも、単位を取得しれ卒業するためにやらなければならない事務手続きの方が難しい。このシステムを理解するのだ最大の勉強なのではないだろうか。

しかも、試験だのスクーリングだのの日程にはかなりの制約があるから、相当綿密に日程を計画しておかなければならないようだ。プロジェクトマネジメントについても勉強しろと言うことか。

まったく、面倒なことこの上ない。

2006/09/21

潜在バグ

結局、昨日のコメントを修正したら云々の件は、ゼロによる除算が発生する潜在バグであることが判明した。ではなぜ今まで動いていたのか、その辺りはよく分からないのだが。

いずれにせよ、プログラムは修正して、サンプルとして公開しておいた。まぁ、何の意味もないのだが。誰も見ないだろうしなぁ。

話は変わるが、減色する際、いくつかの状況においては画質を落としてもばれない、あるいは分かりにくい状況というのがあるのではないかと思う。例えば、色の変化が激しいところは、多少画質が劣化しても分かりにくい。JPEGでの情報量の削減法と同じだ。

また、一般論として、画像では真ん中辺りに意味的に中心をなす部分が来ることが多く、隅の方は余り重要ではない事が多い。だから、中心付近のピクセル(つまり色)を優先して、隅の方は画質を落とす、という方法も考えられる。

更に、RGB値の上では同じ大きさの差しかなかったとしても、明るさが違う場合よりも色相が違う場合の方が、変化が大きく見えるように思う。

以上のことを元にプログラムを作り直せば、もう少し綺麗に減色できるようになるのではないだろうか。もっとも、実写の写真などであれば、現状でもほとんど元の画像と区別が付かない程度にはできるのだが。

2006/09/20

コメント

減色アルゴリズムのページで、サンプルのプログラムぐらい公開してやろうと思って、試行錯誤して作り上げた汚いプログラムのコメントを書き直したら、ものが動かなくなった。

何がいけないのか。

コンパイラがおかしいのでないとしたら、多分自分でどこかを書き換えてしまったのが原因なのだろうが、なにせプログラム自体に手を加えた記憶がないのだから、どこをどう変更してしまったのか、見当も付かない。

いちいちデバッグするのも面倒だし。

世の中、こういう事もあるから、ドキュメントの履歴管理はしっかりやった方がいいというものだ。

2006/09/19

メッセージ日本語化

昨日の考察の通り、とりあえずすべき事は環境変数の引き継ぎを行う機能の実装なのだが、昨日は作業中になってきたメッセージの日本語化を先に片付けておいた。

メッセージの日本語化というよりもは、表示するメッセージを外部ファイルから入力するようにするというのが正確な表現なのだが。

そこで気が付いたのだが、ワイドバイト文字列(wchar_tの配列。これは必ずしもUnicodeだとは限らないようだ)を標準出力から表示する時、fwprintfで書式指定に%Sを指定しても、日本語の文字列が表示されないようだ。

理由はよく分からないが、半角の文字なら正しく表示されるのに、全角文字はどうやっても表示できない。何がいけないのだろうか。

まぁ、とりあえず、マルチバイト文字列に変換してから表示すればいいまでの話なのだが、面倒なことこの上ない。ライブラリでやってくれるはずのことをなぜ自分でやらなければならないのか。

そういえば、この問題はSunのコンパイラのみならず、BorlandのC++ Conpiler 5.5.1でも発生したような気がする。

printf系の関数で、ワイドバイト文字列の全角文字の出力は一般的にできないものなのだろうか?

2006/09/18

環境変数の引き継ぎ

重大なバグに気が付いた。

日本語(ja)ロケールでログインして「主筆」を起動した後に、一旦ログアウトしてから、英語(C)ロケールでログインし直して「主筆」を起動しようとしても、起動しない。

また、別の端末からTelnetでログインした状態で「主筆」を起動すると、Xの画面に主筆が起動してしまう。

初めは、ログインし直した事が、Xのコネクションに何らかの影響を与えて、そのせいでおかしくなるのかと思ったが、どうもそうではないらしい。単純に、telnetの件も含めて、いろいろと考慮するに、どうやら主筆クライアントが起動された時の環境変数と、主筆サーバが起動されたときの環境変数が異なることが原因らしい。

つまり、前者の問題が発生する原因はこういう事らしい。

  1. 主筆クライアントおよびXのロケールは"C"である。

  2. 主筆サーバのロケールは、起動されたときの"ja"のまま。

  3. 主筆は主筆サーバから起動されるため、ロケールは"ja"になる。

  4. 結果として、主筆とXのロケールに整合性が取れず、起動に失敗する。


いろいろ試したが、どうやらXが"ja"の時に「主筆」を"C"で起動するのは問題ないようだが、Xが"C"の時に「主筆」を"ja"で起動する事はできないようだ。その原因についてはまだ完全には調査し切れていないが、どうやらフォントの問題が絡んでいるらしい。

telnetでの問題の原因は、こういう事らしい。

  1. X上で主筆が使用されると、そのタイミングで主筆サーバが起動される。また、そのときDISPLAY環境変数には":0.0"が設定されている。

  2. telnet上で主筆クライアントを起動する。そのときには、DISPLAY環境変数には値は設定されていない。

  3. 主筆クライアントは、主筆サーバの手続きを呼び出して、主筆を起動させる。

  4. 主筆が起動されるときの環境変数は主筆サーバのものを引き継ぐため、DISPLAY環境変数には":0.0"が設定されることになる。

  5. 結果として、主筆の画面はX上に現れることになる。


以上の事から演繹すると、同じユーザアカウントで、複数のX端末から同時にログインしていると、「主筆」は一番初めに起動したときの画面でしか使用できなくなってしまう、と考えられる。もっとも、これはまだ試したことがないから、本当にそうなるのかどうかは分からないが、多分そうだろう。

前に、利便性向上のために、クライアントの環境変数とサーバの環境変数を一致させた方がいいと書いたが、どうもそれだけでは済まないようだ。この問題への対処は、常識的機能の実現のためには必須のものであるらしい。

そういうことで、まずはこれに取り組むことにしよう。

2006/09/17

他のもの

別に「主筆」の第17版の開発を進めなければならない理由はない。たまには何か他のものを作ってみるのもいいかも知れない。そう、さしあたって自分が欲しいと思っている、プロジェクト管理を行うソフトを作ってみるのもいいのではないだろうか。

そう思いはしたものの、やはり面倒くさい。そんなものを作っている余裕があるのなら、その工数を「主筆」に振り向けるべきであるような気がしてきた。

MS Projectでも買ってこようか・・・

2006/09/13

今後の方向性

「主筆」第16版を公開してから1週間ほど経過したが、とりあえずすることもないから、第17版に向けていじり始めた。

いじるとは言っても、何をどうするのかという方向性が決まらないと、いじりようがないから、ちょっと考えてみた。

まず言えるのが、文字コードの自動認識機能の実装だ。エンコード変換機能を実装したとはいえ、ファイル入力時にユーザに指定してもらわなくては読み込みもままならないというのでは中途半端すぎる。

それと、「主筆」の管理用ツールを作るのも面白いかも知れない。「主筆」のインスタンスは、全てサーバ用プロセスによって管理されている。だから、そのサーバ用プロセスと通信して、「主筆」の状況を表示したり、各種の操作を行ったりすることができる、GUI付きのソフトを作成することができる。他には余り見られない機能であると考えられるし、面白いのではないだろうか。

「主筆」本体の話ではないが、CDEの設定で、サーバの再起動やファイルの保存などを行わせるためのアイコンを、フロントパネルに登録するようにしてもいいかも知れない。また、CDEの環境設定を行う際に、何を有効にして何を無効にするかを選択できるようにする機能も必要だろう。そろそろ機能が肥大化してきたから、強制的に全ての機能を有効化するという現在の実装は、野蛮なものになりつつあるように思う。

細かい話だが、クライアント用プロセスやサーバ用プロセスで表示されるエラーメッセージの日本語化を図る必要がある。現状では、クライアントやサーバが表示するエラーメッセージは、全て英語である。メッセージ自体をプログラム内部に固定の文字列で保持しているため、致し方がないのだ。だが、これは俺の信念に反する。「日本語対応」と言ったら、表示される全てのメニュー・文字列・メッセージは等は日本語でなければならない。だから、中で固定で持っている文字列を、外部ファイルから読み込むように変更してやらなければならない。

ファイルの入出力に時間がかかる場合は「停止ボタン」が表示されるようになっている。だが、今の実装では、エンコード変換やテンポラリのファイルへの待避処理を中断することができないようになっている。”時間がかかる”の時間の内に、それらの処理時間が含まれていないのだ。その辺をきっちりとつめる必要がある。もっとも、エンコード変換は別プロセスに分割しているから、途中で停止するというのは結構面倒な問題なのだが。

主筆の起動時に、リソースの設定を個別に指定できるようにしたい。Motifの機能で、起動時の引数でリソースを指定するというものがあるのだが、サーバ経由で起動するようになってからは、その機能が使えなくなってしまった。次期バージョンではその機能を復活させたいと思う。

同様に、起動時の環境変数も「主筆」に引き継がれるようにしたい。現在の実装では、「主筆」起動時に使用される環境変数はサーバの起動時での環境変数であって、コマンドを叩いたときの環境変数ではない。だが、それでは使う側からすると、かなり不思議な振る舞いを示すことがある。だから、その辺を是正したいと思う。

標準入出力についても同じ事が言える。「主筆」に結びつけられる標準入出力は、サーバ起動時の端末であってコマンドを叩いたときの端末ではない。だが、標準入出力の再割り当てについては以前対処を試みたことがあったのだが、ファイルディスクリプタを浪費するというバグに見舞われて、結局やめてしまったという経緯がある。だから、直接的に端末ではなくて、せめてテンポラリのファイルか何かに出力できるようにするぐらいの対処を考える必要がある。

とりあえず、思いつく限り挙げてみた。第17版では、管理用ツールを中心に簡単に実装できそうないくつかの機能を取り入れていきたいと思う。全部は無理だろうが。

2006/09/06

アクセス数

一応書いておこうか。この間の日曜日、ようやく「主筆」第16版を公開した。当初の予定では、ドキュメントはもっと拡充する予定だったのだが、諦めた。第15版からそれ程変わってはいない。

で、書くネタもないから久しぶりにWebサイトのアクセス数についてでも書いておこうか。

最近では、広告の甲斐もあってか知らないが、アクセス数は順調に増えつつある。平日は安定して200PV/日を超えるようになった。休日でも100PV/日を超えるか超えないかと言ったところだ。

だが、アクセスのほとんどはMakecab.exeの話のところばかりで、他のページへのアクセスは多くない。

一番悲しいのは、メインコンテンツであるはずの「主筆」に関するページへはほとんどアクセスがないことだ。「その他情報」にまとめてある一群のページに対するアクセス数の、100分の1程度しかない。

また、あれほど頑張って書いた「Sun Studio 11」のページに対するアクセス数もそれ程多くはない。泣けてくるぜ。

だがまぁ、「Sun Studio 11」のページについては、次期バージョンが公開されたときの痛みを考えれば、余りアクセス数は多くない方がいいのかも知れない。アクセス数が少なければ、情報が陳腐化した場合にも、そしれぬ顔で削除してしまえることができる。

こう考えていくと、エセBBS形式のページは余り良くないのではないという気がしてきた。やはり、このサイトの客層(企業からのアクセスが多い)を考えると、余り変態を極めたようなページだとアクセス数が伸びないのだろうか。

アクセス数

一応書いておこうか。この間の日曜日、ようやく「主筆」第16版を公開した。当初の予定では、ドキュメントはもっと拡充する予定だったのだが、諦めた。第15版からそれ程変わってはいない。

で、書くネタもないから久しぶりにWebサイトのアクセス数についてでも書いておこうか。

最近では、広告の甲斐もあってか知らないが、アクセス数は順調に増えつつある。平日は安定して200PV/日を超えるようになった。休日でも100PV/日を超えるか超えないかと言ったところだ。

だが、アクセスのほとんどはMakecab.exeの話のところばかりで、他のページへのアクセスは多くない。

一番悲しいのは、メインコンテンツであるはずの「」に関するページへはほとんどアクセスがないことだ。「その他情報」にまとめてある一群のページに対するアクセス数の、100分の1程度しかない。

また、あれほど頑張って書いた「Sun Studio 11」のページに対するアクセス数もそれ程多くはない。泣けてくるぜ。

だがまぁ、「Sun Studio 11」のページについては、次期バージョンが公開されたときの痛みを考えれば、余りアクセス数は多くない方がいいのかも知れない。アクセス数が少なければ、情報が陳腐化した場合にも、そしれぬ顔で削除してしまえることができる。

こう考えていくと、エセBBS形式のページは余り良くないのではないという気がしてきた。やはり、このサイトの客層(企業からのアクセスが多い)を考えると、余り変態を極めたようなページだとアクセス数が伸びないのだろうか。

2006/09/02

残作業

ここに何度も書いていることだが、残りの作業はドキュメントの整備ばかりである。今現在は日本語版のユーザーズガイドを作成し終わり、英語版をいじっている最中である。

ところがだ、どうにも俺の浮気性というか、集中力のなさが災いして、なかなか前に進まない。昨日などは結局ほとんど何もできず、その代わりに減色を行うツールの高速化なんかに精を出してしまった。

余談だが、俺が作った減色ツールは処理族度が遅い。一番遅いのは、決定した色に従い各ピクセルにインデックス値を設定する処理だ。その中でも特に、選択された256色の中から、原色に最も近い色を検索する処理だ。

ここが、今は256色すべてを総なめにして、一番近い色を検索するようになっているのだが、これの負荷が重い。データは256個しかないのだから大したことないだろうと思ってはいたのだが、なにぶん検索する回数が多いため、トータルするとかなりの負荷になる。

じゃあどうすればいいのか。もし色のデータが1次元的なものならば、二分探索なりなんなりいくらでも効率的な方法があるのだろうが、なにぶんがRGBの3次元で表現されるデータであるため、単純な二分探索が使えない。

だが俺は考えた。うまく工夫すれば3次元空間上での二分探索(の様なもの)を実現することも不可能ではないのではないか。

そういうことで、主筆のドキュメント整備に費やすべき時間をすべてつぎ込んで、高速化に取り組んでみた。

だが、結局うまくいかなかった。脳内での理論では完璧に動作するのだが、実際のプログラムはなぜか途中で無限ループに陥る。

で、途中でいやになってやめた。また気が向いたら続きをやるかもしれない。そういうことで、肝心のドキュメント整備は一向にはかどっていない。

はぁ、英文うぜぇ

2006/08/31

危機

風呂にはいるときや用を足すときに、己の愚息がパンツの穴からはみ出していることに気が付くことがある。だが、別にこれは大したことではない。ここまでなら単なるポジションの問題なだけだ。

男なら誰でも経験があるだろうが、ズボンのファスナーを止めるのを忘れることがある。社会道義的に言ってこれはちょっとまずいのだが、しかし、それ程大したことではない。誰だってやってしまう可能性のあることだし、それに、多少パンツの生地が露出していたところで困ることなはい。

だがしかし、上記の現象が同時並行的に発生したらどうだろうか。これはまずい。考えただけでも身震いがでる。何せ、わいせつ物陳列罪で逮捕されてしまう程のことなのだ。世間一般ではストリーキングとか変態・変質者と呼び習わされる、あのやばい奴になってしまうのだ。

今ここでこうして、平穏無事にBlog何かを書いていることを考えると、俺はまだ先の事象を生じさせたことはないようだ。だが、いつ何時罠にはまるか知れたものではない。

人生、気を付けていないと思わぬところで踏み外す恐れがあるものだ。

2006/08/27

体調不良

夏期休暇を全部費やしたお陰で、何とか第16版として公開できるところまで持ってきた。後はドキュメントの整備が残っているだけだ。

だが、どうにもやる気がでない。おまけに体がだるい。前々から鼻水とくしゃみが止まらないとは思ってはいたが、どうやら本格的に風邪を引いてしまったようだ。

仕方がないから、今日は諦めて寝ることにしよう。

体調不良

夏期休暇を全部費やしたお陰で、何とか第16版として公開できるところまで持ってきた。後はドキュメントの整備が残っているだけだ。

だが、どうにもやる気がでない。おまけに体がだるい。前々から鼻水とくしゃみが止まらないとは思ってはいたが、どうやら本格的に風邪を引いてしまったようだ。

仕方がないから、今日は諦めて寝ることにしよう。

2006/08/26

ドキュメント

当初予定していた機能は通り一遍実装した。

結局今回新たに実装した機能は、ファイル読み込み・出力時にエンコードと改行コードを指定する機能だけとなってしまった。だが、その機能を実装したおかげでいろいろな部分を修正することになってしまった。

ファイル入出力時にエンコード名を指定する様にする、というのが主たる変更点なのだが、ファイル入出力の指示を出す方法が、ダイアログによるもの、コマンドによるもの、プラグインによるもの、と、大きく三つあるから、そいつらを全部修正しなければならないし、指定されたエンコード名は内部で保持して、上書き保存の時などに利用できるようにしなければならないし、なんだかんだ言って、いろいろなところに手を入れる必要があった。

正直、こんなことになるとは思わなかった。

次期バージョンを公開するためには、いくつか把握している明確なバグの修正と、ドキュメントの整備を行う必要がある。毎日PCの前に座っているというのに、時間ばかりが経過して一向にはかどらないような気がする。なぜだろうか。

2006/08/25

テスト

この数日でコマンド周辺の機能を通り一遍実装した。とりあえず、開いているファイル名を一覧表示する、ファイルを保存させる、スタンドアロンモードへ移行させる、という機能を作っておいた。また、ファイルを開くときにエンコードを指定する機能も付けておいた。

しかし、ファイル名一覧を表示するときに、エンコード名と改行コードの種別を表示する機能は付けなかった。これは、ファイル名を表示するだけならサーバ内の処理だけで済むのに対して、エンコード名と改行コードの種別を表示させるためには、主筆まで問い合わせなければならないためだ。一言で言えば、その処理を実装するのが面倒だったのだ。だからやめておいた。気が向いたら作るかも知れない。

で、いまはコマンド周辺の機能に関するテストを行っている。まぁ、それ程大したことをやっているわけではないのだが。

プラグイン周辺は未だに手を付けていない。

第16版公開までには、あとプラグインの機能の増強、いくつかのバグの修正、ドキュメントの整備が残っている。まったく、面倒なことこの上ない。

2006/08/22

集中力

主筆」の第16版を夏休み中に公開できるよう、何とか作業を進めてはいるのだが、これがなかなかはかどらない。結局、なんだかんだ言って仕事してたってしてなくたって、はかどらないものは、はかどらないらしい。まぁ、仕事がある平日に比べればずっと進捗はいいのだが。

現在は先に書いたとおりコマンド周辺の機能を増強している。で、今作っているのが、コマンドからファイルを保存させる機能だ。この機能が実装できれば、端末からコマンドを入力すると、「主筆」で開かれているファイルを保存させることができるようになる。

それの一体何が嬉しいのか。使い方次第で何にでもなるのだろうが、俺としては、「主筆」で編集しているプログラムをコンパイルする際、シェルスクリプトやMakefileにファイルを保存させるコマンドを仕込んでおくことで、コンパイル前にファイルを自動的に保存させるようにする、という使い方を想定している。これはまぁ、俺はたまに変更したファイルを保存しないでコンパイルしていて、それに気が付かないで長い間悩むという事をやらかすからなのだが。

ところで第16版では、ファイルを保存するときに、文字コードと改行コードを指定できるようになった。だから、コマンドでファイルを保存するときにも、文字コードと改行コードを指定する機能を実装した。だが、その作業を行っているときに気が付いた。いくつかの既存の機能においても、文字コードと改行コードを指定する機能を実装しなければならないのだ。

まず、コマンドでファイルを開くときだ。今までは「ファイル名」「構文種別」「行番号」を指定する機能を実装していたのだが、それ以外に文字コードも指定できるようにしなければならない。

また、これは最近新しく付けた機能なのだが、コマンドから、現在開かれているファイルのファイル名を取得する機能がある。これにも、文字コードと改行コードの種別を表示させる機能を加えた方が良さそうだ。

それと、プラグインに対して文字コードと改行コードの種別を取得・変更できる機能を提供するべきだろう。

こう考えると、やらねばならない作業がずいぶんと多い事に気が付く。しかも、第16版として公開するまでには、ドキュメントの整備という非常に重大な作業が、まるまる手つかずのまま残されている。

今のペースで進めていては、夏期休暇中に第16版を公開することはできそうにもない。まぁ、どうでもいいことだが。

2006/08/21

減色アルゴリズムの改良

数日前からいじっていた、減色を行うプログラムを改良してみた。

今までは、とりあえず手元にあるMicrosoftのImage Composerとか言うソフトを使った場合と比較して、どうにも画質の点で劣っていたのだが、いろいろといじったお陰で遜色ないまでに至った。

ただ、どうにも処理時間がかかるのが気になる。Image Composerを使用した場合は、待ち時間はほとんど無いのだが、俺が作った奴だと相当時間がかかる。

一番時間がかかっているのは、各ピクセルごと、カラーパレットの中から適切な色を選択して、出力イメージに設定する処理だ。

しかし、ここの処理は、はっきり言ってこれ以上高速化しようがないような気がする。やらなければならない処理を、やらなければならない通りにやっているだけだ。

それにしても、どうしてこんなに差が出るのだろうか。

2006/08/20

IME

この間買ったPDAをいろいろといじっていたら、なにやらソフトをダウンロードするようなメニューがあったから、適当にいじっていたら、ATOKが使えるようになった。

PDAを使う目的の都合上、日本語入力がタコいとどうにも作業がはかどらなくて苦労していたのだが、これで多少は良くなるだろう。今まで入っていたのがMS-IME98で、2000ですらなかったから、まじめに辛かった。

後は会社のPCにATOKを入れられれば、俺が使うマシンは全部ATOKになるのだが。一部のフリーソフトが許諾されるのなら、商用ソフトの一つぐらい入れても良さそうな気がするんだが、だめなのだろうか・・・

2006/08/19

コマンドの機能の増強

ようやく夏休みをとることができるようになった。長期連休の間に、いろいろとやらなければならないことがある。

まず、大学入学のための書類を用意しなければならない。一旦は通り一遍全部の書類がそろったと思ったのだが、どうやらまだ不足しているものがあったらしい。面倒なことこの上ない。

それ以外に、主筆の開発も進めたいと思っている。このところずっとご無沙汰していたから、そろそろバージョンアップしておきたい。

だがその前に、版を一つ上げるに足るだけの新機能を実装する必要がある。現状でも、第15版の状態からは多少変わっているとはいえ、客観的に見ればほとんど何も変わっていないと言わざるを得ない。

別に、機能をいくつ増やしたら版を上げる、などという決め事があるわけでもない。俺が勝手に適当な時期に新版を公開して、そのたびに番号を増やしていっているだけだ。だがそれでも、あまりにも変化がない状態で公開するのは何となく目覚めが悪いし、それに、更新履歴に書くことが無くなる。

そういうことで、前の考察に基づいて、主筆のコマンドの機能を増強している。

とりあえず今のところは、「主筆」で開かれているファイル名の一覧を表示する機能と、コマンドから特定の「主筆」をスタンドアロンモードへ移行させる機能を実装した。後はとりあえず、コマンドから「主筆」を終了させる機能と、ファイルを保存させる機能を実装したいと思う。

だが、このコマンドの機能を強化するのは、実は結構大変だ。前もこのblogに書いたような気もするが。

「主筆」は、コマンドのインタフェースを受け持つ「クライアント」と、起動しているエディタの管理を行う「サーバ」、そして「エディタ本体」の三つのプログラムに分割してある。でもって、そいつらが適宜プロセス間通信によって協調動作するように作られている。

そのため、新しい機能のコマンドを追加しようとすると、「クライアント」「サーバ」「エディタ本体」の三つに、それぞれ手を入れなければならない。場合によっては既存の機能を転用することで簡略化が図れる場合もあるが、そうでないことの方が多い。

まぁ、とりあえず夏休みは一週間確保したんだ。できる限り努力してみることにしよう。

2006/08/17

減色

時間が余った隙を窺って、減色アルゴリズムについて考えてみた。暇つぶしのみならず、実際上の問題として、画像の圧縮作業を自動化したいという要求もあってのことなのだが。

24bitカラーの画像を256色に落とす際、単純に、カラーパレットに代表的な色を設定して、元のピクセルの色に近い色を設定するだけだと、画質が酷く劣化することになる。ディザという処理を入れれば、多少は見られるようにもなるが、それでも酷い。

綺麗に減色するには、カラーパレットに格納する色を工夫してやる必要がある。絵全体で使用されている色には、大概にして偏りがあるから、その偏りを考慮して色を設定してやれば、かなり画質を向上することができるようになる。

その考察を元にプログラムを作ってみた。

ものはできたし、かなりいい感じで減色できるようにななったのだが、いかんせん処理速度が遅い。使っているあるゴリズムが悪いようだ。

もう少し、現実的な時間範囲内で処理できるようになったら、減色アルゴリズムの方法をまとめてWebサイトにでも公開することにしてみよう。夏休みにはいるし。

2006/08/15

機能の増強

作者自身がいうのも何だが、「主筆」は世の中一般に流布しているテキストエディタと比べて、オリジナリティがあるといえるような代物ではない。むしろ、業界標準的な仕様になるよう心がけてさえいる。

だが、それだけでは勝ち目はない。何らかの独創的な機能を実装する必要がある。そうでなければ存在意義がないというものだ。

では、現在の「主筆」が持っている機能の内で、他のエディタには見られないような機能・特徴とは何だろうか。そもそも、そんな特徴的な機能を一つでも持っていると言えるだろうか。

確証はないのだが、おそらくコマンドラインのインターフェースを持っているエディタは余り多くないのではないだろうか。無論、UNIX用のソフトは一般にコマンドで起動することを想定しているし、その常として、通常のエディタは起動時にファイル名等を指定する機能を持ってる。

だがしかし、コマンドで起動中のエディタに指示を出す事ができるエディタはあるだろうか。無いことはないだろうが、数は少ないだろう。

「主筆」は、その構造上、起動中のプロセスに対してコマンドから指示を出す事ができる。例えば、現在開いている全てのファイルを上書き保存させたり、特定のファイルを閉じたりすることだってできる。

だったら、その機能を増強してみたらいいのではないだろうか。例えその機能に対して需要が無かったとしても構わない。とにかく、何か一つぐらい他のエディタとは違ったところが必要だ。

人気がない事よりも、存在意義がない事の方が、はるかに辛いと思う。

2006/08/13

疲労

当初の予定通り、専門学校の卒業証明書と成績証明書を手に入れてきた。二日間に渡って電車に乗り続けるのはさすがに疲れる。

電車で座っている間に「言語ーことばの研究序説」を半分ほど読み進めた。だが、あの本はそんな一気に読み進めるようなものではないように思う。肩がこるし、目が疲れる。別の、もっとゆるい内容の本を持って行けば良かった。

電車のせいか本のせいかは知らないが、とにかく昨日は疲れた。せっかく時間があったのに「主筆」の開発はほとんど進まなかった。

とりあえず、「ファイルを開く」と「名前を付けて保存」のダイアログで、最初に表示されるディレクトリを、最後に開いた(保存した)ファイルのディレクトリにするように変更しておいた。言葉だけでは分かりにくいが、とにかく業界標準的な挙動に近づけておいたということだ。

後は、カーソルの動きにちょっと修正を加えて、第16版として公開しようと考えている。ここしばらく更新していなかったから、前の版から余り変化していないような気もするが、この辺でとりあえず公開しておこうかと思う。

まぁもっとも、新しいバージョンの奴を公開しようがしなかろうが、さしたる違いもないわけだが。

2006/08/12

高校の卒業証明書

昨日一日掛けて、高校の卒業証明書をとってきた。

さすがに電車で往復6時間も費やすと疲労がたまる。運賃も大体5000円ほど要した。

今日は発注してあった専門学校の卒業証明書と成績証明書を受け取りに行く予定だ。これもまた大分時間がかかるのだが、致し方ない。行動のないところに進歩はないのだ。

明日中には、大学の入学願書を提出しようと思う。真に大変なのはこれからだ。

2006/08/10

卒業証明書

通信制の大学とか言う奴をやってみようということで、早速資料請求だけしておくことにしてみた。

それを見ていて気が付いたことがあった。申請書類として、高校の卒業証明書が必要になるらしい。

専門学校の卒業証明書と成績証明書は、土曜日に発注してきた。まだ手元にはないが、取りに行くのはそれほど大変でもない。だが、高校の奴は結構大変だ。出身校は、今俺が住んでいるところからだと、結構離れている。

しかし、なぜに高校の卒業証明書が必要なのか。説明書きによれば、大学への入学資格があることを証明するための書類とあるのだが、しかし、それは専門学校の卒業証明書があればいいのではないだろうか。そういうものでもないのだろうか?

まぁ、面倒だが致し方あるまい。俺は、おかしいから制度を直せ等と主張するほどガキではない。

2006/08/09

Windows用のソフト

やっぱり何でもいいからWindows用のソフトを一つ二つ作った方がいいのだろうか。

Linuxですらない、x86ですらないSolaris用のソフトを作ったところで、誰にも使われることはない。客先のサーバで走らせようなどという強者は、そう滅多にはいない。

撒き餌の一つとして、Windows用のゲームでも作ってみるのもいいかも知れない。だが、それは時間がもったいないような気がしてならない。

まぁどうでもいいことだが。

2006/08/07

vectorの登録を削除

主筆」を除く、すべてのソフトをvectorから削除した。

公開を停止したのはBase64エンコーダと祐筆だ。祐筆はダウンロード数は限りなく0に近かったから、どうでもいい。Base64のエンコーダは俺が公開していたソフトの中では最もダウンロード数が多いソフトだったのだが、別にこれもどうでもいい。使っている人間がいるとは思えないし。

まぁ、どうでもいいか。

主筆だけ残したのには、特に理由はない。とりあえずVectorではダウンロード件数を教えてくれるから、何となく残しておいただけだ。後は、vector俺の紹介ページから俺のサイトへ入ってくる人間が、少なからず存在するから、それを当てにして残しておいたというのもある。

まぁ、それだけだ。

2006/08/06

通信制の大学

公開してから1年経過したが、総アクセス件数が数件しかない、俺の自己紹介のページ。そのページを読めばわかると思うが、俺は専門卒だ。高校の頃は大学とかいうところに行く頭も金も根性もなかった。

それでも何とかまともな会社(と信じている)に就職して、そこそこ経済的余裕が出てくると、必然的に逃れがたい心的活動に苛まれるようになった。

学歴コンプレックスというやつだ。

別に仕事をする上では、学歴なぞ全く関係ないと言っていい。専門卒のこの俺が御三家出身の奴に、あれやこれや指示しているのだ。指示っつーか、まぁ、頭下げてお願いしているのが現実だが。

いずれにせよ、仕事のできるできないに学歴は関係ないし、社内に於ける立場にもさしたる影響を与えないようだ。他人の手取りはなかなか知り得ないから、所得に与える影響は計りがたいものがあるのだが。

だがそれでも、この極めて無意味な情動はどうしようもない。否定しようが肯定しようが、間違いなくそこにコンプレックスは存在する。

このコンプレックスを抱いて、一人孤独にオナニーに耽るのも一興かもしれないが、それは俺の趣味ではない。悲劇のヒロインでありたがる奴は、俺の最も憎むべき人間である。

ならば、この問題は端から存在しなかったことにしてしまえばいいのではないか。実害はないのだし。黙殺して忘れてしまえばいい。闇から闇へと葬り去ってしまえばいい。

この方法は、俺が今まで生きてきた人生では、しばしば採用採用されてきたものであり、俺自身にとって極めて受け入れやすいものなのではある。だが、今回はちょっと方針を変えようと思う。

問題を無視し封印したところで、失うものが何も無かったとしても、得るものも何もない。それでは進歩がない。最近になって、ようやくそのことが分かってきた。だから今回は、積極的にコンプレックスを解消する方向で、何らかの行動を起こしてみようと思う。

何らかの行動とは何か。今回の問題においては、するべきことは明らかだ。学士の資格を取ればいい。たとえいかなる手段を用いたとしても構わない。金を出して買おうが、人から貰おうが、道で拾おうが同じことである。

とは言っても、実際問題道に落ちている類のものでもないし、yahooオークションに流れるものでもない。学士様になるためには、大学に入って出る必要がある。

しかし、俺は会社員であり、今の生活を続けるためには会社員であり続ける必要がある。大学だか高校だか知らないが、そういったところに通うためには学費が必要だし、それ以上に生活費が必要である。でもって、俺には数年間無職でも食っていけるほどの資力はない。

そういったことを考えると、俺がとることのできる行動は結構限られてくる。それは、通信制の大学に通うか、独立行政法人 大学評価・学位授与機構から学位を認めて貰うか、しかない。

どっちの方がいいのか、どこの大学にすればいいのか、具体的なところはまだ決めてはいないが、とりあえず昨日、専門学校の卒業証明書と成績証明書を発注してきた。

諸般の条件を鑑みつつ、夏休み期間中にでも具体的の行動計画を立てたいと思う。

2006/08/03

Webページを一枚追加

昨日の夜、久しぶりに早めに帰ってこられたから、Webページを一枚追加しておいた。内容としては、この間考えたメタボールのアルゴリズムの解説をやっておいた。

俺が参考にしたページに書かれていることをかみ砕いた内容であって、それ以上のことは書かれてはいない・当初の予定では、もう少し付加価値を付けようかとも思っていたのだが、何かと大変だし、早いうちに公開するだけしてしまおうと思ったからだ。

どこかで時間があれば、もっと綺麗にメタボールを生成する方法とか、球のポリゴンを生成する方法の図説とか、サンプルプログラムのSolaris版とか、解説とか、そういったものも追加していきたいと思う。

まぁもっとも、今現在急務となっているのは「主筆」の開発なんだがな。

2006/07/31

サイトの趣旨

Fire v250のマシンの環境を整えつつ、昨日はメタボールの作り方についてまとめてみた。とりあえず、自分がやったことについてだけ書いておくことにした。

syuhitu.orgのwebサイトは、主眼は「主筆」の紹介にあるわけだが、それだけではネタとして不足なため、それ以外の情報をできるだけ沢山押し詰めるようにしてある。言うなれば撒き餌だ。

その撒き餌は非常に雑多な種類で構成されているのだが、その中でもSun Studio 11のネタが結構多く含まれている。

だが、このネタには賞味期限がある。おそらくじきにSun Studio 12が出るだろう。そうしたら、Sun Studio 11のページは全面的に更新しなければならなくなる。その作業を考えると気が重くなる。

本来ならば、「主筆」のネタで勝負するべきではあるのだが、そもそも書くこともないし、そんなネタを充実させたところで誰にも見向きもされないだろう。

だから仕方がないから、賞味期限が無い、かつ、より一般受けするネタを広く提供していくことになる。だが余りこれをやりすぎると、サイトの趣旨がぼやけて焦点を見失うことになる。というか、現状すでにその傾向にある。

なかなか難しいものだ。

2006/07/29

Solaris8のインストール

結局、逡巡したあげくにFire v250にはSolaris8を入れておくことにした。

しかし、いつも思うのだが、javaの処理系のいろんなバージョンがごたまぜにインストールされるのは、どうにかならない物なのだろうか?

Solaris8にはデフォルトでjavaのSDKの1.1と1.2と1.3が入っている。でもって、Mozillaを入れると1.4がインストールされる。他にもPatchProは1.3を要求する。だが、俺としては最新版の1.5を一つだけ入れるようにしたい。

どうやったら理想的な環境になるのか。

さすがの俺でも、こう何度もSolarisのインストールをやっていれば、何となくやり方が判ってくる。

まず、デフォルトでインストールされている1.1から1.3は全部消してしまう。

次に、1.5をインストールする。これは、javaを要求するアプリケーションは、大概にしてインストール時にjavaが入っているか否かチェックを行うからだ。それを黙らせるためには、javaの新しい奴を入れておく必要がある。

で、MozillaやPatchProを入れる。そうすると、古いjavaがインストールされ、/bin/java等がいじられて、古いjavaが使用されるような状態になってしまう。(特にPatchProは酷い。あの糞仕様はどうにかならない物なのだろうか?)

次に、javaの古いバージョンを削除する。いらないから。

そして、新しい奴をもう一度インストールする。同じのがすでに入っているとか何とか言われるが、気にしないでかぶせてしまう。そうすると、/bin/javaや/usr/java等を元に戻してくれる。

あと、PatchProはjavaが/usr/j2seにインストールされることを想定している。パス名を固定で持っているらしい。だが、/usr/j2seというのはjavaの1.3の時の物だ。1.5ではj2seフォルダは作成されない。だから、手動でリンクを張って、/usr/j2seで/usr/javaを参照するようにしてやる。

そうすれば、システムにインストールされるjavaは最新版一つだけになり、javaを使用する全てのアプリケーションは、そのインストールされている最新版を参照するようになる。

この問題はSolaris10でもほとんど変わっていない。出てくるバージョンの番号が増えているだけだ。

javaは、基本的には上位互換性を持つように作っているのだから、バージョンが異なるごとに違うソフトとして取り扱われるようなパッケージを作成されるのはやめてもらえないだろうか? また、javaを使用するアプリケーションは、javaの上位バージョンを認識して、古い奴をインストールしないようには作ってもらえないだろうか?

知らぬ間にほとんど同じ奴が多数入っていたり、まったく使うことのない奴が入っていたり、新しい奴を入れたつもりで古い奴を使っていたりとか、そういう泣くに泣けない状況が発生しないようにはしてもらえないのだろうか?

こんな調子だからWindowsに負けるんだよ。

2006/07/27

環境構築

今までFire v250のマシンにSolaris10を入れていたが、調子が悪くなってきたからSolaris9を入れ直してみた。だが、それでもどうにも調子が悪い。何かと気に入らない。

なにが一番気に入らないって、キーボードの設定がおかしくなったのが気に入らない。今までは「日本語 no-off」というキーを押すとATOKが起動していたのだが、それが仮名入力になるようになってしまった。逆に「かな」キーを押しても反応がない。

日本語を入力するためにはCtrl+スペースを押さなければならない。

気に入らねぇ。

それに、昨日の夜からパッチを大量に当てているのに、pprosvcをやるとその都度新しいパッチが大量にダウンロードされてくる。さすがにそろそろ飽きてきた。

やっぱりSolaris10に戻そうか、どうしようか。だが、もう一度入れ直すは面倒だしな。悩ましいところだ。

2006/07/25

メタボール3

昨日ようやく、どうにもこうにも忙しい時期を脱した。これでまた少し暇になるから、主筆の開発を再開することができるようになるだろう。

で、メタボールだが、日曜日はさすがに仕事をやる気がしなかったから、適当な時間に切り上げて帰ってきて、メタボールをいじってみた。

まず、先日の考察というか妄想に従って、法線を幾何学的理由に基づいて計算する方法を試してみた。だが、これはあまり効果がなかった。法線を求める処理の演算量が減少しただけだった。どうやら、融合部分が乱れるのは、ポリゴンがうまく一致していないことに依存する、根本的問題であるらしい。

仕方がないから、力業でポリゴン数を増やしてみた。

そしたらこうなった。



うまくいっているように見える。ここで角度を変えてみる。



気になる点もあるが、それ程目立ちはしない。

やはり、ポリゴン数を増やすのが一番効果があるらしい。あだ、これをやると処理時間がかかってたまらないという大きな問題があるのだが。

メタボールについての本質的問題とは思えないが、ポリゴン数を減少させる、あるいは節約する方法についても考える必要があるのかも知れない。

2006/07/23

メタボール3

このところ酷く忙しい。Webページやプログラムを作る余裕がない。

それはまぁどうでもいい。あれからまた、メタボールの法線について考えてみた。

おかしいのは二つ(あるいは複数)のオブジェクトが融合している部分の法線だ。それに対処するにはいくつか方法があるのだろうが、ちょっと考えて思いつくのは下記の二つ。

  • 融合部分で、ポリゴンが重なり合わないようにする。何とかして頂点を共有するようにする。

  • 頂点の法線をポリゴンの法線から求めるではなく、幾何学的に算出する。



こういっては何だが、どっちも難しそうだ。前者は間違いなく俺の手に負える問題ではない。まだ後者の方が何とかなりそうな雰囲気にある。

融合面のポリゴンが、一部重なり合ったりして綺麗にならないのは、もうどうしようもないものとして諦める。それを前提に、法線を幾何学的に求める方法を考えてみる。

融合面付近では、ある一つのポリゴンの一部が表に現れていて一部が裏側に隠れている、という状況が発生する。つまり、一部分が他のポリゴンによって隠されるということが起こりうる。

そのため、法線は融合されたオブジェクトの表面だけではなく、内部の任意の点での法線を求められる必要性がある。そうすれば、俺の脳内シミュレーションによればうまくいくはずである。

では、どうやって法線を求めるのか。

オブジェクトが一つしかない場合は簡単である。中心点の反対方向に向かうベクトルが法線になる。問題は複数ある場合である。その場合、「オブジェクトの中心点の反対側を向くベクトル」は複数存在することになる。だからそれをうまく足し合わせてやる必要がある。

どうやって足し合わせるのか。単純に合計してオブジェクトの個数で割ったらおかしな事になる。ここは多分、おくオブジェクトごとの濃度の割合に合わせて足し合わせてやればいいともう。

つまり、オブジェクト1の濃度が0.1で、オブジェクト2の濃度が0.9だった場合は、1対9の割合でベクトルを足し合わせてあげればいいはづだ。俺の緻密な妄想に従えば、それで完璧なメタボールが完成することになっている。

どこかでまとまった時間が取れれば、上記の考察をプログラムにしてみよう。

2006/07/19

Solarisの再インストール

Solaris 10にパッチを当てると挙動がおかしくなる。ここ数日パッチを当てずに放置していて、久しぶりに更新してみたらやられた。

何が起きたのかは知らないが、多分ファイルシステムがzfsに変更したこととか何とかが影響しているのだろう。とにかく、最近リリースされたカーネルパッチを入れようとするとおかしくなるようだ。

原因を究明するのも、それに対処するのも面倒だったから、ここは手っ取り早くSolaris 10をダウンロードし直してきて、新しくインストールしてしまうことにした。問題のパッチを適用済みの奴を入れれば、多分大丈夫だろうという判断からだ。

だが、ここに大きな罠があった。ダウンロードしてきたCDイメージのサイズが大きすぎてCD-Rで焼けないのだ。

俺のCD-Rの焼き方に問題があるのか、買ってきたメディアが安物だからいけないのか、SolarisのCDRWコマンドを使うからいけないのか、Sunの人間が真性の馬鹿なのか。

原因はどうあれ、焼けないものは焼けないのだから仕方がない。今回はとりあえずSolaris 9を入れておくことにした。こういっては何だが、普通に使う分ではあんまり違いは無いしな。

そういうことで今は環境の構築中である。だから「主筆」の開発も現在は停止中である。第16版公開までの道程は長い。

2006/07/16

PDA

とうとうPDAなるものを買ってみた。

今現在、俺は毎日の通勤に二時間から三時間程度を費やしている。その内約一時間四十分を電車の中で過ごしている。一日が二十四時間しかないことを考えれば、これは大変な浪費である。だからこの時間をもっと有意義に使いたいと考えている。

とりあえず今は電車に乗っている間には本を読んでいるのだが、これは必ずしも生産的だとは言えない。だから電車に揺られている時間を、俺のもう一つの趣味、小説を書くことに当てたいと思う。

通勤ラッシュの電車は非常に混んでいる。当然だが。その中で文章を書くためには、非常に小型の機械が必要になる。一般的には携帯電話を使うという選択肢になるのだろうが、俺の場合はそれはありえない。特に理由は無いがとにかく携帯電話は使いたくない。あんなもんで日本語が入力できるかっつーの。

最近ではSONYが小さいPCを発売しているから、それでも買っても良かったのだが、何分値段が高い。安くとも17万円ぐらいはする。ただの趣味に、それも主たる趣味でないものに17万はつぎ込めない。

そういうことでいろいろ考えた結果、NTT Docomoのsigmarion IIIとか言う奴を中古で買っておいた。アレにはキーボードが付いていて、何となくアピールするものがあった。SHARPのZaurusもキーボードが付いていて何かと良さそうだったのだが、あいつはOSがLinuxであるという理由から、選択肢から消えた。しかも、付いてくるエディタのショートカットキーのバインディングがemacsに合わせてあるらしいし。死んでも買わねぇ。

そんなこんなで買ったはいいが、まだ使える状態にない。どうも本体を買っただけではPCと接続する術がないらしいのだ。sigmarionの本体には赤外線ポートがあるから、PCにも赤外線ポートが付いていれば、ファイル転送ぐらいはできるらしい。ところが、俺のマシンにはそんなハイカラなもんは付いていない。

後は、別売りのケーブルでPCのシリアルポートに繋ぐ方法と、LANのインターフェースカードを買ってきて付ける方法が有るらしい。更に余分な金を浪費せねばならないのは痛いが、致し方有るまい。ここまで来たら後には引けない。

まぁいずれにせよ、これで多少は限られた時間を有意義に使えるようになるだろうか。

2006/07/15

メタボール2

この間このblogに、メタボールの生成に成功したと書いた

で、せっかくメタボールに成功したのだから、その方法をまとめてWebに公開しようと思ったのだが、これがなかなか難しいようだ。以前ここで公開したのはワイヤフレームの絵であり、それでは面白味に欠けるし説得力がないから、ちゃんと照明を設定してシェーディングを掛けてやろうと思ったのだが、それが難しい。

いい感じで陰が表示されるためには、法線を設定してやらなければならない。だが、オブジェクトの接合部分の法線をどうやって計算したらいいのかが分からない。どうしても接合部分の色がおかしくなる。

実物を見た方が判りやすい。



上図のように正面から見ている分には、特に問題があるようには思えない。



だが、角度を変える化けの皮が剥がれる。接合部分、つまりくびれの辺りがおかしいことが判る。

法線を計算する際、俺は頂点を共有するポリゴンの法線を足し合わせて、平均をとる方法を使っている。とりあえずお手軽にできるからそうしている。だが、オブジェクトの接合部分では、ポリゴンは隣接しない。一部ポリゴンが重なり合うようになっているのだ。

その為、俺が使った方法だと法線が正しく計算できないのだ。どうすればうまくいくのだろうか。

2006/07/14

主筆の開発状況

このところ仕事が忙しく、開発が一向に進んでいない。二週間ほどは事実上ストップした状態にある。昨日は多少早めに帰ってこられたから、少しだけ作業を進めておいた。

当面、とりあえずやらなくてはならないのは、エンコード変換のプログラムをいじることである。これは「祐筆」の内部で呼び出して使用している変換用プログラムなのだが、こいつに問題があった。

今の仕様では、同じエンコード同士での変換はできないようになっている。例えばEUC-JPをEUC-JPには変換できない。変換も何もこれでは変換になっていないわけだし、する必要がないというのが俺の判断だった。

だが、このプログラムは改行コードの変換も行っている。エンコードを変換する際に一緒に改行コードも変換できる機能がある。しかし、同じエンコード同士での変換ができないように制限を掛けてしまうと、改行コードの変換だけを行うことができなくなってしまう。

主筆でファイルを保存する際、改行コードを指定する機能を実装する予定であり、その機能は上述の円k-どへんかんのプログラムの機能を流用するつもりである。しかし、エンコード変換を行う必要がない場合には、改行コードの変換を行うことができないとなると、その為にわざわざ改行コード変換の処理を実装する必要が出てくる。それは馬鹿馬鹿しい。

もっとも、わざわざ主筆に改行コードを変換するロジックを仕込んだところで、そんなに大した作業量というわけでもないのだが、それでも気分的に納得できない。何の納期があるわけでもないのだから、俺の気が済むようにやりたいのだ。

そういうことで、第16版公開までにはかなり時間がかかることになるだろう。

2006/07/13

PV数

内部リンクを緊密にした成果があったのだろうか。ここ最近PV数は大幅に増加している。今まで100PV/日がいいところだったのだが、最近では200PV/日に達する勢いである。

ところが、adsenceのクリック数は一向に増えない。今までとまったく同じだ。というか、同じかどうか判断しようがないほど少ない。

見かけ上のPV数が増えたところで、俺としてはまったく嬉しいことはないわけで、どうにかしなければならないと思っている。しかし、クリック率を増加させるにはどうしたらいいのだろうか。

なかなかに難しい問題だ。

2006/07/12

電気を大切にね3

電力ネタ三つ目。

以前、ホワイトアウトという映画があり、その中に、とある水力発電所を停止させて付近の村を停電にする、という描写があった。

アレはおかしい。

電力会社が持っている送電線ネットワークは、基本的には全て一つにつながっている。無数にある発電所は、それぞれが無数にある需要家に電力を供給しているのであって、どこかの発電所がどこか特定の地域に電力を供給しているとか、そういう作りにはなっていない。

乾電池三本を並列に繋いで、そいつに豆電球三つを並列に繋ぐという回路を考えてみる。その場合、二本以内であれば、三本の乾電池の内のどれをはずしたっても、豆電球が消えることはない。ましてや、どれか一本が選択的に消えることなどありえない。基本的にはそれと同じだ。

現に、何年か前に東京電力で原子力発電所が一斉に停止されたことがあったが、停電には至らなかった。もし、あの映画のようなことが起こるのだとしたら、原子力発電所の周囲では電気が使えなくなっていたはずである。

送電線が切られても、一般には停電になることはない。通常であれば、バックアップの線が用意されているはずである。ところがこれは必ずしもそうとは言い切れない。

以前、自衛隊の戦闘機(?)だったかが、演習中に墜落して送電線を切断したことがあったのだが、そのときある一部の地域で大規模な停電が発生した。当時、これは送電ネットワークの不備としてマスコミにたたかれていたような気がする。

テロか何かで大規模な停電を引き起こそうと企てているのであれば、どこかの発電所を停止させるというのは愚の骨頂である。発電所を一つぐらい停止させたところでビクともしないのだ。やるのなら送電線を切断するべきである。その方が確実だし、それに、発電所よりも送電線の方が警備は手薄である。

もっと面白いのは、送電線に発電機を接続することである。といっても、生半可なものではだめなのだが。原子力発電所並みの巨大な発電機を接続して、意図的に交流の周期をずらした電流を流し込む。そうすると、他の発電所の発電機が全部一斉に故障することになる。はずだ。そうすれば、お望み通りの大規模停電を引き起こすことが可能になる。

どうせやるのなら、事はでっかくやらないと面白くなかろう。

2006/07/11

電気を大切にね2

あの若奥様が、いくら「電気を大切にね」と訴えかけたとしても、やはり夏場は暑い。エアコンがあるのであれば付けたくなるのが人情だ。

そんなこんなで最終的に電力が不足したら、一体どうなるのだろうか。俺が知っている限り書いてみる。

まず行われるのは、大口需要家に対して電力不足を通知して、電気使用量を節約してもらうことだ。大きな工場やビルなどでは、普段の電気料金を少し安くしてもらう代わりに、電力不足の際には一定レベルまで電気使用量を低減させるという契約を結んでいるところがある。

実際に電力が不足したら、そういった契約がある需要家にお願いをして、使用量を削減してもらう。

また、隣近所の電力会社から電力を融通ししてもらうこともできる。送電線ネットワークは、基本的には各電力会社ごと独立しており、つながってはいない。しかし、万一の際に互いに電力を融通できるように、つなげてある部分がある。で、電力が不足した際には、そういった接合部分を通じて、隣の電力会社から電力を買ってくることができる。

例えば、東京電力であれば東北電力から電力を調達してくることになる。東京電力は中部電力とも隣り合ってはいるのだが、この二つは周波数が違うため、なかなか融通し合うのは困難がつきまとう。不可能というわけではないのだが、送電容量に限りがあるのだ。(交流の周波数変換は結構大変らしい)

また、独立系の発電事業者、いわゆるIPPから調達してくることもできる。世の中には、自分で発電所を持っている会社というのが結構ある。例えばNTTやJR(停電時にもサービスを提供できるようにするため)、あるいはゴミ処理場(余熱で発電する)などだ。電力会社はそういった事業者から電力を調達してくることもできる。

それでも足りなくなったらどうなるのか。

そしたら、停電するしかない。

だが、全面的に停電になるわけではない。そもそも、停電になるのは需要が支えきれないからなのであり、電力会社が持つ供給能力自体には変動はないのだから、全てを停電にしてしまう必要はないのだ。

だから、電力が不足した場合には、輪番停電という、各地域ごとに持ち回りで停電にするという方式がとられる。大きさは忘れたが、ある程度の面積ごとに地域を区切って、それぞれの地域を一日の内一時間か二時間ぐらい、順番に停電にするのだ。

輪番停電は電力不足の最終形態であり、電力会社は何があってもこのような事態は防がねばならない。

だから、予防措置としていろいろな事をやっている。上記の、万一の際には節電するという契約や、昼間の電気料金を高めに、夜間の電気料金を低めに設定するとか、CMで「電気を大切にね」と訴えてみるとか。

最近、アメリカではもっと過激な方法がとられているらしい。詳しいことは知らないが、何でも電力不足の際には一般家庭のエアコンを止めてしまうような仕掛けをくっつけようとしているらしい。まぁご苦労なことだ。だが、日本でそのシステムを導入するのは、なかなか困難ではないだろうか。

2006/07/09

メイドさんブーム

すぐ終わるかと思っていたメイドさんブーム。意外に長続きしている。

風邪でふらふらではあったけど、暇だったから秋葉原に行ってみた。特に理由は無かったが。

秋葉原駅の電気街口を出て左に行ったところの広場に、メイド服を着た連中が多数いた。いすぎた。どう考えても、メイドさん人口が多い。多すぎる。

それ程広いとは言えないあの空間に、おそらく数十人はいただろうか。多すぎ。

いくらブームだからといっても、馬鹿の一つ覚えのようにメイドさんにする必要も無かろうに。たまには巫女とかにもすればいいのに。

一口にメイドさんといっても、いろいろなタイプがあるようだ。基本的には、黒ないし紺の服にフリフリの白いエプロンなんだが、中には色違いの奴もいる。

エプロンの縁がちゃんとフリルになっている奴もいれば、そうでない横着型の奴もいる。生地が硬いのか補強が入っているのかは知らないが、鎧のようになっている奴もいる。

スカートが短く太ももが露出している奴もいれば、足首まで隠れている奴もいる。

純粋に服装の形という意味での俺の好みは、色は黒でスカートは長い方がいい。少なくとも膝下まである方がいい。夜目遠目傘の内と言うだろう。

メイドさんなのかどうだかは知らないが、中にほとんどボンデージとしか言いようのない格好をしている奴がいた。あの手の格好でビラ配りをするのは結構辛いと思うのだが、そんなに時給がいいのだろうか? あるいは好きでやっているのだろうか?

あれだけ沢山メイドさんがいると、インフレを起こしてメイドさん一人当たりの価値が減じてしまう。各社メイドさんブームに乗ろうという気持ちも分かるが、もう少し工夫した方がいいのではないかと思う。

2006/07/05

進捗

このところ、主筆の開発の進捗が悪い。どうも風邪を引いたらしく体調が思わしくない上に、このところ妙に忙しい。主筆をいじっているどころではない。

暇だ暇だと周囲に言い続けていたら、超短納期の開発案件が回ってきた。その上、社内のイベントが目白押しになっている。日程的にかなりきつい。

仕事があることはいいことだとはいえ、いくら何でも納期短すぎ。

2006/07/03

内部リンク数

この間書いたとおり、俺のサイトでは、検索エンジンから飛び込んできて、他のページには行かずに出ていってしまうというパターンのアクセスが結構ある。言うならば、撒き餌を食い逃げされているような状態だ。

それは余りよろしくないだろうと言うことで、内部リンクを緊密にすることにした。

「その他情報」のページは追加や削除が頻繁にあり、全てのページから全てのページに対してリンクを張るのは維持管理が大変だからやっていなかった。

だがこの間、インデックスの部分だけをJavaScriptととして切り出しておくことで、先の内部リンクを実装しておいた。

本来ならばJavaScriptは使いたくなかったのだが、背に腹は代えられない。構造化しなければ更新負荷が大きすぎて耐えられなくなるし、リンクが疎ではアクセス数が増えない。

それと、JavaScriptが無効だと、左側に何もない灰色の領域が生じてしまうが、まぁ致し方あるまい。元々無かったリンクだ、今更表示されなかったところで困ることはない。

しかし、HTMLとか言う奴にはincludeやCOPY句に相当する機能はないのだろうか? XMLにならばあるのだろうか?

web系の技術というのは、どうしてこうも見苦しいのだろうか。つくづく嫌になる。

2006/07/02

電気を大切にね

関東一円に住んでいる人間ならば、誰でも知っているキャッチフレーズ。だが、この言葉、よく考えると酷くおかしいことに気が付く。

何がおかしって、自社商品(電力)を買うな、という意味なのである。数あるCMの中でも自社の商品を買うな、という意味のCMをやっているのは電力会社ぐらいなものである。どこぞの会社の青汁のCMのように、意図的に自社商品を侮辱するようなCMをやる場合もあるが、それはあくまでも広告の一手法であり、決して本気で買うなと言っているわけではない。

ではなぜ電力会社はそんなCMを放送するのか。もちろん、あのCMは電力会社が金を払って放送しているのである。

理由の一つには、企業のイメージアップというものがある。CSRの一環として、環境保護を訴えるというのは正当な手段だ。しかし、だからといって自社商品を買うなというのはおかしい。自動車メーカーや石油会社は「地球に優しい商品」のCMをやっている。なのに、なぜ電力会社は直接的に「自社商品を買うな」と言っているのか。

もっと直接的な理由がある。それは、商品が売れなければ売れないほど、つまり、電力消費量が下がれば下がるほど利益が増える仕組みがあるのだ。というより、電力消費量の増大に伴い損失が増加するといった方がいいか。

電力会社はその役割上、決して停電を引き起こしてはならない。つまり、電力不足は何が何でも防がなくてはならない。しかし、電力は蓄積できない(東京一つ分の電力を蓄積できるような蓄電池は未だに存在しない)。だから、電力会社は、最大消費電力量を賄える程の発電設備を用意しなくてはならない。

発電・送電システムというものは、建設には金がかかるが、運用コストはそれに比較すれば低い。つまり、建設された発電所や送変電設備は、限界ギリギリまでこき使った方が儲かる。

しかし、電力消費量というものは、季節や気温などによって大きく異なる。夏場のクソ暑い時間帯には非常に多くなるが、そうでない時期や時間帯はかなり少ない。

だから電力会社としては、利益を増やすためには、電力消費量の少ない時間帯の需要を増やさなければならない。また、逆の考え方として、電力消費量が多い時間帯の需要を減らすという方法もある。そうすれば発電所や送変電設備を少なくすることができる。

他にも電力使用量が安定していれば、原子力発電による発電量を相対的に増やすことができる、というのもある。原子力発電所は他の発電方法に比較して、建設費は高いが運営コストは低いという傾向が強い。はっきり言って、一度できてしまえば、後はただみたいな値段で発電できるのだ。

また、技術的な問題として、原子力発電所は余り発電量を変動させない方がいい。安定して運用した方が安全性が高い。だから、原子力発電はベース電力を担うようにして使用している。

そこで、電力使用量が安定していれば、相対的なベース電力が増える事になるわけで、結果として原子力発電所の使用量を増加させ、火力発電所の使用量を削減できるようになる。

で、その電力使用量を安定させる手段の一つとして、蓄冷式のエアコンや、夜間電気温水器、IHクッキングヒーターなどといった物を売り込みをかける。そして、その裏返しで「電気を大切にね」というCMで、ピーク電力の削減を図る。

あの若奥様には結構ファンが多いようだが、ファンならばCMの本来の意味ぐらいは知っておくべきだろう。

2006/06/30

アクセス数

なんだかんだ言って、アクセス数は少しずつ上昇しつつある。およそ一週間サイクルで上昇と下降を繰り返しつつ、もう少し長いサイクルでの変動があり、全体としては増えている。

ここ二ヶ月ほどは、一日平均100PVを維持している。下は50PV/日から上が200PV/日ぐらいだ。

それなのに広告収入は一向に増える気配がない。最近アクセスしてくるようになった人間は、広告をクリックしない類の人たちばかりなのだろうか?

2006/06/28

法則

マーフィーの法則というのだったか、物事は常に悪い方へ転ぶ、あるいは、常に裏目に出るという法則がある。

なぜか知らないが、俺が傘を持って外に出ると決して雨は降らず、持ってこなかった日に限って雨が降る。一体何の嫌がらせなのかは知らないが、傘は必要なときには無く、入らないときに限ってあるから困る。

スーパーのレジもそうだ、俺が並んだ列はいつも進捗が悪い。気が付くと俺の後ろにいる奴の方が先に精算を終えている事がある。大概にして、俺の直前にいる奴がやたらと時間のかかる奴であることが多いのだ。一体何の嫌がらせなのかは知らないが。

そもそも、スーパーのレジでなぜにそんなに時間がかかるのだろうか? 一体何をしているのだろうか? 人によっては15分ぐらい粘っている奴がいる。時間を掛けた方が得だとでも思っているのだろうか?

遅いと言えば、ATMのいじっているオバハンも不思議だ。一体何をしているのだろうか? なせあんなに時間がかかるのだろうか? いくつもの通帳やカードをとっかえひっかえ、金を出し入れしている。暇なのだろうか?

年寄りは歩くのが遅い。それはまぁ致し方のないことだろう。しかし、だったら人の前に強引に割り込むのはやめてもらえないだろうか。突き飛ばされたいのだろうか? まぁ、そういう場合俺は押しのけて進むわけだが。自分の歩く速度を考えずに、人の前に割り込んできた奴の方が悪いのだから。

女はなぜ道をよけないのだろうか? 自分の方が優先されるとでも思っているのだろうか? コンビニなんかで、商品棚の前に俺が立っていて、方一方から女が進行してくると、その女は絶対に止まらない。男の場合は、大概止まるか、進行方向を変えるか、道をよけていくのだが、女の場合はそういうことはほとんど無い。なぜだろうか? それでもって、俺が道をよけずに頑張っていると、その女はどんどん進んできて、最終的にはぶつかることになる。そうするとその女は、まるで俺が痴漢か何かかのような目つきで睨み付けてくる。一体何を考えているのだろうか? 被害者は俺であり、おまえの方が加害者ではないか。殺すぞ。

電車の中でもそうだ。自分の方から近づいてきておきながら人を痴漢扱いする。

酷い奴になると、自分で押してきておきながら「押すんじゃねぇよ」とか言ってきやがる。このときはさすがの俺もむかついたから「押されてるんだろうが、馬鹿が」と言い返しておいた。だが、今思い返すと言うべき言葉が間違っていたように思う。ここは「オメーが押してるんだろうが、売女」とでも言った方が良かった。

俺のオカンもそうだが、どうも、自分が悲劇のヒロインでありたがる奴というのが結構いるようだ。特に女がそうだが、男の中にもいる。何があっても自分は常にかわいそうな被害者であり、周囲の人間は常に自分に悪意を抱いている。そう本気で考えている奴が世の中にはかなり多数いる。

そういった人間に気を遣うのは、馬鹿馬鹿しいし報われないから、強気に出るに越したことはない。

2006/06/26

進捗

一向に作業がはかどらない。土日を費やしても、結局、読み込み時のエンコード変換の処理を実装できただけだった。まだ出力時の変換処理が残っている。道のりは長い。

今現在は、とりあえずエンコード変換に対応使用としているだけだけで、それ以上の機能を付けるつもりはない。つまり、エンコードの自動認識は後にしようと思っている、ということだ。

だが、そうするとちょっと困ったことになる。

ファイルを開くとき、「ファイルを開く」ダイアログからファイル名を指定する場合は、特に問題はない。そこでエンコード名もいっしょに指定させればいい。だが、ドラッグ&ドロップでファイルを開く場合はどうするべきだろうか。

自動認識機能を実装するのであれば、エンコードを自動認識するという仕様にするのがもっともだと思う。だが、自動認識を実装しないのであれば、是非ともどこかでエンコード名を入力させなければならない。

ドラッグ&ドロップされたタイミングで、強制的にエンコード名のダイアログボックスを表示させるというのもあるだろう。だが、それでは使い勝手が悪くなるように思う。毎回表示されるのはさすがにうざいだろう。

一旦、カレントのロケールで使用されているエンコードで読み込んでみて、それで失敗するようだったらエンコード名の入力を促すという方法もあるだろう。だがそれにも問題がないわけではない。

どうするのが一番いいだろうか。

2006/06/25

コードの再利用

プログラムを作っていると、かつて一度作ったことがあるような処理をもう一度作っていると言うことがある。既視感みたいなものだ。

それが単なる既視感なのであれば、それはそれでどうでもいいのだが、問題は本当に同じ様な処理を作ったことがある場合だ。

何かのプログラムでどこかに書いたであろう処理を、再度作り込むのは馬鹿馬鹿しい。かといっても、その処理が書かれたプログラムが一体どこにあるのか、それを思い出すことができない。

結局、同じ処理をもう一度記述する羽目に陥る。普段からソフトウェア工学なんたらと偉そうなことを行っている割には、俺の実態はこの程度のものだ。

この辺でそろそろ何らかの手を打っておいた方がいいのかも知れない。

そもそも論でいけば、リポジトリ関係のソフトを導入するべきだと思う。最良の解は、自分が作成したクラスや関数をリポジトリに登録し、コンパイル時にはリポジトリ内にあるコードが自動的に使用される、という仕組みだ。

だが、これを実現するのは非常に大変だ。ソフトの購入に金がかかるのは、まぁ仕方がないだろう。もしかしたらフリーソフトがあるかも知れないし。最大の問題は、開発スタイルの変更を余儀なくされることだ。

自分の作業手順が多少増減する程度であれば、特に問題はない。だが、作成するプログラム中に、リポジトリ内のコードを参照する為のコードを記述しなければならなかったり、あるいはヘッダファイルの参照や、リンクするライブラリの参照に変更が生じたりするのは、是非とも避けたいと思う。

結果としての実行バイナリだけが得られればいい、というのであればそれでもいいだろう。だが、ソースコードを配布しようとする場合には困ったことになる。配布するためには、リポジトリからコードを取り出して、必要に応じてMakefileやプログラムを書き換えて、単独でコンパイルできるようにしてやらなければならない。それは非常に面倒だ。だからといってリポジトリごと配布するわけにも行かない。

それ以外にも、ある特定のリポジトリソフトに全面的に依存するのにも嫌悪感を感じる。作成したプログラムの一部ないし大部分がリポジトリ内に格納されて、そのリポジトリソフトがなければコンパイルすることもできないとなると、不安を感じざるを得ない。

どうしたらいいだろうか。何か、俺の需要を満たしてくれるような、いいソフトはないだろうか。あるいはいい感じの物を自作するべきだろうか。

2006/06/24

プロセスの分割

エンコード変換の処理を行うプログラムは、以前「祐筆」の為に作成した変換プログラムをそのまま使うことになった。今まで、変換処理の実装には、変換用プログラムから変換処理を行う部分を切り出してきて「主筆」に組み込む必要があるかと思っていた。しかし、どうやらそんなことをせずとも、変換処理を別プロセスで行うような実装にしても問題なさそうだ。

プログラムの明瞭性を高め、維持するためには、ロジックを様々なレベルで極力細かく分割するのがセオリーだ。たとえば、長大な単一の関数より小さな複数の関数の方が解りやすい(一般的には、だが)。同じ要領で、クラス・コンパイル単位・変数のスコープ・変数の寿命・コンポーネント・プロセス・サービスなど、いろいろな種類の「分割」が考えられる。

主筆」第15版では、クライアント・サーバ・主筆本体の3つのプロセスに分割されている。そして今度それにエンコード変換のプロセスが追加される。

第15版の実装方法は、機能を実現する上での必要性から導き出された結論だ。しかし、上述の議論を考えると、プロセスの分割は必要性のみならずソフトウェア工学的な観点から見ても、もっと積極的に押し進めてもいいのかも知れない。

だが、プロセスで分割するのは何かと大変だ。処理の依頼と結果の受信は、全てIPCの機能を使ってやらなければならない。共有メモリとかパイプとかRPCとか、いろいろな種類のIPCがあるが、どれもこれもプロセス内での関数呼び出しに比較すれば遙かに複雑で困難だ。まぁ、だからこそ厳格に分割することができるのだが。

時間の問題もあるから、第16版では余り大したことはできないだろが、最近肥大化しつつある主筆本体の分割には、いつかは手を着けなければなるまい。

2006/06/22

アクセス解析

この間から使い始めたアクセス解析を、徒然なるまま眺めてみた。

で、気が付いた。

まず、アクセスの内の多数が、makecabjpeglibの使用法のページに集中している。でもって、このページへのアクセスの多数が、googleやyahoo等の検索エンジンから直接飛び込んできたものであり、他のページへ移動することなく俺のサイトから出ていくのだ。

つまり、これらのページは誘い水としては成功してはいるのだが、他のページにアクセスを誘導することができていないのだ。

じゃ、どうすればいいのか。

各ページの情報に関連性を持たせるのがいいのだろうが、そもそも関連のない情報は関連がないのだから、仕方がない。とりあえず、無理矢理にでもサイト内リンクを密にするべきなのだろう。

サイトの基本的な作りとして、左側にインデックスの領域を設けてあるのだが、「その他情報」のページだけは、追加や削除が頻繁にあるだろうという判断から、そのインデックスを付けていない。やはり付けるようにした方がいいのだろうか?

でも面倒なんだよな。ページ数も多いし。楽にやる方法はないものなのだろうか?

2006/06/19

忘却

今現在、「主筆」にエンコード変換機能を実装しようとしているところなのだが、ある機能のことを完全に忘れていた。

読み込み/出力時に変換しなければならないのは、文字コードだけではなく改行コードもあったのだ。そのことをすっかり忘れていた。

実際に文字コード変換を行うプログラムはすでにできていて、それは改行コードの変換にも対応している。しかし、「主筆」側で改行コードの種別をユーザに入力させる機能が抜けていた。

要は、ファイル名を選択させるダイアログで、文字コードと共に改行コードの種別も入力させればいいだけのことなのだが、これが面倒くさい。入力項目の増減を伴う変更は、結構大きく変更が波及する。

これは別に主筆に限った話ではないし、それどころかXやMotifに依存する話でもない。Windows上のアプリケーションでも、EXCELマクロでも同様だ。

DOAなんたらの講釈を垂れるつもりはないが、あえて言わせて頂く。入出力項目の増減はデータ項目の増減につながることが多い。でもって、プログラムは処理するデータに依存して記述される。データありきのプログラムというわけだ。だから、データ形式が変更されると、プログラムに変更が及ぶ可能性が高くなるのだ。

そういうことで、改行コードの種別を入力させる機能を実装するのは面倒なのだ。先の原因不明のバグみたいなのが起こることもあるのだし。

第16版公開までは、今しばらく時間がかかるだろう。

2006/06/18

デバッグ2

土曜日は接待飲みだった。なぜに金を払って仕事をせねばならんのか、等とここにサラリーマンの愚痴を書いても仕方がない。

この間、XtOpenDisplayの呼び出しでメモリアクセスエラーが検出される、と書いたが、そのエラーは主筆に限らずSun Studio 11の解説で使ったTestPrj3というプログラムでも発生することが判った。

このTestPrj3というのは、解説用に作っただけのきわめて単純な奴で、俺自身はほとんど何もプログラムを記述していない。だから、たぶんXtOpenDisplayの呼び出しで検出されるエラーは、俺のせいではないと言うことができるのではないだろうか。

そういうことで、メモリアクセスのエラーについては、ここではちょっとおいておくことにした。

で、次に何をしたらいいのか。寄る辺を失いする事が無くなったから、とりあえず漫然と起動時のシーケンスを一つずつステップ実行してみた。

そしたら気がついた。

CTaEditShell::OnCreateというメソッドは、シェルウィジットが生成されるときに呼び出される。つまり、シェルウィジットが生成されるときのコールバックとして登録してあるということだ。



で、このコールバックだが、こいつは本当にシェルウィジットが生成された直後に呼ばる。シェルウィジット配下の他のウィジットが生成される前に呼び出されるのだ。

一応、CTaEditDrawなどの「シェルウィジット配下のウィジットを管理するクラス」のインスタンスは、「シェルウィジットを管理するクラス」のコンストラクタで生成されているから、OnCreateが呼び出された段階では、こいつらにアクセスすることができるようになっている。しかし、ウィジット自体はまだ存在しない。

だからシェルウィジットのOnCreateの段階では、あまりウィジットやMotifの初期化処理を行うことができないのだ。

ところが俺は、今まで余りそういうことを考えていなかったようだ。思い返すだけでも身震いがする。

だから、今度はそういう視点で初期化処理について見直してみた。そして、今までOnCreate内にあったいくつかの処理(正確には、タイトルバーの文字列の設定をアイコンの読み込みなのだが)を、もっと後の方で呼び出されるメソッドに移設してみた。

その結果、一応プロセスが殺されることなく起動することができるようになった。

だが未だに起動できなかった本当の理由は判然としていないし、メモリアクセスエラーの問題も何ら解決していない。これでいいのだろうか?

2006/06/16

主筆のデバッグ

ここ数日、主筆に文字コード変換機能を追加しようとして、いろいろと手を加えている。

その途中で、ドキュメント管理用のクラス(編集対象のテキストを保持している)に、エンコードの情報を保持するメンバを追加したら、主筆が動かなくなった。

起動する途中、メニューのウィジットを生成する処理でセグメント例外が発生して、プロセスが殺されてしまう。上述のメンバを取り除いてやると動く。

それ以外の状況なども含めて考えると、どうもメモリ関係のバグが発生しているようだ。Sun Studio 11が持っている、メモリアクセスのエラーを検出する機能を使用すると、いくつか引っかかるところがある。どう考えても何かがおかしい。

ところがだ、どこがどうおかしいのかがさっぱり判らない。いつ頃からおかしくなるのかすら判然としない。XtOpenDisplayの呼び出しでいきなりアクセスエラーが検出される。

Sun Studio 11が生成したコードがおかしいのか、MotifやXlibがおかしいのか、デバッガがおかしいのか、本当に俺の書いたコードがおかしいのか。それすらも判らない。まぁ、たぶん俺の書いたコードが間違っているのだろうが。

に、しても、XtOpenDisplayはプログラムの本当に初めの方で呼び出されるのであって、それより前には俺の書いたコードは実行されないはずだ。

一体何がおかしいのだろうか?

2006/06/13

メタボール

深い理由はないが、前々からメタボールをやってみようと思っていた。しかしながら、今まで果たせずにいた。どうにも難しくて、なかなか作れなかったのだ。だが、この間ついに成功した。



絵はワイヤフレームで表示されていて、なんだか分かりにくいが、一応3つのボールが融合した形になっている。

ややこしい割には、実際にプログラムにしてみると結構単純で、総行数でも500行程度だ。俺は一体今まで何をこんなに悩んでいたのだろうかと、自分で自分を疑いたくなる。まぁ、短いから簡単と言うわけでもないのだが。

現在の実装だと、接合部分に乱れが生じやすく、それを防ぐためにはポリゴン数を増やす必要がある。しかし、ポリゴン数を増やすと、形状の生成や描画に時間がかかるようになる。

何らかの抜本的な対策をとるのが最前なのだろうが、それはもはや俺のおつむには不可能事に近いため諦めるとする。

今ひとつの方法としては、あらかじめ細かいポリゴンで形状を生成しておいて、後から余分なポリゴンを削るという方法だ。これならまだ何とか俺の手に負えそうだ。

今度時間があったら、久しぶりにスクリーンセーバーでも作ってみることにしよう。

アクセス解析

日曜日、暇だったから全部のページにアクセス解析のコードを仕込んでおいた。

まだ余り結果は出ていないみたいだったが、とりあえず昨日統計を見てみた。

俺は今まで、俺のサイトに飛び込んで来るときに使用された検索エンジンは、ただ何となくgoogleが多いのではないかと思っていたのだが、どうやらそうではないらしい。

一番多いのはyahooだった。大体全体の3割程度がyahooの検索から入ってきている。googleは1割に満たない。

google analyticsは、えげつないことにアクセス元ドメインまでもが表示されるのだが、それを見るとどうも各社SIerからのアクセスが多いようだ。この事はアクセス数の変化、つまり平日が多く休祭日は減少する、という事実から何となく感じてはいたのだが、どうやらその感じは間違ってはいなかったようだ。

せっかくだから、今後のweb制作にアクセス解析の結果を有効活用させてもらおうか。

2006/06/11

主筆のビルド

文字コード変換に対応するとか行っておきながら、昨日は本来の作業を怠って、ビルド時にパッケージが自動的に生成されるような仕掛けを作り込んでおいた。

仕掛けといったって、とどのつまりはMakefileでコンパイルによって生成されたファイルの収集とパッケージ生成を行う一連のコマンドを叩くだけなのだが。

この間買ってきてまだ残っている安いブランデーをちびりちびりとやりながら、その上テレビを見ながらの作業だったから、非常に時間がかかった。結局、昨日の進捗はその作業だけだった。

だがまぁ、この作業によって、今後のリリース作業が効率化されるようになったのだから、良しとするか。

2006/06/09

検索・置換

検索・置換機能をいじった結果、こういう風になった。


それと、もう一つ機能を追加しておいた。

今まで、「検索・置換」ダイアログは、メインのウインドウの後ろ側に隠れてしまったら、そのウインドウを自力で移動して、「検索・置換」ダイアログをマウスでクリックしなければならなかった。だが、それでは面倒で不便だから、「検索・置換」メニューを選択するか、あるいはCtrl+Fキーを押すかすると、「検索・置換」ダイアログが一番前に表示される様にした。

それと後、検索に使用した文字列を記録しておいて、後からそれを参照できるようにする機能とか、「検索・置換」ダイアログにおけるショートカットキーなんかの機能を実装したいと思うが、それは後にしておくとにした。

とりあえず次は、文字コード変換の機能を実装することにした。そもそも「祐筆」は「主筆」での文字コード変換機能の実装を念頭に置いて作ったものなのだ。今まで後延ばしにしてきてはいたが、そろそろ実装しなければならない。

だが、ファイルで使用されている文字コードを自動認識する機能は、とりあえずおいておくことにしよう。何か、難しそうだから。

2006/06/06

検索・置換機能の変更

主筆」は昨日に引き続き、検索・置換処理を変更している。

実をいうと、今までの実装では、「置換」ボタンは現在選択されている範囲を削除して、置換後に設定する文字列を挿入していただけであった。

一応それでも、「検索」と「置換」を交互に連続して押下する場合には、そのほかの通常のエディタと同じような振る舞いになる。

しかし、そんな安直な実装だと使いにくいので、ちゃんとすることにした。今現在は修正を行っている最中である。


ところで、そろそろ近い将来にTOEICの試験を受けなければならないらしいから、久しぶりに英語のお勉強をやろうと思う。

とりあえず手始めに、英文のBlogを再開することにした。一応これだが、余り読むに値するようなもんではないと思う。

2006/06/04

主筆の開発を再開

久しぶりに、「主筆」の開発を再開することにした。

とりあえず、検索・置換の周辺をいじることにした。あの辺は今ひとつ機能が不足していて不便だからだ。

今日実装したのは大文字と小文字を同一視した検索だ。一応正規表現による検索に対応している都合上、気合いと根性があれば大小文字を区別しない検索もできないことはないのだが、しかし、それはさすがに現実的ではない。

そういうことで、正規表現ライブラリに手を入れて、然るべき機能を実装しておいた。

ところで、俺が苦労して作った正規表現ライブラリは、その目的の都合上、検索対象のデータ型、及び、検索用の文字列のデータ型には依存しないように作ってある。

つまり極端なことを言えば、”文字列”は文字の列でなくとも、レコードのような複合的なデータ形式であったとしても、対処できるようになっている。

だがしかし、”大文字”・”小文字”を意識して処理を行うようにするとなると、上記の性質が失われることになる。どうするか。

とりあえず現状では、”文字”型のクラスが==演算子をオーバーロードすれば、いかなる型でも対応できるものとしている。俺の正規表現ライブラリを紹介しているページでも、同じ方法でもってして大小文字を同一視した比較を行っている。

「主筆」でも、理論上は同じ事をやれば然るべき機能を実装することはできるのだが、しかしそれは大変だ。「主筆」の内部のデータ形式を大幅に変更する必要がある。

どうするか。風呂に入りながら考えた。

結局、ごく単純な方法で対処できた。外部から、比較用の関数オブジェクトを指定できるようにすればいいだけだった。良くある方法だ。

まぁ一応、これでめでたしめでたしということなのだが、それに関連して一つ。

ForteC++6.0だとクラスのメンバ関数をテンプレートにすることができなかったのだが、Sun Studio 11だとできるようになっていた。

一応、コンパイラもぼちぼちと進歩しつつあるようだ。

まぁ、それだけなんだが。

2006/06/03

メール

久しぶりにメールを見てみると、珍しく何通かメールが来ていた。

まず1通はVectorのダウンロード数の通知。例のごとく情けないほど少ないから、ダウンロード数はもう書かない。

あと、何かの広告が2通。これは無視して捨てておいた。

変わったところでは、Vectorからもう一通来ていた奴、うちの所のblogを使えという広告があった。

なにやら、課金機能だのユーザ管理機能だのがあるだ何だと抜かしていはしたが、しかし、申し訳ないが俺のblogにはそんな機能は全くもって必要ない。前々から書いている通り、このblogはほとんど誰にも読まれることはない。毎日毎日貴重な自由時間の内のかなりの時間を割いて書いているにもかかわらず、その努力は一向に報われること無く現在に至っている。

無償で公開していても誰にも読まれることのないblogなのに、それを有償にしたら一体誰が読むというのだろうか。例え無料であったとしても、登録制にしただけでも読者は絶無になるだろう。

そういうことで、各種の利点の一切を使わないのであれば、強いてわざわざblogを移動する理由は何一つ無くなる。だからこのままここに居座ることにしよう。

そして今一通来ていたメールは、googleのアクセス解析が使えるようになったとか、ならないとかいうメールだった。

googleという所は、ずいぶんな殿様商売をやっている会社で、俺としてはこんな所の商品は、できれば利用したくない。だがしかし貧乏サラリーマンとしては致し方のないことだ。背に腹は代えられぬ。

とりあえず、いろいろな意味でムカムカしながらも、何とかアカウントの設定をしておいた。後は気合いと努力と根性と忍耐と体力で、アク解用のコードを全ページに埋め込むだけだ。

あぁ、面倒くせぇ。

2006/06/02

仕事

ぶっちゃけて言って、俺はほとんどまともに仕事をしていない。

一応会社員であって、ちゃんと毎日定時に出社してはいるのだが、することがない。暇で暇で仕方がないのだ。新手のリストラ策なのかと思ってはいたのだが、どうやら本当に仕事がないらしい。

それなのに不思議なことに、最近、人事的な評価のランクが一つ上がって、それにともなって給料が上がったらしい。茄子もちびっと増えたらしい。

企業とは不思議なものだ。朝会社に行って、PCの前に座って、一日寝ているだけで、なぜ給料が増えるのか。

だがまぁいいだろう。給料が下がったわけではないのだから。

とりあえず、増えた茄子を使ってUPSの一つでも買ってみることにしようか。電源が不安だしな。

2006/06/01

画面のキャプチャ

おもむろにSolarisでの画面のキャプチャと、インターネットで公開できるようにする方法について書いてみる。

Solarisで画像をキャプチャするのに、俺はCDE付属のイメージビューアを使っている。


背景を右クリックして、スナップショットを選択すると、こんな画面が表示される。


で、このツールを使って画面をキャプチャすると、こんな感じになる。


問題はここから。キャプチャした画面はファイルに保存しなければならないのだが、一体何の形式で保存すればいいのか。

この後、画像に対して縮小などの加工を行いたいから、画質の劣化無く保存したいと思う。でもって俺の場合、画像の加工はWindowsで行いたいから、Windowsで扱うことができる形式で保存したい。

イメージビューアで保存できる形式の内、そういった需要を満たすのはTIFFしかない。TIFF形式で、圧縮を「なし」、カラーを「フルカラー」で保存してあげればいい。


そうしてキャプチャした画像がこれ。


その次に、キャプチャした画像をインターネットで公開できるように加工することを考える。

インターネットで公開するためには、GIFやJPEGに変換する必要がある。それに、Webサイトに使用できる記憶容量の問題とか見る人の利便性とかも考えれば、ファイルサイズは極力小さくする必要がある。でもって、画質はできるだけ落としたくない。

その為に俺は、Visual Studioを買ったときにくっついてきたFront PageにくっついてきたImage Composerというソフトを使っている。なぜこのソフトなのかといえば、それは単に俺のPCにインストールされていたから。


ここで画像をGIFにすることを考える。

まずは、さっきSolarisでキャプチャしたファイルを、何らかの方法でWindowsPCに持ってくる。で、Image Composerでそのファイルを開いて、メニューの中の「ツール(T)」-「色の選択(K)...」を選択する。そうすると、こんな画面が表示される。


ここで「新規作成」ボタンを押す。パレット名は何でもいい。ディザ処理の方法はべた塗りを選択しておくといい感じになるようだ。


OKボタンを押すと、「色の選択」ダイアログがこういう風になる。


「色の作成」ボタンを押すと、下の絵のようなダイアログが表示される。ここで色数を256、作成元は選択範囲を選択して、追加ボタンを押す。


そうすると、「色の選択」ダイアログのパレットに、必要な色が登録される。で、OKをおしてこのダイアログを閉じる。


後はGIF形式で保存すればいい。ただそのとき、画面下部にある「色の形式」のところで、さっき作成したパレットを指定してあげる必要がある。そうしないと画面が汚くなる。


まぁ、大体こんなもんだ。

キャプチャした一枚の絵を公開するまでには、結構手数がかかっている。個人の趣味でやっているとはいえ、我ながらご苦労なことだとつくづく感心せざるを得ない。

その割に報われないのだが。

2006/05/31

倦怠期

プログラムを作っていると、やる気が亢進して作業がどんどんはかどる時期と、停滞してほとんど何も手に付かない時期がある。数分ないし数時間単位の、周期の短い変化もあるが、数日から長ければ数ヶ月単位の波長の長い変化もある。

一体どういう心理作用なんだか分からないが、倦怠期にはいると進捗がはかばかしくなく、自分でもほとんど止まっているのではないかと思える時もある。

で、とうとう嫌になって放り出したりする事もあるのだが、それがまた気分が変わってきて、以前投げ出したプログラムを引っ張り出してきて、いじりだしたりすることもあるから不思議だ。

倦怠期とは言っても、必ずしもプログラミング全体が嫌になるというわけではない。ある特定のプログラムを作るのが嫌になるのだ。嫌になるというより、自分の気持ちが満たされてしまうと言った方が正しいか。

例えば今なら「主筆」をいじるのが嫌になってきたとしても、それはプログラミングという行為全てが嫌になったのではなく、「主筆」をいじるのが嫌になったに過ぎない。他のプログラム、例えば何らかのゲームとかの開発にのめり込むこともある。

各プロジェクトごとに、欲望だか向上心だか知らないが何かバイオリズムのような物が、非同期的にかつ周期的に変動している。

別にだから何だというわけでもない。ただ、あるプログラムに対するモチベーションが下がったときに、他のプログラムに移ったとしたとき、その作業内容が元のプログラムにも反映されるようにプログラムを作れば、作業効率は向上するのではないかと思う。

要は再利用性の高いプログラムを作ると言うことに他ならないのであって、今更いうまでもないことではあるのだが、プログラミングの作業効率という観点からすれば、必ずしも再利用するのはプログラムに限った話でもないように思う。

技術の習得であっても、今後のプログラミングの役に立つライブラリやツールでもいい、とにかく費やした作業時間がその後で有効活用されるような活動をしたいものだ。

人生、使える時間は限られているのだし。

2006/05/30

Solaris8版主筆のパッケージの作成

Solarisのパッケージの作り方を、曲がりなりにも書いて公開したから、今度は主筆のパッケージの作成に取りかかっている。

一応、昨日の夜だけでSolaris8でコンパイルした奴のパッケージを作ってみた。とりあえず、まだ公開するつもりはないから、あんまり深い事を考えずにやってみただけなのだが。

とりあえず、実行したときの画面

まぁ、当たり前だが、特に問題はない。だが、いくつか決めるべき事項があるようだ。

1.インストール先
Solarisの習慣では/optに入れる事になっているのだが、Linuxの習慣では/usr/localである。中には/usr/localでなければ受け付けないという人もいるようだが、しかし、ここはSolarisの習慣に従っておこう。何分、このソフト自体がすでに「Solaris用」を名乗っているのだから。

2.パッケージ名
pkginfoファイルの説明を読むと、「パッケージの名前の先頭4文字はベンダを識別する文字列にするべき」と書いてある。

だが、他のソフトのパッケージを見る限りでは、必ずしもこの習慣に従っているとは限らないようだ。それにそもそも「ベンダを識別する文字列」は一体何にしたらいいのだろうか?

Sunはなぜか知らないが"SUNW"という文字列を使用している。じゃ、俺はどうするか。ハンドル名"nabiki_t"そのままでは長すぎるから、ちょっと縮める事を考える。

候補としては"NBKT"・"NABI"・"NABT"なんかが考えられる。とりあえず、既存の会社と重複するのは不可という事で、"NABI"は消滅する。

"NBTK"と"NABT"が残ったが、どちらがいいのだろうか?

3.インストール先フォルダ名
Sunのソフトは、/optの下に"SUNWxxx"という名前でインストールしている。その流儀に従えば"NBKTsyuhitu"ないし"NABTsyuhitu"になるのだろうか、ちと長いような気もする。それに、他のソフトは大概にして、そういった流儀はとっていないようだ。

ここは単に"syuhitu"とするべきなのだろうか?

4.CDEの設定
技術的には、インストールした時点で強制的にCDEの設定を行ってしまう事ができる。全ユーザにこの設定を強制する事もできる。

だが、本当にそれでいいのだろうか? 個別のユーザの意志に任せた方がいいのではないだろうか?

しかし、このソフトのターゲットはどう考えても個人ユーザだ。それに、パッケージ化した時点で、インストールするのにroot権限が必要になってくる。

そう考えると、CDEの設定をやってしまってもいいような気がしなくもない。 どうするべきだろうか?

5.manページの作成
一応、用意するべきなのだろうか? SolarisではPDFは余り便利とは言えない形式だしな。


大体以上のような事が未定のまま残っている。第16版公開までには決めておこう。

2006/05/29

ビデオデッキ

最近、ビデオデッキの調子が悪い。

録画したテープを見ていると、時々音と画面が乱れる事がある。どうやら、録画中に何かがあって、おそらくはテープの回転速度が遅くなって、映像が乱れるのではないだろうか?

原因は何なのか? 一番単純な答えとしては、ビデオデッキそのものが壊れたという事なのだが、諸般の事情でそれは認めたくない。

とりあえず、他に原因を考えてみようか。

最近、寮の電源設備が不安定な事を考えると、録画中ないし再生中に瞬断が発生しテープ走行速度が不安定になっている、という可能性もある。

あるいは、テープが痛んでいる、アンテナ系統の不具合なども考えられる。

だがしかし、比較的新しいテープを使っても同様の症状が生じることから、テープの痛みは否定される。また、音と映像の乱れの様子から、アンテナ関係の問題とも考えにくい。

映像の乱れが必ず同じところで発生するのであれば、乱れた映像がテープに録画されているためであると言える。だが、必ずしも常に同じところで乱れるとは限らない。が、逆にいつも同じところで乱れる場合もある。

つまり、不具合は録画・再生の両方で発生しているという事だ。

以上の考察からでは、ビデオデッキ自体の不具合の可能性は否定されないが、電源設備の不調も否定できない。

どうするのが一番いいのだろうか。

俺としては、買い換えるのであればblu-rayディスクかHD-DVDのどちらかにしようと思っている。今更DVDのレコーダーを買う気は毛頭無い。

だから、今この時期にビデオデッキを買い換えるのはなんとしても避けたいのだ。

一番少ない投資で最高のパフォーマンスを得るにはどうするのが一番いいのだろうか?

2006/05/28

英文

英文とはいえ、人間が書いている限り間違いもあれば不明瞭になる場合もあるだろう。文章の運びや言い回し、単語の選択など、読みにくいものになる場合もあるだろう。

Sunのマニュアルを読んでいて、どうにも意味がつかみかねる文章が多くて、今まで大分苦労してきたのだが、この苦労は必ずしも俺の脳味噌の働きが鈍いせいでもないようだ。

酒(ブランデーだな)の勢いを借りて、声を大にして言わせてもらおう。Sunのマニュアルは分かりにくい。文法がむちゃくちゃだ。

日立のマニュアル(仕事でよくお世話になる)も分かりにくい事で有名だが、しかし、アレはまだ文法に間違いはない。一文が長かったり、係り受けが複雑だったり、曖昧な言い回しだったりして、直感的に理解しにくい文章ではあるが、しかし日本語ではある。

だが、Sunはどうだ。もう一度言おう。あれは英語ではない。一体何なんだ。あの片言英語は。おまえらそれでもアメ公か。俺の書いている英文とすっとこどっこいじゃねぇか。

外部に公開する正式なマニュアルなら、文法上のミスやタイプミスぐらいちゃんと添削しろよ。仕事だろうが。


それに比べると、jpeglibに付いてくるREADMEの英文は分かりやすかったな。あの文章は不思議と理解しやすかった。読んでいると、何となく俺の頭が良くなったような気になってくる。平易で明確に書いてあった。

俺も下らないWebサイトを作っている身として、あるいは社会人として文章を書かざるを得ない立場にいるものとして、分かりやすい文章を書くように心がけたいものだ。

だがしかし、文章の書き方は「心がけ」だけでどうにかなるもんではないんだかな。事によれば、プログラミングよりも深遠なテーマだしな。……練習あるのみ、なんかいな。やっぱり。

2006/05/27

pkgmk

pkgmkコマンドのmanページの英文がマジで意味不明。

Prototypeファイルに記述したパス名と、-bや-rに指定したパス名の関係がさっぱり分からない。

似たようなものが複数あって、そいつらが複雑に絡み合って、最終的なパス名が決定されるから、ただですら分かりにくいのだが、それがあのトンチンカンな英文のせいでますます意味不明になってる。

どうやら、いくらか省略した言い回しをしているらしい。そのせいで、俺のおつむでは理解できなくなってる。

ちゃんと分かりやすい文章を書け、馬鹿野郎。

仕方がないから、Prototypeファイルのパス名にフルパスを指定した場合と相対パスを指定した場合、-bと-rのそれぞれを省略した場合・フルパスを指定した場合・相対パスを指定した場合、の全ての組み合わせをやってみて、どういう結果になるのかを確かめてみた。

すんげぇ疲れた。

それもこれも、mamページを書いた奴が悪いんだ。アメリカ人ならちゃんとした英文を書け、このタコが。

2006/05/25

Solaris8版主筆

ようやくSolaris8上で主筆をコンパイルした。せっかくだから、このままパッケージ化してSolaris8対応版として公開してもいいのかも知れない。

だが、やっぱりやめておこう。今するべきはパッケージ化の方法をまとめてWebに公開することだ。やり始めた仕事は完遂したい。

しかしそれにしても、英文が分かりにくい。英語である上に、言っている事の意味が分からない。もう疲れた。

2006/05/23

PV数とクリック数

このところ、WebサイトのPV数は順調に増えつつある。4月後半に多少落ち込んだような気もしたが、それは一時的な傾向に過ぎなかったようだ。

だが、広告のクリック数は増加していない。すなわち、クリック率がPV数に反比例して減少しつつある。

それでは元も子もないのだが。誰も好きこのんで只で情報を公開しているわけはないのに。

まぁ、今のところは確率的な問題から多少少なくなったように見えるだけ、という可能性も捨てきれないし、おそらくはそうだろうから、しばらく様子を伺ってみるつもりではいる。しかし、抜本的対策としてのクリック率増加作戦について、考えておいても損はないだろう。

クリック率を増やすにはどうしたらいいか。

いろいろあるのだろうが、一番単純安直なのが、広告が広告と分からないよう、コンテンツの中に紛れ込むようなデザインにする事だ。要はだまし討ちという事だ。

だが、それは俺の信義に反する。許し難い。

広告数を増やす、というのもあるのだろうが、あんまり数が多いと嫌われる危険性がある。最近は、むしろ逆に広告数の削減を図っている。この間、何ページか広告を削った。

配置や色・形・大きさなどによって、多少クリック率が変化するらしいのだが、いろいろと実験するだけの気力がない。

一日当たりのPV数がある程度あるのであれば、そういった実験もやりやすいのだろうが、数が少ないと時間を掛けて傾向を見極めなければならないため、気力が萎える。

結果が出るまで数ヶ月かかるような実験をやる気にはなれない。


……やはりPV数そのものを増やすのが一番手っ取り早い対策という事になるのだろうか。

2006/05/22

再インストール

X86版Solaris10の調子が悪くなってきたから、というか、環境を破壊してしまって元に戻らなくなってしまったから、再インストールしておいた。

とは言っても、元々ディスプレイ周辺の調子が悪いから、再インストールしたところでそれ程よくなるわけではないのだが。

起動するととりあえずはログイン画面が表示される。ところが、そこからログインしようとすると、画面が真っ暗になって、何もできなくなってしまう。その他の状況から鑑みると、どうも起動してはいる様なのだが画面だけが死んでいるらしい。

ちゃんと画面を表示させるには、一旦コンソールでログインして、kdmconfigで設定をし直す必要がある。しかし、kdmconfigのデフォルトの設定は、ちゃんと前に設定したとおりの値になってる。なんで起動するたびにkdmconfigが必要なのかどうにも分からない。

単純に考えればグラフィックボードのドライバか何かがちゃんとインストールできていないからなのだろうが、しかし、ログイン画面はちゃんと表示できている。なぜなのだろうか?

まぁ、余りx86版の奴は余りまともに使おうという気もないし、そもそもSolaris10を走らせるにはCPUが遅すぎて使ってられないしな。

もし今度PCを新しく買い換えるような事があったら、ちゃんと使えるように設定してみる事にしよう。

2006/05/18

今後の予定と現在の作業内容

主筆」第16版に向けて何をするか。

必須となるであろう機能はいくつか思い浮かぶが、とりあえず実装したいのは

  1. 右端で折り返し

  2. 改行コードの表示

  3. ルーラーの表示

  4. 行番号の表示

  5. Undo/Redo中の中断ボタンの表示

  6. ウインドウの分割表示

  7. パッケージ化



この中でも1と6は難易度が高い。データ構造やプログラムの構造をかなり大きく変更しなければならない。だが、7は簡単にできる。そもそもこれはプログラムの問題ではない。

pkgaddやpkgrmで追加や削除ができるようにするのは、前々から考えていた事ではあるが、先送りにしてきて現在に至っている。この辺でそろそろ対処しなければならないと考えていた頃だ。いい機会かも知れない。

それに、パッケージ化の方法をまとめてWebページに追加するのもいいだろう。そういう事で、現在はパッケージ化に関わるmanページやwebページを頑張って読んでいる。

日本語のページでもパッケージ化について書かれたところがないわけではない。だが、そういったところは、大まかな概略について書いてあるだけだ。後発の俺がそいつらに負けないようにするには、できるだけ詳細な情報を提供しなければならない。まぁそこに勝機がある訳なのだが。

いずれにせよ、今現在はパッケージ化の方法を調べている最中だ。

2006/05/16

主筆第15版を更新

結局、この間のバグを修正した奴を第15版として公開しておいた。放置しておくには余りにも重篤なバグだから更新せざるを得ないし、かといって第16版とするのは面倒くさい。

一応、更新する際には必ず版番号を上げるというルールでやってきたのだが、今回は例外としておく事にした。とは言っても、前例が無いわけではないのだが(第5版でやってる)。

「主筆」は、一応Vectorでも公開しているのだが、そっちは放置しておく事にした。バージョン番号を変えていないという都合と、実際に更新されるまでにはタイムラグがあるとか何とか、いろいろと面倒だからやめておいた。Vectorの方からダウンロードした人には、諦めてもらうほか有るまい。

そういえばVectorといえば、「主筆」が公開される区分がまたしても変わった。今まではSolaris > SPARC用のところにあったのだが、今回からはUNIX > 文書作成 > テキストエディタに移った。

元々はUNIX……の方にあったのだが、それがいつの頃からかSolaris……に移されて、それが元に戻ったという形になった。別に俺としては変えてくれとか、移してくれといった覚えはないのだが、勝手に変えられた。

一体どういうルールで決定されているのだろうか? もしかしたら担当者の腹一つで決定するのだろうか? まぁ、別にどうでもいい事だが。

2006/05/15

アイコン化解除

Motifでアイコン化を解除するには、
Display *pDisplay = XtDisplay( シェルのウィジット );
Window window = XtWindow( シェルのウィジット );
XMapWindow( pDisplay, window );
とすればいいらしい。

ところが、この直後に
XSetInputFocus( pDisplay, window, RevertToParent, CurrentTime );
とすると、前と同じくBadMatchが生じる。

詳しいことは知らないが、どうやらXMapWindowの呼び出しが処理される前にXSetInputFocusが実行されるのが原因らしい。

とりあえずXmUpdateDisplayという、溜まっているイベントを先に片づけさせる関数を呼んでやると、うまくいくようだ。

つまり、結果としては
Display *pDisplay = XtDisplay( シェルのウィジット );
Window window = XtWindow( シェルのウィジット );
XMapWindow( pDisplay, window );
XmUpdateDisplay( シェルのウィジット );
XSetInputFocus( pDisplay, window, RevertToParent, CurrentTime );
となるらしい。

とりあえず、覚え書き程度に。

アイコン化解除

昨日見つけてしまったバグを潰したいけど、どうやって対処したらいいのかが分からない。

現在は、主筆サーバからイベントを受け取ったときにXSetInputFocusを呼び出すようにしている。ところが、ウインドウがアイコン化されているときにこれを呼び出すと失敗する。

対処としては、アイコン化されているか否かを調べて、もしアイコン化されていた場合にアイコン化を解除して、その後にXSetInputFocusを呼んでやる、という事になるだろう。

ところが、どうにもアイコン化されているか否かを調べる関数と、アイコン化を解除する関数が分からない。そういったものが有るのか無いのかも分からない。

アイコン化する関数だったらXIconifyWindowというのがある。じゃなぜその逆がないのか。他ので簡単に代用できるからなのか、今更説明するまでもないほど簡単な事だからか。

いずれにせよ、どうにか対処しておかないとまずい。どうすればいいのだろうか?

2006/05/14

バグ

いつもの事だが、またしてもバグの存在を発見してしまった。というより、なぜ今まで気が付かなかったのかが不思議に思える。

ウインドウを最小化している状態で、そのウインドウが開いているファイルを開こうとすると、主筆が終了してしまうのだ。

別の言い方をすれば、アイコン化されているときに能動的にフォーカスを取得使用とすると、BatMatchとか何とか言うエラーが発生して、プロセスが終了させられてしまうのだ。

もうね、もうね、俺はアホかバカかと。何で今まで一度も、アイコン化されたときの挙動を調べていなかったのかと。

まぁ、嘆いていても始まらないから、とにかく修正する必要がある。だが、その後はどうする?

第十五版のままひっそりと更新しておくか、急遽第16版を公開するか、しばらく放置しておいて、いくつかのバグをまとめて修正してから第16版として公開するか。

なんだかんだ言って、リリース作業は結構手間のかかるものだし、一つ版を上げるとなると、いろいろとやらなければならない事がある。そうすると、俺的にはしばらく放置するやり口が一番魅力的に思えてくる。

だが、明々白々なバグを放置しておくのは「主筆」の将来に悪影響を及ぼす恐れがある。しかしながら、そもそも「主筆」には将来性などというものがあるのかが疑わしいし、どうでもいいといえばどうでもいい。

最近は、機能の追加よりも安定性の向上の方が重要なような気がしてきたところで、どこかで綿密なテストを行おうと考えていた。

だからここは、テストを行って、ある程度バグを潰してから第16版として公開するようにしようかと思う。

それまではまぁ、放置することにしよう。

2006/05/13

Solaris8へのSun Studio 11のインストール

この間、Sun Studio 11のリリースノートとやらを見てたら、その中にSun Studio 11ではbashが必要になる、という記述がある事に気が付いた。

だが、インストール対象のSolaris8にはbashを入れていなかった。だから失敗していたらしい。

一応、試しにbashを入れてからSun Studio 11をインストールしてやったら、あっさりと成功した。

今までの苦労は一体何だったのか。

2006/05/11

気持ちはわかるが

アニメの録画予約に失敗したという事で、テレ東に脅迫状が送られてきたらしい。4月26日は水曜日だから、おそらく「いぬかみっ!」か「.hack//Roots」だろう。

放送時間の変更のせいで録画予約に失敗したときの、やり場のない怒りと悲しみ。それはわかる。分かるのだがしかし、こういう事をされると、世のオタク達のイメージの低下につながるからやめてもらいたい。ただですら世間から冷たい目で見られ、不審人物扱いを受けているというのに、それをますます悪化させてどうする。


と、まぁ、それはいいとして、ここで一つ、こういった悲劇に遭遇しないための俺流の自衛策を紹介しておく。

1.放送時間変更への対策

通常、前倒しになる事はない。変更されるという事は必ず遅れるという事だ。だから、放送時間が変更される危険性がある場合は、あらかじめ長めに予約しておく事だ。興味のない番組が余分に録画されたところで、別に害はないのだから。

問題は、どんな番組が延長されるか、ということだ。

まず、スポーツ全般は延長される危険性が高い。野球はいうに及ばず、それ以外のものも伸びる可能性がある。例え卓球であったとしてもだ。

それに、まれに発生する事として、ニュース番組が伸びる事がある。何らかの突発的イベント、ちと古いが「ブッチホン」みたいな事象や、出演者(政治家とか)が長くベラベラとしゃべりまくった場合なんかには、放送時間の延長が発生する事がある。

まとめると、「生放送の番組は危険」という事になる。

2.テープの不足

録画予約をする前には必ず巻き戻す。というか、ビデオの場合は、見終わったら巻き戻す癖を付けておいた方がいい。

また安全策として、長めのテープを用意する。無論、録画予約をする際には、テープが不足しない事を確認する。

3.ビデオデッキの時計の精度

常に確認する。

4.録画する日付の確認

通常、深夜アニメを録画する場合、録画する日付は「明日」になる。ところが、深夜12時を回ると、その日付は「今日」になる。

この当然の事が、時々罠になる。つい、いつもの癖で「録画する日付は今日+1」で処理してしまう事があるからだ。

だから、録画する日付をちゃんと確認すると共に、現在の時刻が深夜12時を回っているか否かを確認する必要がある。

同じ要領で、12月31日と1月1日の境では、年号の確認をする必要がある。

5.チャンネルの確認

意外に間違えやすい。

6.午前・午後の確認

大概にして、午前・午後の表示は文字が小さい。十分注意する必要がある。

7.指さし確認

かっこわるいが、どうせ誰も見てやしないのだ。ちゃんと指さし確認をするべきである。

大体、こんなところだろうか。

今時、ビデオデッキで録画するというのもアレなんだが、まぁ、経済的問題から仕方がない事もあるしな。

2006/05/09

次の更新

多少遅れて昨日の夜になってしまいはしたが、とりあえずHHttpの第6犯を公開しておいた。

次は一体どこに手を付けようか。とりあえず主筆は第15版を公開したばかりだから、しばらく休むとするか。ここ最近更新していないものとして「祐筆」「くず箱」といった物があるのだが、今更これを更新しようという需要が俺の中に存在しない。

どうしても暇だったら多少手を加えてもいいのかも知れないが、必ずしも暇だとは言えない。それどころか、まとまった時間を取る事ができない状況にある。

ではどうするか。何もしないで放置しておいたら、今までの努力が水の泡と消えてしまう。

そういえば、最近は「Sun Studio 11」の解説ページを書いていなかったような気がする。

まぁ、これとてまとまった時間が取れないとなかなか書くのは辛いのだが、別に不可能というわけでもない。毎日ちょこちょこと書き続けていれば、いずれできあがるだろう。


仕事が微妙に暇なようで忙しい感じで、なぜか早く帰れないもんで、ソフトやwebページの更新が滞っているのだが、何とかして少しずつでも更新するようにしていきたいものだ。

2006/05/08

HHttpの更新

「主筆」第15版を公開してすることが無くなったから、勢いでHHttpを更新しておく事にした。このソフトは以前はVectorで公開していたのだが、余りにも人気がないから削除したという経緯があるソフトだ。

自分で使う事を目的に自分で作っただけのものなのだから、別にわざわざ公開しなくてもいいし人気が無くてもいいのだが、とりあえず公開するソフトの数を増やすという目的の為だけに公開している。

だから、自分の手元にあって使っている奴のバージョンが上がっても、バージョンアップ版を公開しないで放置していたのだが、昨日暇だったのに任せて更新する事にした。

今回は、中身のサーバの部分はほとんど変わっていない。一番大きく変化したのは、Windows用のインストーラと設定用のツールの部分だ。今まではサーバの機能の一部分にしか対応していなかったのだが、それを拡張した。

まぁ、貴重な休日を一日費やしたとて、何の利益にもならないのだがな。ダウンロードする奴がいるわけでもなし。


ところで、面白いのがgoogleで"hhttp"で検索すると25,500件もヒットするという事だ。もちろん、俺のHHttpがヒットしているのは、一番最初の1件だけだが。

それ以外の約25,500件は"http"のタイプミスか、あるいは意図的にそうしたものらしい。httpを意図的にttpとするのはある様だが、hhttpとするのもあるのだろうか?

別にどうでもいい事だが。

2006/05/06

1ページ追加

あんまり書く事もないので、Blade100に関する駄文を書いておいてみた

本当は、この内容以外にも玄人志向のCHANPON-3とかいうカードを接続した場合の話を書きたかったのだが、途中で嫌になった。

一応、接続しては見たものの、当然の事ながらそのままでは動くわけがない。ドライバを見つけてきて入れるほか無い。

CHANPON-3は、INITIOのSCSIとc-MediaのサウンドとNECのUSB2.0が一つになっただけの代物なので、基本的にはそれらのドライバを別々に入れてあげれば動作するはずである。だが、そのドライバを見つける作業が辛い。

たとえあったとしても、ちゃんとインストールして、正しく動作させるまでの道のりは遠く険しい。

自分にとって何のメリットもない事に、不要な時間と精力をつぎ込むのは余りにも馬鹿らしいし疲れるだけだから、途中で投げ出してしまった。で、結局その話は書かない事にした。

そうすると、全体としては余り面白い話は無くなってしまうのだが、やっぱり他に書く事もないし、とりあえずCHANPON-3は無しのまま公開してしまった。

まぁ、俺が飽きたら消そうか。

2006/05/05

第15版公開

逡巡したあげくに、結局Solaris10用バイナリだけで第15版を公開しておく事にした。後はWebページの方をそれに合わせていろいろと修正するだけだ。まぁ、この作業も結構負荷が大きいのだが。

主筆のアップデートとは全然関係ないのだが、昨日秋葉原に行ってみた。金がないから何も買う予定はなかったのだが、とりあえず運動と暇つぶしを兼ねて行ってみた。せっかく片道150円でいけるのだから。

そこでの一幕なのだが、俺が駅について昼飯喰って、電気街に繰り出した時の事だった。どっかの変な奴、カメラ持ってたからマスコミ関係の人間かも知れないし、あるいは単なるお上りさんなのかも知れないが、とにかく「秋葉原以外のところ」では普通一般に見られる若い男の集団に話しかけられた。

「メイド喫茶がどこにあるか知ってますか?」

まず、質問の内容が気に入らない。俺はそんなに秋葉系のオタクに見えるのか? そーゆー雰囲気を全身から発散しているとでも言うのか?

事実そうなのかも知れない。だがしかし、気にくわない。気分が悪いものは気分が悪い。

次に、質問の仕方が気に食わない。

俺の正面から近づいてきた奴は、俺の進路を絶つように前に立ちふさがり、突然話しかけてきやがった。しかも左の方にいた奴はカメラを俺の方に向けていやがった。

一体何なんだ、連中は。どこの田舎ものかは知らないが、余りにも常識というものを知らなさすぎる。人を動物扱いするな。そんな聞かれ方をされたら、例え知っている事であろうとも、まともな答えを返すわけがないだろうが。馬鹿が。

だが、何が一番気分が悪いかって、そんな連中に対して丁寧に「いやぁ知らないんで」と答えてしまった事だ。本来なら文句の一つも言ってやるのが礼儀というものだろうが、少なくとも無視して通り過ぎるぐらいの事はするべきだったのだろうが、とっさにそれができなかった。そんな弱気な俺自身に腹が立つ。

社会人として、強気で生きる事を日々実践しているはずなのに、いざとなるとそれができない。そんな自分が歯がゆく思う。

まぁ、主筆第15版の公開とは何の関係も無いのだが。

2006/05/04

Solaris8版バイナリの作成

そろそろ嫌になってきた。Forte C++ 6.0だとどうにもうまくコンパイルできない。できたと思ったら、起動時にプロセスがcoreを吐いて落ちる。

休日も残り少なくなってきたことだし、ここは一旦諦めて、今まで通りSolaris10版バイナリだけにして公開しようと思う。(それにしても、起動できないというのは気になるな。プログラムのバグなのだろうか? あるいはコンパイルがうまくいっていないだけなのだろうか?)

そうするとCD-RWドライブを買った主目的が達成できなくなることになるのだが、まぁいいか。バックアップ用に使いでがあるのだから。Solaris8でちゃんと書き込みができるかどうか心配だったけど、どうやら問題なくできるみたいだし。

余談になるけど、一応メモ代わりにCD-Rの書き込み方をここに書いておこう。

まず、書き込みたいファイルをISO形式に変換する。
mkisofs ファイル1 ファイル2 > isoファイル

CD-Rに書き込む
cdrw -i isoファイル

で、良いらしい。とりあえず、ちゃんと読み込める。

改めてみると、せっかくのBlade100の見てくれが酷いことになっているが、まぁ致し方あるまい。どうせ中身にもいろいろと手を加えてあって、もはや中古で売れるよな代物じゃないし。こうなったら徹底的にいじり倒してやろう。

2006/05/03

Forte C++ 6.0

いろいろ努力したが、結局Solaris8にsun Studio 11をインストールする事ができなかったから、Forte C++ 6.0を使うことにした。だからそれに併せて、MakefileをSun Studio 11とForte C++ 6.0とで共有して使える様に修正している。

そこでいくつかの点でつまずいたことがある。

まず、静的ライブラリの構築だ。第15版では実行ファイルが「主筆クライアント」「主筆サーバ」「主筆」の三つに分かれたのだが、当然のことながらそれらで共有して使うクラスやプログラムが存在する。そういった奴らは一旦静的ライブラリにまとめてからリンクするようにしている。

静的ライブラリに構築には、俺は単にarコマンドを叩けばいいものだと思っていたのだが、どうもそれではいけないらしい。Solaris8上のForte C++でコンパイルしようとするとリンクで失敗する。いろいろと調べた結果、C++のインタフェースを持つ静的ライブラリは、CCで-xarスイッチを指定して作成する必要があるらしい。・・・知らなかった。

次はWorkshop VisualとX-Designerの非互換性だ。

当然だが、Forte C++ 6.0についてくるWorkshop Visualで作成されたファイルは、Sun Studio 11についてくるX-Designerで読み込むことができる。だが、その逆はできないらしい。

これについては未だ有効な解決策を見いだしていない。最終手段として、X-DesignerでコンパイルしてC++のコードを生成させてからForte C++ 6.0でコンパイルするという方法もあるのだが、それはさすがに面倒だ。

そもそも、俺としてはソースコードでの配布も考えているのだが、もし上記の作戦を採るとなると、著作権的にどうなのだろうか? それにやはり、配布するファイルなどの作成が面倒になりそうだ。

できることなら、Workshop VisualとX-Designerの両方で読み込めるファイルを作成したいものだ。これは可能なのだろうか?

2006/05/02

致命的欠陥

テストしていて気がついた。主筆に致命的欠陥がある。

テスト項目としては、起動時のウインドウサイズと表示位置に関するものだったのだのだが、そのときテストの一環として、主筆を連続して多数起動してみた。そうしたら、主筆を起動できる回数に制限があることに気がついた。

61回目に起動したときに、プラグイン設定ファイルが読めなくなってプロセスが落ち、62回目からはフォントセットの構築に失敗してプロセスが起動できなくなる。

状況の再現が困難な(というか体力的につらい)事もあって原因追及が大変だったのだが、何とか理由を見つけた。

結局原因は、ファイルディスクリプタの使いすぎだった。「主筆」では、エディタとしての主筆が標準出力や標準エラー出力に吐くメッセージを、主筆クライアントが起動されたときに使用された端末エミュレータに表示できるよう、標準出力や標準エラー出力の付け替えを行っている。ところが、それが原因でファイルディスクリプタの不足が生じるようになってしまったのだ。

対処としては、不要なディスクリプタを閉じるようにすればいいだけなのだが、それがどうも難しい様な気がする。状況が複雑で、まだ正確なバグの発生状況を突き詰められていないのだ。

だが、元々こういう事をやっているのはデバッグの為であって、基本的にリリース版では必要ない機能を実現するためなのだ。それを考えると、この処理を取っ払ってしまうという対処も考えられる。だから、問題の箇所をコメントアウトするだけでよしとしておいた。

この問題は第16版以降で対処することにしよう。

2006/05/01

リソース設定のバグ

リソースの設定を変更した場合のテストを行ってみたら、バグが何件かあった。

もっとも、普通いじる必要がないような所だったり、あり得ない値を設定した場合におかしくなるという物なのだが、一応、バグはバグなので修正しておいた。

この調子だと、他にも多数あるような気がする。でもまぁいいか。


Blade100にSolaris8をインストールする作業はだいたい終わった。だが、そこにSun Studio 11をインストールする段で詰まっている。何が原因なのかは判らないが、インストールで失敗する。中途半端な状態でインストールされてしまうのだ。

初めはロケール周辺の問題かと思ったのだが、必ずしもそうではないようだ。英語ロケールで英語版だけをインストールするようにしても、同じ問題が発生するようだ。

また、インストール時に-nodisplayスイッチを指定しても同じだ。(Solaris8だと、X端上でインストールすると-nodisplayの指定が無視されるらしい。だからtelnet経由でインストールしてみた。)

こうなったら、以前のForte C++を使うことにしようか。せっかく金を出して買ったソフトだ。死蔵しておくのはもったいない。

だが、Makefileとか何とか、いろいろと変更しなければならないことがあるし、Sun Studio 11とForte C++ 6.0を平行に使えるようにするのは何かと面倒くさいことがある。それに、せっかくだから新しいコンパイラでコンパイルしたいし。

悩ましい問題だ。