シェルスクリプト

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"

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

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

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

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

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

2006/09/26

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

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

まず、現在「主筆」はシェルスクリプト経由で起動するようになっている。そのとき、主筆クライアント(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次元空間上での二分探索(の様なもの)を実現することも不可能ではないのではないか。

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

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

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

はぁ、英文うぜぇ