Sun Studio 11のデバッガ

どこかのバグなのか、設定が悪いのか、仕様なのかは判らないが、Sun Studio 11で64bitのプログラムをデバッグしようとするとデバッガが落ちる。デバッグ対象のプロセスが落ちるのはあたりまえだとしても、デバッガが落ちるってのは一体何の冗談なんだよ。

似たような症状はForte Developper 6.0 Update 2でも発生する。Solaris8と9では特に問題ないのだが、Solaris10上だと64bitのプログラムはデバッグできない。だが、Forte6.0はSolaris10には対応していないから、多分そのせいなのだろうと思っていた（本来、Solarisは上位互換性は保っている。しかしデバッグは比較的特殊なものだから、きっとどっかに違いがあるのだろうと勝手に思っている。）

だが、Sun Studio 11はちゃんとSolaris10に対応している。そのはずなのにデバッグできない。一体なんなんだよ。

一応32bitのプログラムはデバッグできる。だからデバッガを使う必要がある場合は32bitでコンパイルしなおせばそれで事足りる。だが、もし64bitと32bitの差異による問題が生じたらどうしろと言うのだ。64bitでは落ちるが32bitでは動いてしまう場合はどうすればいいのか。それに、デバッグ時には32bitでリリース時には64bitと言うのは、業務アプリケーションを開発している場合は許容できない問題とはならないのだろうか。

何か設定が間違っているのだろうか。

以前、Forte Developper 6.0で同じ問題が生じたときに、デバッガにデバッガを当てていろいろと調べてみたことがある。そうすると、どうやらライブラリの参照か何かでこけているような感があった。64bit版のライブラリを参照するためのパスが、いくつか不足しているのではないか、という気がした。あくまでも気がしただけで、結局そのときは原因を突き止めることも正常に動作させることもできなかったのだが。

またどっかのアメリカ人にでも聞いてみようかしらん。答えは期待できないが。

もしかすると忙しいかもしれない

実は俺は結構忙しいのかもしれない、と言うことに最近になって気が付いた。

よくある話だが、最近になり仕様変更があり機能が追加されたし、三月末までにこの一年に関する報告書をまとめなければならないし、二月末までに月報を書かなければならないし、四月には情報処理の試験を受けるから、そのための勉強をしなければならないし、三月末には引越しがあるからその準備が必要だし。

そう、こんなblogを仕事中に書いているひまは無いのだ。それどころか、毎朝二時間ぐらいを深夜アニメを見るのに費やしていたり、誰にも使われることの無いソフトの開発に現を抜かしているひまは無いのだ。

だが残念なことに、俺には時間以上に集中力と言うものが不足しているために、すべきことがはかどらない。つい、yahooのニュースなどをみて時間を潰してしまう。

でもまぁ、別にどうでもいいか。報告書の一つや二つ、内容が多少おかしかったっても首が飛ぶわけではない。残り一月のわが世の春を謳歌することにしよう。

バグの原因

昨日は久しぶりに、TOEICを受験しに会社に出社したから体が痛い。バスと電車とタクシーを乗り継いで片道二時間だからな。さすがに疲れる。今日は何もする気がしない。

やる気がないとは言っても、何もしないでいるのも苦痛だから仕方がない。とりあえず「主筆」のバグを修正することにした。

結局、昨日書いたバグは「カーソルが描画されているか否かを管理するフラグ」を更新する式が間違っていたのが原因だった。今まではbool型のフラグCurDFlgの値を反転させるために「CurDFlg = ~CurDFlg」としていた。しかし、これでは一度真にしたら二度と偽にならなくなってしまう。だから描画がおかしくなっていた。だから「CurDFlg = !CurDFlg」としておいた。（元のコードの挙動を調べてみた。どうやらbool型の「真」の値はビット反転させても「真」になるらしい。でもって、数値として評価した場合は反転前後にかかわらず「1」になるらしい。へー）

だがここで疑問がある。なぜ今まではこれで動いていたのだろうか。このコードかなり古い物で、俺の記憶が正しければ第1版の当時からあったように思う。それなのに今までは正常に動作していた。なぜだろうか。

無論、自分で書き換えてバグらせた等ということはない。こんなところをいじる理由はない。じゃ、前と今とで一体何が変わったのだろうか。

よく思い返すと、一つだけ変わった事があった。それはパッチを当てたことだ。二、三日前にコンパイラのパッチを当てたのだ。確認したわけではないが、どうやらそれが原因のようだ。

つまり、今まではコンパイラのバグに依存したコードを書いていた、ということになるらしい。我ながら恥ずかしいと同時に恐ろしいと思う。十分気を付けているつもりではあるのだが。

しかし、この手のバグならコンパイラの警告か、あるいは「lint」みたいなツールで検出できるのではないだろうか。そう思ってコンパイラのフラグをいろいろと調べてみたが、どうやら細かい警告を出させる機能はないようだ。それに、付属する（？）lintはCにしか対応していないらしい。C++は使えないらしい。

おいおい。

仕方ない。なんか別の手を考えよう。あるいはもう少しSunCCのマニュアルを調べてみよう。該当する機能が全くない、というのも考えにくいし。

主筆の開発状況

誰も興味はないのだろうが、とりあえず近況報告。

以前検討したとおり、クライアント・サーバ・主筆の三者を用いた構造にすることで、排他制御を実装することにした。クライアント->サーバ、主筆->サーバの通信にはsolaris doorを用い、サーバ->主筆の通信には名前付きパイプを用いる。

かなり苦労したが、最近になりやっと排他制御を行うことができるようになってきた。クライアントでコマンドによりファイルを開くときも、主筆自体で新規にファイルを開くときも、同一のファイルが重複して開かれるのを防ぐことができるようになった。細かい苦労話はいろいろあるが、今は省略。

排他制御が実装できたのはいいのだが、新しく問題が生じた。なぜか知らないがカーソルの表示がおかしくなった。マウスで文字を選択してもカーソルが移動しない。画面をスクロールしてもカーソルが動かない。フォーカスが当たってないときはカーソルを表示しないようにしているのだが、それが表示されている。

なぜだろうか。

思い返すに、以前にもこんなバグに遭遇したことがあるような気がする。それに、どうもこのバグは既存の主筆をアクティブにしたとき（つまり、すでに開かれているファイルが他で開かれた場合）に発生するようだ。フォーカスの移動のやり方に問題があるのだろうか。

まさに一難去ってまた一難と言ったところか。

パッチ

以前からこのページにSun Studio 11のパッチが公開されていたことには気が付いていた。しかし、このパッチを当てようとすると、途中でエラーが出て失敗してしまっていた。だから今まで放置プレーしてきていた。
昨日の夜久しぶりに再挑戦してみたが、それでも結果は同じだった。シングルユーザモードでやってみても同じだった。
徒然なるまま吐かれたログを見てみた。するとなにやらゾーンがなんだとか、-Gのスイッチをつけろとか書いてあった。だからその通りに"-G"をつけてやってみると、ちゃんと入れることができた。
はじめからログを読まなかった俺が悪かったらしい。我ながらアホだ。
ところで、ゾーンって何ぞや。コンテナのことか？　なんでもいいが、名前を統一しろよ。判りにくい。

自販機

今朝用を足したとき、ふと見るといつもよりかなり色が黒い。すわ病気か、と思ったが、よく考えると昨日の昼飯はイカ墨スパゲティだった。もう数日様子を伺ってみようと思う。

いつも昼飯を食った後に立ち寄る自販機に「つーぶーオレンジ」というどう見ても果肉入りオレンジジュースとしか思えないものが、"あったか～い"のほうに入っている。あれはもともとホットで販売するべきものなのだろうか。

ある自販機にお汁粉が入っているのを思い出して立ち寄ってみたら、お汁粉が無くなっていてその代わりに缶コーヒーが入っていた。今朝、とろけるレモンとか言うジュースを買おうと思って同じ自販機に立ち寄ったら、とろけるレモンの変わりに若武者が入っていた。なぜ俺が買おうと思ったものに限って無くなるのだろうか。

俺は生茶は好きではない。なんとなくあの味は俺の好みではない。緑茶を買おうと思っているときに生茶しかないと気分が悪い。

ブラックの缶コーヒーは、大概が180ml入りなのが気に食わない。350mlで出せ。

最近、ふたを閉めることができる缶のやつが増えてきた。だがあれは中身が少ない。300ml弱しか入っていない。俺は一度空けたら二度と締める気はしない。余計な機能はいらない。ちゃんと350ml入れろ。

夏になると暖かい緑茶が無くなる。全部冷たい奴になってしまう。俺は暖かいほうが好みだ。暖かい方も残しておけ。

自販機の「暖かい」やつは、だいたい60度ぐらいなんだそうだ。だが、それではぬるすぎる。もっと熱くしろ。缶は熱伝導率が高いからすぐに冷えてしまう。特に冬は周囲の気温が低いから冷えやすいのだし、もっと熱くしろ。そう、自販機は"つめた～い"と"あったか～い"と"熱い"の三種類を用意すべきだ。

自販機は携帯電話で買える機能なんぞをつける前に、まず中身を改善するべきだ。と、俺は思う。

一ページ追加

昨日の夜、Webページを2枚追加しておいた。Solarisでサウンドを取り扱う方法について記述したものだ。

このページでやっていることは、単にデバイスの設定を取得・変更して正弦波を出力しているだけだから、極簡単に書き終わるかと思っていたのだが、案外そうでもなかった。結局昨日一日を費やしてしまった。

だが、これだけの労力をかけても、実は余り報われることはない。

google sitemapで分析結果を表示させると、俺のページにアクセスする人は"キャビネット 形式 を 使おう" と"クォータニオン"というキーワードで俺のサイトに到達しているらしい。

結局、俺がどんなに頑張ったところで市場規模（ユーザの数）はSolarisよりWindowsの方が圧倒的に多いから、Windows関連のネタのほうが集客率が高いのだ。多少ページの内容がしょぼくとも、競合するサイトの数が多くとも、絶対的なユーザ数が多ければ結果的なアクセス数は多くなるのだ。はぁ。

・・・結局、今日の内容も「ニッチだぞゴルァ」の愚痴になってしまったか。まぁいいや。

頭の切り替え

今俺は仕事でC言語を使ってプログラムを作っている。C言語のプログラムを読み込み、いろいろと解析して結果を出力するプログラムだ。別にCなくC++であったとしても問題なかったのだが、今後保守するであろう人間の事を考えるとCの方がいいだろうと思って、とりあえず純粋にCだけで作っている。

Cでプログラムを作るとなると、やはりそれなりの制約があって、その制約の下で目的を達するための方法論などがある。

そこで問題なのだが、仕事でCのソースをいやと言うほどいじり倒した後、家に帰ってきてからC++のソースをいじってると、C++のソースがC的になってしまう。Cでは例外が使えないし、クラスが使えないからデストラクタで後処理をさせることもできないから、必要に応じてgotoを使うこともある。しかし、C++の場合はそうする必要はほとんどない。うまく逃れる方法がある。それなのに、gotoを使ってる俺がいる。気がつけばグローバルな関数を量産している。

頭を切り換えればいいだけなのだが、それがなかなか行かない。とかく人間とは不自由な生き物だと思う。

テレビ番組

昨日の夜（正確には今日の早朝だが）SoltyReiがつぶれやがった。番組編成が変更されて雪遊び中継に変わったらしい。一応、今回放送予定だった分は次回以降に繰り延べになったから、まぁ、よかったのだが。

深夜アニメはその放送時間の都合上、よく玉遊び中継の延長の被害に遭う。朝起きて録画していたビデオを見たときに、そこに映っているのが下らないバラエティ番組だったりスポーツ番組だったりしたときの無力感ややるせなさといったら、これ以上ないぐらいだ。行き場のない怒りを一体どこにぶつけろと言うのか。

だが、野球の場合はそれでも「最大延長30分。以降の番組は繰り延べ。」とか書いてあるから、時間やテープ的に余裕があれば長めに録画しておくこともできる。しかし、そうでないときもある。意表をついてニュースが10分ぐらい伸びたり、最大延長30分と書いてあった野球が1時間延びたりすることもある。あるいは今回のように、突然別の番組に差し替えられたりすることもある。

そういうのは絶対に止めてもらいたいと思う。少なくとも当日いきなり変更するのはあってはならないことだと思う。何せ、一度見逃したら二度と見れなくなる性質のものなのだから。

それに、7時台に放送されるアニメは、しょっちゅう潰れるのが気に食わない。夏は野球でほとんど放送されないし、盆暮れ正月・番組差し替えの時期は特別番組で潰れるし、冬季・夏季のオリンピック・ワールドカップ・世界陸上があればそれでまた潰されるし。特にひどいのがOnePieceだ。あれは放送する気があるのだろうか。一ヶ月ぐらい平気で潰すし。（でもまぁ、あれはそれほど見たいわけではないから、どうでもいいが。）

所詮、視聴率が全ての世界なのだろう。しかし、少数とはいえ放送するからには視聴者が発生するのだから、その視聴者に対して一定の配慮をしてもらいたいものだと思う。少なくとも俺は、見ず知らずのおっさんの雪遊びの中継なんか見たくない。興味ない。

UNIXの流儀

ようやく昨日の夜、クライアントからサーバを経由して主筆が起動できるようになった。それに、ちゃんと「主筆」やサーバで標準出力や標準エラー出力にデータを書き込んだときにも、クライアントを起動した端末エミュレータにそのデータが表示されるようにすることができた。まぁ、まだ異常系の処理はまったくできてないけど。

後は、主筆側でファイルを開くときや名前を付けて保存するときにそのことをサーバに通知することと、既存の主筆を必要に応じてアクティブにする処理が残っている。ようやく道半ばと言ったところか。

ここまで来るのには、いろいろと紆余曲折があった。例えば、exit()したときnew したオブジェクトのデストラクタが実行されない（あたりまえ）ということで一時間ばかり悩んだり、おととい自分が書いたコードが何をやってるのかわからなくなって悩んだり。もう、俺はアホかバカかと。

まぁそれはいいとして、現状では上に書いたとおり異常系の処理はほとんどまともにはできていないし、一度も動かしていない。だが、早いうちに作っておきたい例外的処理もある。デバッグがしにくくてかなわない。

そのうちの一つが、execをwaitする方法だ。

他のプロセスを起動するには、あたりまえだがfork()してexec()しなければならない。しかしそのときに、子プロセスでexecが失敗したことを親プロセスは一体どうやって知ればいいのだろうか。子プロセスのexit()はwait()で待ち合わせることができるのだが、単純にwait()するとexec()が成功した場合親プロセスは子プロセスが終了するまでずっと待ちつづけることになるはずだ。だがそうではなく、子プロセスがexec()するかあるいはexit()するまで待つにはどうしたらいいのだろうか。

今までWindowsでやってきた（その前はN88-BASICだったなぁ）せいか、どうにもUNIXでの流儀がよく判らない。googleとかで検索しても、ここへんの「常識」についてはなかなか書いてなかったりする。

さすがに焼付け刀ではそろそろ辛くなってきた様に思う。まじめのその手の本の一冊でも買って勉強するべきなんだろうが。

ディレクトリ構成

俺は${HOME}/projectsの下に、各プロジェクト別にディレクトリを作ってその中で必要な作業を行うようにしている。例えば「くず箱」であれば${HOME}/projects/kuzu配下に全てのソースコードを格納している。それと同じ要領で「主筆」もprojects/TaEditというディレクトリで作業していたのだが、最近それを変更した。

先に書いたとおり、「主筆」はエディタ本体だけでなくクライアントとサーバが追加されることになったため、それぞれ開発用にディレクトリを作成、その中で開発を行うようになった。また、エディタ本体・クライアント・サーバ間で共通に使用するライブラリ用にもう一つディレクトリを作成した。でもって、そいつらを全部まとめて一つのディレクトリ${HOME}/projects/syuhituの配下に移動した。

種類別にディレクトリを分割するのは当然の処理といえば当然だ。だが、そのせいで最近モチベーションが下がったような気がする。

なぜディレクトリ構成がモチベーションに影響するのか。

深い理由はない。単に、ファイルを開いたり閉じたり、コンパイルしなおしたりするのが面倒なだけだ。今はどうしても、クライアント・サーバ・主筆本体・ライブラリの４つを平行にいじらざるを得ない状況にある。だが、そのせいで一時に開かなければならないファイルの数が多く、また、ファイルマネージャでも頻繁にディレクトリを移動しなければならないのがかったるい。一つ一つは些細なことなんだが、それが積み重なってボディブローのように俺のモチベーションを奪ってゆく。

NetBeansの組み込みエディタは使用に耐えないし、大きなディスプレイを買うほどの金銭的余裕は無いし。どうにかならないものだろうか。

まぁ、ある程度できてしまって落ち着いてくれば、どうにかなるのだろうが。ここが正念場なのだろう。

小説

いまさら言うまでもないことだが、俺はアニメが好きだ。アニメオタクといいうるほど入れ込んでいるわけでもないから、自称ではアニメ好きとしている。

話はそれるが、一般にアニメ好きの奴とゲーム好きの奴とはオーバーラップするようだが、俺はそうではない。なぜだか知らないが、ゲームはやらない。ファミコンを持っていた当時は結構やっていたのだが、スーパーファミコンには移行しなかった。

また、漫画はまったくと言っていいほど読まない。ライトノベルの類もほとんど読まない。なんとなく。小説自体はよく読むのだが。

で、今日の本題。

最近、ホームページとか言う幼稚くさいものを一生懸命作ってるせいで、おつむの構造が幼稚化してきたのだかどうだか知らないが、小説とかいうものを書きたくなってきてたまらない。テレビアニメを見ていると、なぜこういう展開になるのかと違和感があってたまらない。俺ならこうするのに、と思うことが頻々とある。あるいは、俺の好みはこんなものではない、こういう風なのが好きだ、と思うことがある。

思い立ったが吉日ということで、今までに二度ばかり行動に移したことがある。構想を練り、あらすじを書き、書き始めてみる。

あらすじを書くまではいい。だが、実際に書き始めてみると、これが意外と難しい。頭の中にある情景、要は俺の妄想なのだが、それを文章にすることが存外困難であることに気が付かされる。

俺が仕事で書く文章は、ほとんど全て技術的なものばかりだ。日本語がかっこ悪くてもかまわない。文章で表現しにくければポンチ絵でも入れればいい。むしろ積極的に絵を入れたほうがいい。だから・そして・それで・なので・よって・で・また・であるから・むしろ、も使いたい放題だ。たとえ全ての文章の頭に「そして」が付いていたとしても問題はない。それどころか演繹の過程を明示するためには必須であると言っていい。（論文の場合は別のようだが。）

対するに、小説の場合はそうはいかない。接続詞の連続は読んでいて見苦しい。井上ひさしに言わせれば、日本語では主語は省略したほうがいいともいう。だが、技術文書では主語の省略は言語道断である。

やはり俺には芸術的才能はないようだ。ガキの頃から判っていたことではあるが。やはりここは、小説とかいう競争率の高い、おまけに無数の厨房がひしめくこの分野に身を投じるのはやめておいたほうがいいようだ。一消費者の立場に甘んじているのが一番幸せなのかもしれない。

あぁ、それにしてもコンピュータに関してはもう少し正しい描写にしてはもらえないものなのだどうか。いまどきサラミ法はないだろ、攻殻機動隊。それに、一般にシステムをハックするのに攻撃者の持つ処理能力は意味をなさないし（特定のバイトシーケンスを送ればいいだけなのだから、極論すれば携帯電話からスーパーコンピュータを乗っ取ることもできる）、量子コンピュータやDNAコンピュータには逐次処理は困難だし、スーパーコンピュータというものは逐次処理が高速なのではなく、並列処理によって巨大なベクトルを高速に処理できると言うものなのだし、データグローブやHMDは使用には耐えない代物だし（使えば判る）、アイコン等のオブジェクトを操作するのに身振り手振りを必要とするのは不便だし（理想的には体の一部のように操作できるべき）、将来にもわたってパソコンが現状のまま残るとは思えないし。

まぁ、俺がここでいくら愚痴ったところでどうしようもないことだがな。

Yahoo登録の効果

いわゆる”インターネット上の噂”によれば、Yahooに登録された直後、新着情報の所に表示されている間はアクセス数がもの凄いことになる、らしいのだが、俺のサイトではそういうことは起こらなかった。残念ながら。俺のサイトは自分が思っている上にニッチなのかも知れない。

だが、多少の効果はあったようだ。yahooやmsnで「Sun Studio 11」とか「Solaris Text Editor」とかいうキーワードで検索すると、かなり上位に表示されるようになった。

それどころか、その他のかなり一般的なキーワード「ICOファイル形式」とか「BMPファイル形式」とかいうものでも、表示される順位があがった。

なかりすげぇ。

んだけど、それでもアクセス数が増えない。それに、googleからは相変わらず嫌われてる。順位あがらない。

まぁ、効果が出るまでゆっくりと待ってみることにしよう。

yahoo掲載

とうとう来よった。yahooカテゴリ掲載通知。ようやく俺のサイトにも春が来たらしい。

ここはせっかくだから、サイト内検索をgoogleの奴からyahooの奴に変えておいてやることにしようか。

「主筆」での標準入出力の扱い

基本的に「主筆」では、エラーメッセージはX上のメッセージボックスとして表示するようにしている。ところがそうも行かない場合もある。起動直後や子プロセス生成の前後、所定のタイミングで実行するコマンド内などでは、メッセージボックスの表示は困難である。そういった場合は、断末魔の叫びとして標準エラー出力にエラーメッセージを出力している。

ところがだ、最近それがうまくいかなくなる危険性が生じてきた。どういうことかというと、それは「主筆」がサーバプロセスから起動された場合だ。

サーバプロセスは必要に応じてクライアントから起動される。そのときサーバプロセスの標準入出力はクライアントのものと同じ所（端末エミュレータ）に結び付けられている。そして、そのサーバプロセスから起動された主筆もまた、標準入出力はクライアントと同じ端末エミュレータに結び付けられている。

ところが、今度は別の端末エミュレータからクライアントが起動されたとしたらどうだろうか。クライアントは既存のサーバにdoorを通じて指示を送る。サーバは主筆を起動する。そうすると、そこで起動された主筆の標準入出力は一体どこに繋がっているのだろうか。

答えは、サーバを起動したクライアントが使用していた端末エミュレータである。そう、主筆を起動するきっかけを作ったクライアント（二回目に使用された奴）が使用していた端末エミュレータは使用されないのだ。

そうすると、ユーザはかなり奇妙な感覚を抱くことになる。「主筆を起動するコマンドを入力したウインドウ」と「エラーメッセージが表示されるウインドウ」が異なるという現象が発生するのだ。それに、もしサーバを起動したときの端末エミュレータが閉じられてしまったとしたら、その後起動される全ての主筆は、標準入出力は一切使用することができなくなってしまうことになる。奇妙どころか、かなり困ったことになってしまう。

ではどうするか。

致し方がないから、クライアントが起動されたときの標準入出力を名前つきパイプとして度っかのファイルに結び付けておいて、主筆が起動されたら（あるいは主筆を起動する直前にサーバ内で）自分が持っている標準入出力を破棄、名前つきパイルを開いてそれを新しい標準入出力として使用することにした。そうすれば少しは一般のプログラムに近い感じになる。

だが、ここにも悩みがある。それは標準入力だ。現状考えている使用では、クライアントは主筆が起動、あるいは既存のものがアクティブにされたらそれで処理を終了するようになっている。だが、そうすると標準入力の扱いは一体どうしたらいいのだろうか。では今度は、クライアントは主筆が終了するまで待ち合わせるようにしたとしたらどうなるだろうか。クライアントからの要請で新しく主筆を起動したときは良いだろう。だが、そうではなく既存のものをアクティブにしただけの場合はどうなるのか。その場合はすぐに処理を終了するのか。

悩ましい問題だ。だが、まぁ、現状主筆では標準入力は使用しないのだから、この際完全に標準入力はサポート対象外としてしまうのも良いかもしれない。そうすれば比較的事態は単純になる。

で、難しいことは後で考えることにしよう。

犬の染色

Novell（すでに終わった会社だな）が、犬のGUIを改悪するとかいうプロパガンダを表明したらしい。もともと犬はMacのゴテゴテなUIを真似てどんどん使い物にならないものになっていっているのだが、それをさらに加速するつもりのようだ。

世の中には不思議なことを考える人たちがいるものだ。

犬のUIの使い勝手が悪いのは、UIの統一性が取れていないことであり、消して派手なエフェクトが無いからではない。派手なマウスストーカーがついてきたり、アイコンを選択すると爆発したり、ウインドウがひん曲がって出入りするようなアニメーションが表示されたり、汚いフォントをぼかしてごまかしたりすることが使い勝手の向上に貢献するとは思えない。それよりもはgnomeとKDEの操作性の統一や、「はい」と「いいえ」のボタンを位置を統一したりすることのほうが先だと思う。ウインドウを閉じたり最大化したりするボタンのアイコンと挙動を統一するほうが先決だと思う。

まぁ、俺は犬は嫌いだから、こうやって自滅してくれれば結構だとしか思わないのだが。こういう風に余分なエフェクトがどんどん増えていけば、時期に「CDEよりgnomeの方が軽い」とか「WindowsよりLinuxの方が早い」とか言うプロパガンダが間違っていることに気が付かざるを得ないようになるだろうから。

・・・とは言っても、現状明らかにGTK+よりMotifの方が軽いのに（何せ開発が止まってるのだから）、それでもGTK+の方が軽いとか、gnomeの方が軽快だなどといっているような連中は、一生涯事実を認めることは無いのだろう。信者にとっては事実は問題ではなく「全ての面において自分が信じているものの方が上である」と言うことが問題なのだから。

信者ってのは、見てて面白いな。

FORTRANをやってみる

Sun Studio 11は最古のプログラム言語であるFortranに対応している。いまどきこんな言語を使うやつがいるのかどうだから知らないが、多分需要があるのだろう。並列化のことや過去の資産・言語仕様等を考慮すると、学術計算においてはこれの右に出るものはない、とか言う話だし。

まぁ、とにかく俺にとっては未知の言語であるFortranの処理系（それも極めて実用的な奴）が、いま俺の目の前に転がっているのだから、技術屋としてはこれを放置しておくわけには行かない。使ってみることにしてみた。

ただ、新言語を習得するとは言っても、結局俺はC/C++をメインにやっているのであり、今後をそれを変えるつもりもないのだから、あまり金と時間をかける訳にはいかない。というか、予算はまったくない。だから、全部Web上のロハの情報だけでどうにかすることにした。

だが、やってみるとこれがなかなか大変だ。やっぱ、只なものは只なだけあって、記述の程度が浅い。それにFORTRANにはFORTRAN77だとかFortran90だとかいう書式が違ういくつかのバージョンが混在している。かなりややこしい。どうせやるなら新しいほうにしておこうとも思うのだが、Webページでは大概がFORTRAN77で解説していたりする。やはり只より高いものはないという格言は真実なのか。

新言語を習得するなら何か目標を立てたいようにも思う。何が良いか。

特に何でも良いんだが、とりあえず「主筆」がらみでプラグインでも作ってみることにしようか。でもって、それをFortranでの開発方法としてWebページにでも書いてみることにしよう。だいぶ先のことになるだろうがな。

作業が進まない

毎回毎回似たようなことを書いてるようなきもするのだが･･･「主筆」の開発作業が一向にはかどらない。マシンの前に座ってソースコード開いて考えようとはするのだが、それがついつい2chとかyahooとかを見てしまう。結局、昨日の夜はほとんどプログラムを作ってないし。

何でそんなにはかどらないのかと考えてみると、おととい?の考察結果も有るのだろうが、それ以外にもう一つ大きな理由があることに気が付いた。

それは、俺が今やってる仕事がC言語でプログラムを作るものでらる、ということだ。そもそも、出勤してきてから一日中プログラムをいじりつづけてるのだ。それでは夜になるころには疲れてしまうのも道理だ。（というか、もっと早く気がつけよ。）

しかも、その作ってるプログラムとか言うのが、結構ややこしい代物だったりする。なにかC言語のプログラムを読み込んで、それを分析して、どこぞの配列だの変数だのに書き込んでるとか読み出してるとか、そういったのを求めるようなプログラムなのである。やたらとややこしい。なんか、文字式のまま値を計算しなきゃならないし。はっきり言って俺のおつむじゃかなり厳しい。

だが、厳しかろうがなかろうがやるしかない。なにぶん、このプログラムをいじってるのは今現在俺しかいない。だから他のやつに丸投げしたくてもできない。もういや。

まぁ、仕事が辛かったり、バグが多くて動かなかったり、胃が痛かったり、朝晩が寒かったり、隣のVipperがむかついたり、雪が降って道が凍ったり、雨が降って道が川になったりするような話は一旦おいておいたとして、とりあえず諸般の事情で「主筆」の開発が進まないのだが、まぁ、今日は金曜日だし、明日あさってで多少は進めることができるだろう。

それに、情報処理技術者試験の勉強もある。なんだかんだいって、ここ数日は勉強してないし。まぁ、ぼちぼちがんばることにしよう。とりあえず2chにはもう出入りしないようにしよう。いいことないから。

TOEICの点数

今日は二回目だが、イベントがあったから書き込んでおこう。

この間受験したTOEICの結果が帰ってきたのだ。今回は絶対に500点は超えた!と思っていたのだが、全くもってだめだった。400点だった。

500点越えてたらSunにミカジメ料払ってパッチを落としまくろうと思っていたのだが、だめそうだ。また今度にしよう。

yahooの登録申請

何日か前になるのだが（前の日曜だったか）、yahooに俺のサイトの登録申請を出してみた。以前にも何回か挑戦して失敗しているので、リベンジということになる。

前に申請したときからみれば、現在はいくつかページが追加してある。特にSolaris上でのプログラミング関係のネタだ。

俺が知っている限りでは、Solaris依存のプログラミングネタを書いているサイトは他には存在しないといっていい。大概はUNIX共通一般の話で、ファイル入出力・プロセス制御・スレッド制御、そんなにがんばってもソケットぐらいまでだ。SolarisのDoorやSun Studio 11についてあれだけ書いてあるページは、俺は知らない。

これだけユニークな情報について書いてあるのだから、掲載されてもおかしくないだろうとは思うのだがしかし、ここで考えなければならないことがいくつかある。まず、俺が書いたことが本当にユニークな情報なのかどうかということだ。もしかしたら、単に俺が見つけることができないでいるだけかもしれない。次に、ユニークかどうかは俺が決めることではないということ。そう、俺がどんなに貴重な情報を公開していると主張しても仕方がないのだ。他のやつが見て貴重であると判断してくれなくてはいけないのだ。第三に、これが一番の問題なのだが、俺が書いた情報に対して需要があるか否かということだ。あるいは、需要があるように見えるか否かということだ。掲載する側としては、どんなに希少性の高いページであったとしても、絶対的な需要が認められないのであれば掲載するだけ無駄である。してみると、俺のページに需要があるように見えなければ掲載してもらえないことになる。

ユニークなものか否かということについては、いまさらどうしようもないだろう。これで勝負をかけるほかない。俺が選択した道だ。だが、需要があるように見えるか否か、ということについては、まだ努力の余地が有るようにも思える。つまり、掲載するか否かを決定するやつに対して「俺の書いているネタは世間一般で大騒ぎになっている内容なんだ、その大事件について俺だけが知りうる希少な情報を公開しているのだ」と思わせるのだ。まぁ、いまさらSolarisのdoorが世間一般で取り沙汰されることは絶対にないのだが、それでも、それを使うことによって得られるメリットや、使用事例を挙げることぐらいはできるだろう。

そう考えると、俺のサイトにはまだ改善の余地があるのかもしれない。多分、今回はだめだろうから、次回に向けて詐術に磨きをかけてみることにしよう。

「主筆」の開発状況

数日ぶりに「主筆」の開発状況について書いておこうと思う。

先日考えたとおり、排他制御機能はXtApAddInputを用いて行うことにした。また、「主筆」起動用のコマンドと「主筆」のインスタンス・挙動管理を行うサーバを用意することにした。

起動用コマンドでは、必要に応じてサーバを起動し、そのサーバに対して指定されたファイルを開くよう指示をする役目を負う。サーバは指定されたファイルを「主筆」で開く。また、既存の「主筆」で開かれていた場合には、それをアクティブにする。起動用コマンドとサーバはSolaris doorで通信を行い、「主筆」とサーバはパイプを用いて通信する。

そして、今現在は上記の方針に従ってプログラム作成を進めている。だが、これがなかなか進まない。

なぜ進まないのか。どうやらそれは、ファイルを開いたりプロセスを上げたりと、比較的面倒なうえに失敗するかもしれない処理ばかりだかららしい。そのせいでモチベーションがあがらない。作ってて気が滅入ってくる。

もしここでパーミッションの設定が違ったら、ファイルが存在しなかったら、サーバが起動していなかったら、逆にすでにサーバが起動していたら、メモリの確保に失敗したら、falkやexecに失敗したら・・・考えることが多すぎる。それに、エラーメッセージの出力も想像以上に面倒くさい。複数のプロセスでガシガシと通信しながら処理を進めることになるので、もし、どこかのプロセスでエラーが発生したとき、そのエラーメッセージはどこに出力すればいいのか、その後の処理は一体どうすればいいのか、容易には解決できない。

子の調子では第15版公開までだいぶ時間がかかりそうだ。