こーゆーのってどんどん活用すべきだと思う

放置自転車を無料でレンタル「エコチャリ.com」
これなかなかよさげだよなぁ。ステッカーの大きさにも依るけれど、まぁ企業の広告ステッカーくらいならあんまり気にすることもないかな。今ちょろっとレンタルリストの自転車見てみたけど、変速つきのモノとかもあってすげーじゃん！とか思ってしまった。通学以外にも自由に使って構いませんよとのことだし、便利に使えるよなぁ。
これ、大学生だけじゃなくて社会人とかにも広げてくれないかなぁ。駅から会社まで、歩ける距離だけど、自転車があると行動範囲が広がるんだよね。会社帰りにふらっとおでかけ〜みたいなのができるわけだし。
あぁでも、社会人には「卒業」ってのがないから、レンタル期限が定められないってのはあるのか。4年ごとに更新とかでもいいからやってくれないかしら(笑)
実際、放置自転車ってのはたくさん回収されてるだろうし、こーゆー形で利用できるのはいいことだと思う。「捨てるくらいなら俺にくれよー！」と思うことはよくあるので、ガンガン活用してゴミを減らしましょう！
それとは別で、自転車泥棒をホントどうにかして欲しい。結構軽い気持ちでパクって乗ってっちゃうんだろうなーとは思うけど、持ってかれた方はたまったもんじゃない。足が無くなるわけで。
そんで盗んだ自転車を放置しやがるから放置自転車も増えているとか言うオチ。防犯登録してたら返ってくることがあるけど（実際返ってきた）、放置されていたために錆びたりぼろぼろになって返ってくるんですよね・・・。ほんと、やるせなくなる。
環境に優しい乗り物なんだし、使う側は防犯意識をしっかりと！　盗む側には天誅を！　万が一放置されてしまった自転車には救いの手を！

本日の日記は予定を変更してお伝えします

予定では、無事中間発表が終わり、打ち上げが楽しかったよ的なことをつらつらと書こうと思っていたのですが、家に帰ってからの出来事の方がはるかにインパクトがあったのでそちらに変更します。
打ち上げが終わり、家に到着。まぁ夜もそこそこ遅かったですし、家族はみんな寝るところだったのですが、親父が一言
「激辛ピーマンを刻んでみたぞ。ちょびっとだけ食べてみ。」
先日、親父が仕事場で貰ったらしいんですね。激辛ピーマン。小振りなピーマンで、色は橙。まぁ私と親父はそれなりに辛いモノは好きですし、せっかくだからちょいと摘んでみようと。
・・・、それが大きな過ちだったことを知るのは数分後です。ちょびっとかじってみるか、そう思って一切れ口に入れてみたわけです。そうですね、大きさとしては3cmくらいの長さの切れっ端です。
で、数秒咀嚼して、まず辛みが来ました。あぁ、こりゃ辛いなと。ここまではまだよかったんですが、ここから辛い通り越して痛みが。
いてぇ！めっちゃいてぇ！
もう酔いなんて吹っ飛びますね。なんせ痛い。息をするだけで痛い。つかして無くても痛い。そっこーで口に残っているピーマンを吐き出す。ごめんよピーマン、だがこれを飲み込んだら死ぬと思ったんだOrz
吐き出しても痛い。痛い痛い痛い。冷蔵庫から冷たいお茶引っ張り出す。飲む。
辛み成分を洗い流すようなイメージで飲む。
ダメ。消えない。
一旦口にお茶を貯め、火傷をさますようなイメージ。
ダメ。消えない。
飲み続けるわけにも行かないので、洗面所でひたすらうがい。というかさます感じ。ちなみにその間あまりの辛さというか痛さに号泣。いや勝手に目から涙がｗ
そんで十数分ほど悶えていたでしょうか、なんとか痛みが治まり、親父に報告。
「あれは辛い。アレは凶器だ！」
親父はまー笑ってましたが、母親は隣の部屋でブチ切れてました（苦笑　まぁ母親は辛いモノがとても苦手ですからねぇ。ちょっと食べてしまったらしく、そりゃあもう不機嫌でしたね。そりゃ市販の辛口カレーが食べられないくらいなんだから、あんなもん食べたらそりゃ不機嫌にもなりましょうな。合掌。
ということで、今まで「辛いモノは結構好き」と言ってきましたが、前言撤回。「ちょい辛好き」に改めます。
あんなもん殺人道具だぜほんと。親父は
「学校持って行って遊んでみるか？」
なんて言ってましたが、アレは洒落にならねぇ。犠牲者が出ないように自重します。
とりあえずググってみると、ほんと激辛で有名らしい。なるほど素手で触ったら手に刺すような痛みが、ってのは頷けるぜ・・・。
くわばらくわばら。

今の〜僕〜には 理解できな〜い〜

本日17時頃の私の偽らざる気持ちです＞タイトル
本日は中間発表でした。予定では午前中に修士2年生全員が終わる予定だったのですが、教授陣の会議があったために大幅変更。午前中は1人だけ、午後から3人を行うということとなりました。
今日頑張って早起きしたけど報われずOrz
まぁそれはさしたる問題ではないのでどうでもよかったのですが、中間発表と言えば准教授がハッスルする場として私達の講座では有名。今日ものっけから大ハッスルしてました。
まずトップバッターの発表に対する質疑応答。ステレオカメラの映像から、視差を利用して（精度はさほどよくはないが）距離情報を取得することが出来、それを画像化することが出来ると紹介した発表者に対して、
「奥行きを表現した画像に物体の形状が現れることはないのではないか？」
と質問。発表者、質問の内容を理解できず。傍聴者、同じく質問の内容を理解できず(笑)
誰一人としてその質問の意図をくみ取れぬまま時間だけが過ぎていきました。ちなみに発表した学生の担当教員も、准教授の質問の意味を理解できていなかったそうです。そんなもんどうやって答えろと＾＾；
また、nikuが発表者に対して
「今後の課題に精度向上とありますが、どういった目標に向けての精度向上ですか？」
という質問をぶつけ、返答を貰う。十分議論できたなーと思っていたのに、准教授、（聞いている分には）同じ質問をぶつける。発表者、同じ回答を返す。なんだこの既視感（苦笑
続いて二人目の発表。この学生は准教授のグループの学生であるため質問は無し。ただし、軽く説教。まぁ、これも毎度のことだったり。
そして三人目の発表。ここでの准教授の質問はオーソドックスなモノで、発表者も難なく返答。
そして最後に、私の発表。質疑応答で早速食いつかれる。最初はその研究結果はどういったところで用いるのか、という質問だったので研究目的について回答。続いて提案アルゴリズムの効果範囲に関する質問。これについても特に問題なく回答。
途中教授や助教の質問も交えつつ、特に問題なく終わるかと思われたセッション時間終了間際、再再度准教授の質問発生。
「結果で出してきているTimeDelayとは何を意味するのか？」
この質問の意味が私には分からず、質問の意図を探ろうとこちらからも様々にアプローチ。インパルス応答データを結果として出していたので、その遅延量を横軸に取ったためにラベルにDelayと書きました、そう説明したにもかかわらず納得できないご様子。
その後様々なご託を並べられましたが私の考えとあまりに乖離していたため、堪りかねて
「申し訳ありません、仰っていることの意味が分かりません。」
とはっきりいいました。が、質問の内容を言い換えてはくれなかったため、やはり議論は平行線。結局タイムオーバーということでセッション終了。
なんつーか、すっげー疲れた＾＾；　ホント、
「理解できな〜い〜」
ですな。その後私の担当教授がぼそっと
「あの質問は僕も意味が分からなかった」
と仰ってました。やっぱ何か根本的に勘違いされていたような気がします。そもそも、
「かくかくしかじかでこういうものです」
ってちゃんと答えたんだからそれで納得してくれと。
まぁ何はともあれ、無事に終わったのだからよしとしましょう。明日は修士1年生と卒研生の発表。特に卒研生はこれが初めての発表となるので、准教授のきつい洗礼を受けていただくとしましょう(笑)
世の中理不尽なコトなんていくらでもあるのだよ（ぉ
さぁ。明日は質問する側に廻ることだし、ちょくちょく突っ込み入れて行きましょうかねぇ＾＾

明日は中間発表

って記事を書こうと思ったら、気がつくともう2時。
朝起きられるかしらwww
発表時間は20分だけど、練習してみたところ21分喋っちゃう。う〜ん、途中ちょっとあたふたしちゃうところがあるからなぁ。そこをスマートに説明したらぎりぎり20分で収まりそう。
頑張るしかないやね。まぁ練習したところで流れを頭に入れているだけなので本番どう喋るかは考えていないのだけれど(笑)
しかし、予定では10時開始だったけれど、教授の都合により少し送れる可能性が。明日はM2のみの発表で、昼までに終わる予定でしたが、午後に1セッションだけずれ込みそう。
まぁ、私なんですが＾＾；　今回は珍しく普段と順番が逆になり、トップバッターだと思っていた私がトリになったんですね。ですので、昼から私だけやるかも。なんだかなぁ・・・。
ま、明日が終わればM2は気楽。M1、B4は明日が本番。特にB4は初の発表となりますし、緊張している頃かな。
B4の度肝抜くような発表してやらないといけませんなぁ・・・（ニヤリ

メールサーバの設定等

昨日で（というか今朝）で諸々の設定は終えたと思っていたのですが、まだし忘れていた設定が残っていました。
メールサーバの設定です。
私はWindowsの方ではメールを受信しておらず、Linux側にすべて保存しています。今でこそWebメールの容量もGBを越えており、特にローカルに保存する必要性は薄くなってきておりますが、ちょっと前まではそうでもなかったですよね。その頃の名残で、WindowsではWebにて確認、Linuxではローカルに保存というスタイルをとっております。
で、ただダウンロードするだけでは芸がないということで、スパムフィルタを通してからローカルに保存するようにしています。あと、Mailbox形式が私嫌いなんですよね。なんらかの拍子でメール受信に失敗したりするとメールデータ全体がおじゃんになる可能性があるとか、やってらんねー、と。ということで、Maildir形式にてメールを保存することも視野に入れ、メールサーバを立てているという次第です。
といっても、送受信サーバいずれも外部には公開しておりませんし、Linuxも普通に電源を落とすので設定は結構おざなりです(苦笑) きちんとメールサーバを運用するならしっかりと設定しておかないとまずいですが、所詮ローカルということで。
で、昨日までに受信メールサーバであるDovecotの設定は行っていたのですが、うっかり送信メールサーバのPostfixの設定を忘れておりまして、ISPのメールサーバからメールを取得したはいいけれどそれをローカルの受信メールサーバに転送できていませんでした＾＾；
しかも設定を大分前に行っており、しかもBlogなどに備忘録を残していなかったためやり方が分からないというオチ＾＾；
今回は同じ轍を踏まないよう、ちゃんとBlogに備忘録を書いておこうともいます。
Dovecotの方はほぼデフォルト設定のままでもんだいなし。デフォルトではユーザの環境を見てMailboxかMaildir形式かを自動的に判断するようになっているけれど、明示的に指定した方が無難なのでその設定を追加するくらい。
具体的には
mail_location = maildir:~/Maildir
と書いておくくらい。Mairdirにメールが届くようになっているので、ここのディレクトリ名を自由に変更することは可能。まぁ、デフォルトを触らない方が安心・安全。
続いてPostfixの設定。こちらはメールサーバ構築(Postfix+Dovecot) - Fedoraで自宅サーバ構築にしたがって設定しました。昔設定した時もここのサイトにお世話になった気がする。当時はFC3か4の頃だったと思うけど、ちゃんと7にも対応して編集しているあたり脱帽。まめやなぁ。
基本的にはこの2つを起動しておけばfetchmailコマンドにてISPのメールサーバからメールを取得し、それをローカルの受信メールサーバに転送する事が可能です。私はkbiffというメールチェッカを利用しており、こいつが新着メールを調べるコマンドにfetchmailを指定しています。fetchmailの設定ファイルとして$HOME/.fetchmailrcはこのように記述しています。

defaults
smtphost localhost # 送信メールサーバのホスト名
#set daemon 300
poll 受信メールサーバのアドレス
#       user "ユーザ名" there password "パスワード" is 転送先ユーザ名 here
protocol pop3 # あるいはimapなど
username ユーザ名
password パスワード
#mda "/usr/bin/procmail -p -f %F" # 指定しなければシステムのデフォルトが使用される
#keep
fetchall # 新着、既読関わらずメールをすべてDLする
#no rewrite
#no mimedecode
#set postmaster ポストマスターのユーザ名
#set no bouncemail
set logfile .fetchmail.log # ログファイル名
#set syslog # システムログをとるかいなか

デーモンモードで起動することも可能ですが、メールチェッカ側で一定時間毎にfetchmailコマンドを実行しているためデーモン起動の意味は無いと判断しました。
で、これで一応メールは取得できるのでいいかーと思って溜まっていたメールを受信したのですが、内容にビックリ。迷惑メールの多いこと多いこと＾＾； 以前からまぁ入ってくるには入ってきていたのですが、雲泥の差です。先にも書きましたように、以前はこの構成にさらにアンチスパムを挟んでいたため、そこでかなりの数シャットアウトしていたようです。thunderbirdのベイジングフィルタも十分機能しますが、そもそも誤認されるスパムメールは少ないに越したことはありませんしね。
ということで、以前のようにスパムフィルターを導入することに。使用するスパムフィルターはspamassassinです。こちらの設定は13Hz! Postfix + SpamAssassin + DovecotでMaildirなメールサーバーを参考にしました。当時参考にした記事そのままですので、ちょっと古いですが、おおよそこのままで問題ありませんでした。
これらの設定でもって、スパム対策も含めて設定を復元出来ました。案外簡単に終わったかな？ 新規で入れても環境復帰に1日ちょっとしか掛からないもんなんだなぁ。まぁhomeディレクトリはそのまま残してるからなお早いってのはあるけれど。
これならOSアップグレードじゃなくてちゃんと入れ直した方が精神衛生上よろしいかもしれないなぁ。どっちみちアップグレードでも1日仕事なんだし。
までも、Fedoraは更新早いから、2回か3回に1度、くらいがベターかも。1年に1度新規で入れ直すくらいの方が楽かな。半年に1度新規で入れ直すのはさすがに骨が折れそうだ(苦笑)

Fedora7 x86_64版インストール

今日はFedora7 x86_64版のインストールを行ってました。
インストール記を必死に書いていたのですが、書いている途中にXが死ぬという不幸に見舞われたため、書く気が失せましたOrz
結論から言うと、再インストールしたにもかかわらず、Xが堕ちることに変化はありません・・・。もう何が原因で堕ちるのか分からなくなってます・・・。
一体、何が原因なんだ！？ 単純にハードウェアの相性とでも言うのだろうか・・・？
もうお手上げだよパトラッシュ・・・。。。

な・・・！ それは完全に予定外ですってばOrz

Fedoraを再インストールするかしまいか。悩んでいたのですが、もうこの3連休のうちにやってしまうことに決めました。
システムパーティションの使用量は10GB程度、homeディレクトリは空きが30GB程度あるため、そこをまるまるバックアップすればいつでも元の環境には戻せます。
バックアップはtarで固めておこうと思うので、すぐに反映させたい設定やデータだけは別にバックアップを取ることに。何が必要かな〜と考えたところ、
・Yumリポジトリ（なくてもいいが、あれば楽。テキストデータだし取っておいて損はない）
・受信メールサーバの設定（ただ、よくよく設定ファイルを見てみるとデフォルトから何も触っていないようなので、なくてもいいかも）
・MySQLのデータベース（amaroKのプレイリストや様々な情報のバックアップ。なくても致命的じゃないけど、どうせなら取っておきたい）
・Firewallの設定（もう一回設定するのが面倒だ）
ざっとこんな感じ。思いの外少ないなぁ。まぁhomeディレクトリはそのまま残すので、個人的な設定は残ってますしね。パッケージさえ入れてやればその設定が反映されるので気楽なもんです。このあたりが窓と違って便利ですね。窓でもDocument and Settingsを別の場所に指定することは可能ですが、確か結構面倒だったはず。Linuxだとパーティション変えておけばOKですしね。バックアップが楽でいいです。
で、再インストールを決めたのですが、どうせなら32bitから64bitへ旅立とうということで、Fedora7 x86_64版をインストールしてみようと思います。ぶっちゃけ私のマシンはメモリも最大2GBまでだったはずですし、64bit版を入れるメリットなんてこれっぽっちもないですが（ぁ、まぁそれはそれ。
面白そうだし、新しいモノにはチャレンジしないと！
ってなわけで早速Fedora7 x86_64版のLiveCDイメージをDL。で、CDに焼こうとしたときに事件発生！
「CDの空き容量が足りません。十分な容量のCDを用意してください」
おっとしまった。CD-RWの消去を先にやらないといけなかったか。ん？けど焼こうとして空じゃなかったらCD-RWの消去を行いますかって聞いてくれなかったっけ・・・？　まぁいいや。CD-RWの消去をやってから再挑戦だ。
「CDの空き容量が足りません。十分ｎ（ｒｙ」
な、なんだっｔ
いや、確実にRWは消去したんだが・・・？　ん？容量が足りません？　isoイメージのサイズは・・・
「741MB」
・・・( Д) ゜ ゜ !!!
ちょｗ　普通大きくても700MBじゃない？ｗ　なんだよ741MBのisoイメージってwww
ちなみにこれはGnome版のLiveイメージ。KDE版だと800MB越えてた気がする。何に焼けというのだOrz
しかしググってみると、世の中には800MBのメディアとか900MBのメディアも存在するようで。そんなのでしか焼けないメディアとかほんと勘弁して欲しいんですがOrz　せめて700MBで収まるサイズにしてくださいよ・・・。
もう仕方ないので、久々のハードディスクインストールを行おうかと思います。前に失敗して以来やってないんですけれど。まぁインストーライメージが起動できたらこちらの勝ちですし、どうにかしましょう。ネットワークインストールでもいい訳ですし。
とりあえず、明日またBerry LinuxのイメージをDLしよう。ついうっかりBerry Linuxのイメージディスクを消去してしまった。まだシステムパーティションのバックアップ取ってないからなぁ。こういうとき1CD Linuxは便利だ。ぶっちゃけFedoraのLiveCDでやろうと思ってたけど、焼けないなら仕方ない。
さ、久々のLinuxインストールだ。LVMとかも興味はあるけど今回はスルーすっかなー。ちょっと楽しみになってきたぞ＾＾

フォントが変わってしまうことがあるのは仕様？

おや、書いたことあったかと思ったけどなかったか。
実は数日前に、家のガレージで蜂の巣を発見しました。多分、アシナガバチです。
これがまた結構大きな巣になってしまっていまして、蜂が大の苦手である私からするともう悪夢。朝蜂が活動する前に家を出て、夜蜂が活動を終えるくらいの時間に帰るという生活を送っています（苦笑　昼間は結構元気に飛んでますからねぇ。
で、一度は駆除も検討されたのですが、これが結構お高いんですな＾＾；　1万円ちょっとだっけか。まぁ、結局のところ、刺激さえしなければ刺されることもないという判断で放置と言うことになっちゃいました。私としては戦々恐々なんですがOrz
蜂は煙に弱いらしいので、煙でいぶり出すと言うことも考えられるのですが、巣がある場所が中々厄介なんです。窓の日さしと屋根の間に巣を作っていて、ガレージで煙を発生させたとしてもそこに到達しにくいんですな。
パッと見たところ、巣の大きさは握り拳よりも一回り大きいくらいでしょうか。結構大きいです。うちは母親が趣味でガーデニングをやっているので、昔から蜂はよく見掛けていたのですが、巣があるとさすがに飛んでる量が比ではないですね。ガレージに巣があると言うことで、車や自転車に乗るのが億劫になってます。いやホント蜂苦手なんですよ；；
まぁ冬になればおとなしくなってくれるとは思うんですがねぇ・・・。頭の痛い問題だわ＾＾；

足りないのは小手先の『素描力』ではない 現実をも超える『想像力』

Linux以外のネタを書くのが随分久しぶりな気がします。今日はごくごくふつ〜の日記・・・だと思いたい(笑)
さて、斧少女のおかげでアニメ界隈が結構な影響受けてますね。スクイズが最終回を差し替えられましたが、ひぐらしも放送を見送るようで・・・。そんなもん、今更放送規制してなんになるというのだと。凶器で人殺すようなシーンなら深夜アニメよりも土曜ワイド劇場とかの方がよっぽど直接的に表現してんだろーにとかやさぐれてみる。
まぁ、アニヲタの戯れ言にしか聞こえないんだけどさ（ぁ
ひぐらしはこっから面白くなるところだと思ってたのになぁ。
絶望した！ 考えなしに安直に事件とアニメを結びつけてしまうマスゴコミに絶望した！
それはさておき、今日は来週の中間発表に向けて、後輩の発表練習に付き合ってました。二人にやってもらったのですが、私とnikuとでフルボッコにしました（ぉ
ま、叩かれて伸びるもんだよ、うん。 叩く方の我々が学部生当時どうだったかというのはこの際置いておくものなのさ(笑)
とりあえず最初はこんなもんだろか。なんだかんだで二人の発表を見終わったら4時間くらい経ってたような・・・。私もnikuも、普段はおちゃらけていますが、やるときはやるんだぜ？
ただ、それのおかげで自分のスライド作りが随分押しちゃいましたね＾＾； 一応草案は完成させておきました。明日ささーっと通して黙読してみて、不足分は補うとしましょう。
風呂で流れは確認してみたんですけれどね、説明をテキパキとしていかないとだらだらと長くなってしまいそうだ＾＾； 要点はしっかり押さえておこう。 ポイントは研究背景と原理やな。
さて、明日も後輩の発表練習に付き合いつつスライドの調整だ。来週の発表終わったらちょっと休みたいなぁ＾＾；

やはり根本的な解決が必要、か

今日もめげずにLinux奮闘。
今日は思いつきでKDEの個人設定を初期化してみました。
と言ってもまぁ
$HOME/.kde
をリネームする形で、いつでも元に戻せる状態です。KDEもBerylに関わらず不調でしたから、こっちの影響も取り除いてみようと。
で、KDEの個人設定を初期化してBerylを稼働させた結果、Xは堕ちましたOrz
もう思いつく限りの手は尽くしたので、これ以上の抵抗は無意味なようです・・・。潔く、再インストールしますかね・・・。
Fedora8まで待とうかどうするか、未だに悩んではいますが・・・。とりあえず、「/」パーティションは20GBしか切っていないので、こいつのバックアップを取ってさえ置けばいつでも元に戻せる、そういう状態にしてアップグレードすればいいかな。
そう考えれば意外と楽に片付くかな？ う〜ん、「/」パーティションをtarで固めるのが一番手っ取り早いか。KnoppixかBerryでも使ってバックアップを取ると簡単だな。
ま、homeディレクトリはパーティション切ってるし、データベースとメール設定、Firewall設定さえ復活できたら十分やな。
さ、それじゃ、Fedoraの余生を楽しみましょうかね！

果たしてどこまで浸透するかな？

さすがGoogle先生。ドキュメント、スプレッドシートと来て、大方の予想通り、プレゼンテーションの投入！ それに伴い、サービス名もグーグルドキュメントに変更されましたね。
これにより、オンラインで基本的なOAが可能ということに。まぁ、Word機能なんかはちょっとファイルサイズの上限がきっちーので実用は厳しいかもしれないですが、小中学校の情報リテラシーにて、Officeの代わりに使わせることくらいなら十二分に力を発揮してくれるでしょう。そもそも、ブラウザ（とGoogleアカウント）があればいいわけですから。
こうしてGoogleを筆頭にWebアプリケーションがデスクトップアプリケーションに侵食し始めてきています。これをさらに加速させそうなのが、Fedora8で搭載予定のBigBoardです。今Fedora8 Test2がリリースされている状態で、既に試すことも出きるようです。私はテスト版には手を出さないので、調べた限りではありますが、将来性を感じさせる物であるようです。
Gnome用らしいですからKDE派の私としてはちょっと残念ですが、KDEもきっと追いかけてくるでしょう。
さて、肝心の機能ですが、これがちょっと説明しにくいものだそうです。詳しくはコチラ
オンラインデスクトップという位置づけのようでして、Vistaのサイドバーのようにバーが画面横に配置されています。そしてそこにはGmailやGooglカレンダーなどのGoogleサービス、その他RedHatが提供するSNSエンジンのアカウント情報等が表示されるようです。
これだけならただのサイドバーなのですが、それに付け加えて、ブラウザからアプリケーションの起動が行えたりするらしいです。
RedHatのSNSに登録していると、そのメンバ内で人気のアプリケーションランキングなどを見ることが出来るそうです。で、そのアイコンをクリックすると、インストール済みなら起動、されていなければインストールができるんだとか。インストールさせるのはrpmパッケージにリンクを貼って、正しくサーバにMIME設定をさせていたら可能ですが、起動は今まで出来ませんでしたからねぇ。まぁセキュリティ面は今後の課題でしょうけれど。
まぁ、この程度では「だからどうなの？」と言われてしまうでしょうけれど、今後の発展は楽しみです。KDEなんかはkioのモジュールがなかなかよくできており、ローカルとネットワーク上のリソースをほぼ等価に扱えたりしますが、あくまでWebDAVとかFTP相手の話です。
これが今後はFlickrやPicasa、GoogleドキュメントやYouTubeをもローカルから透過的に扱えるようになる可能性を秘めている、となると、やっぱり楽しみになるじゃないですか。
それ以外にも、Fedora8に搭載される新機能で注目しているのは結構たくさんあります。今回の更新は久々に大幅変更が来そうですね。3DデスクトップにはCompizFusionが採用されるようです。Compizが立ち上がり、開発の遅さなどを嘆いたメンバーがBerylをフォーク、けど分裂しててもえーことあらへんってことで再びプロジェクトの成果をマージ。CompizFusionとしてプロジェクトを立ち上げたそうです。まぁいきさつはどうあれ、今後はCompizFusionが標準搭載のようで。Berylは既に開発止まっているそうです。
一応Fedora8で搭載なんですが、有志がFedora7用にYumのリポジトリを公開していたので試しに入れてみました。Berylとほぼ同等の機能で、設定ツールがちょっと変わっている程度でしょうか。
使った感じ、まだ洗練はされていないのか、CompizFusionの方が重く感じましたね。特にデスクトップCubeはもっさりしてました。まぁ残念ながらBerylであろうとCompizFusionであろうとX落ちましたがOrz 根本的にこりゃダメだな。Fedora8にしたら直るかもという私の期待は今の時点で既に砕かれたようです(苦笑)
サウンドミキサーにはPulseAudioが採用される模様。長らくサウンドサーバにはESD（とArts）が採用されていましたがプロジェクトが開発停止してもう随分となります。サウンドドライバがALSAとなり、ALSA自身がミキサ機能も持つようになりましたが、PulseAudioはESDなどのようにサウンドサーバのようで、ネットワークを通じて他のマシンのサウンドも扱えるようです。ちょっと日本語のドキュメントが少ないので詳しいことは分かりませんでしたが、こうしたサウンドサーバが登場してくれると、
「/dev/dspが開けません」
という悪夢のエラーを見なくて済みます(笑) ALSAは優秀ですけれどね。こいつはあくまでドライバなので、ミキシングは確かに様々なドライバを扱えるアプリに任せる方がよさそうです。
と、言うことでなかなか大きな変化を生みそうな今度のメジャーアップグレード。OpenSUSEはKDE4のベータ版を搭載してきましたし、Vistaも相まって次世代デスクトップ、次世代OSの時代が到来しそうですねぇ。
今後もますます、Googleが大きな影響力を持ちそうだ(笑)

キャパシティを大幅に越えている・・・！

昨日になって初めて、SCIM-Bridgeなるパッケージの存在を知りました。GTKやQtにIM-moduleの機構が取り入れられたのは割と最近でしたが、それをSCIMも利用しようじゃないのというパッケージです（細かく説明すればちょっと違いますが）。
こいつを利用することで入力関係の不具合が改善される・・・らしいです（ぉ　と言うのも、入れたのが昨日の夜中なので、まだあんまり試せていないんですよね（苦笑
GTKは割と早くからIM-moduleを取り入れていたのですが、Qtが結構遅かったんですね。まぁQtはもともと日本語入力関連とは相性が悪いことで有名ですから（ぁ、それは半ば仕方のないことなのですが。
で、色々とバグを抱えつつもSCIM-Bridgeなるものがリリース、修正を加えて今に至るらしい。リリースされたのはFC5の頃の模様。ぜんっぜん気付かなかった＾＾；
まぁSCIM-Bridgeを使っていなくてもGTKやQtアプリで日本語の入力は可能です。XIMプロトコル経由で行えば済む話だったりします。
ただ、これは利用者側の話で、開発者側からするとXIM経由、というかSCIM-Bridgeを利用しない場合、メンテが非常に大変なんだとか。
確かに、SCIMはライブラリのバージョンに非常にうるさいパッケージです。glibcとかを更新したらSCIMが起動しないとか、あるいはSCIMを更新したらアプリが起動しないなんてことも良くありました（苦笑　そのあたりの不都合を解消するためのパッケージがSCIM-Bridgeだそうです。
ただ、SCIMに依存していたわけではないらしく、今までの更新に引っかかったことはありませんでした。昨日、xinitrc絡みでXの起動プロセスを追いかけている際、xinputrcのスクリプトの中身を見てたまたま気付いただけでした。
「ん？im-scim-bridge.so？なんじゃそれ？」
で、ぐぐってみたらそげなパッケージがあると。で、インストールしましたよ、と。
ひょっとしたらFedoraを新規で入れても入ってないかもです。大学のPCはFC6を新規で入れましたが、多分scim-bridgeは入ってないです。今までの更新で引っかかった記憶がありませんので。
こーゆー風に、新規パッケージは山ほど増えてくるけれど、それをどうやって知るか。そしてさらに、自分にとって必要なパッケージをどのようにして取捨選択するか。これが難しくなってきてます。
昔は公式のパッケージ数も知れていたので、FTPを直接覗いて
「なんか面白いパッケージねーかなー？」
なんて探したりしてましたが、今は公式だけでもかなりのパッケージ数があり、なおかつその中から自分に必要、あるいは興味を惹くようなパッケージを探し出すのは骨です。パッケージ名からでは中身が分からないものも少なくないですし。
まぁ最近では「ペンギンの杜」のような、Linuxのお勧めパッケージを紹介するサイトもちょくちょく現れてますので、そこいらから情報を仕入れてもいいんですが、Linuxはディストリビューションによって癖がかなり異なるのでそれだけじゃ中々追いつかないんですね。
まして今回のSCIM-Bridgeのような非常に"地味"なパッケージはそういった紹介サイトには現れにくいですしね。
ふむ、紹介サイトや@itにも紹介されないような地味な更新とかパッケージの紹介を昔見たく細々と復活させるかなぁ。amaroKとかsuperkarambaとかの日本語の情報は少ないからなぁ。
自分の知ってることをまとめておくだけでも多少の価値はあるやも知れないな。
あるいは既にそういう紹介をやってるサイトに協力するとか。もうちっと色々と調べてみましょうかね。
ここでだらだら書くのも好きなんですけどね(笑)
さて、「続きを読む」にはCDライティングのお話。トラブル記です。

忌避すべき終端

最近初音ミク動画にどっぷり浸かっている（ぉ
どんどん製作者がうまくなってるんだよなぁ。わざと下手っぽく聞こえるようにチューニングされているはずなのにね(笑)
それはさておき、相変わらずのBeryyl調整。今度はFedora7をベースとしている1CD Linux、Berry LinuxにてBerylの挙動を調べてみました。
Berry LinuxはBerylを搭載しており、かつLivnaのnvidiaドライバも使用という、今の環境に非常に近いLinuxです。デスクトップもKDEですしね。
こいつでもってBerylが安定して動くというなら、Xの設定ファイルをいただこうじゃ無いかという魂胆です。なんせPC環境はまったく同じ、ベースとなるOSも同じですからね。テスト環境としてはこれほど都合のいいものは無いでしょう。
で、起動。initngを選択したら起動しませんでした＾＾； initngはまだ実用的じゃないのですねぇ。KNOPPIXでは使えたんですが。起動が早いので安定してくれるのを待つばかり。
起動しなくては話になりませんので、通常起動。特に何のトラブルもなく起動しました。
で、早速Beryl起動。うむ。何も問題は無い。後はどれだけ耐えてくれるか。それだけに絞られます。
まぁその間暇ですので、音楽でも聴いておこうと、音楽ファイルを置いているパーティションをマウント。てきとーに再生して見たところなんとコーデックが見つからない！ つかどーゆーことよそれ！？ Linuxだろ？ なんでOggが再生できないんだよ！w
mp3はデフォルトで再生できるくせにOggが再生出来ないとか素でびっくりした。xineも入ってるのに、xineがOggのデコーダを持ってないことにもビックリ。mplayerの方は再生できましたが、なんか釈然としないぜ・・・。
まぁとりあえずベンチが目的ですので、音楽を鳴らし、ブラウザを起動させっ放しという私の普段のスタイルそのままにして昼ご飯食べに行きました。
1時間ほど放置して戻ってきたところ、特に何のトラブルもなし。これならほんと、悪いのは自身の環境にあるっぽい。
ということで、xorg.conf、ついでにBerylの設定ファイルをコピー。これを使えばひょっとするとひょっとするんじゃないかという期待を抱きFedora起動。
で、Berylを一旦切り、設定ファイルを書き換え、Beryl起動。
結論から言いますと、やっぱだめでしたOrz
5時間は耐えてくれたんですがね、やっぱだめだったっぽい。こりゃいよいよ、環境をクリアにする必要がありそうです。KDEも不調だしね、再インストールが必要っぽい。
まぁこの5時間の間に、音楽ファイルの整理について色々と調べてました。Windowsで音楽を聴くときはfoobar2000を使うのですが、こいつはアルバム単位のシャッフルが正しく動作します。コンピレーションアルバムだろうと、ちゃんと通し番号にそって再生してくれます。
これに対し、Linuxで使っているプレイヤーのamaroKは、アルバムシャッフルが意図通りに動作しません。コンピレーションアルバムの場合、アルバムアーティストのタグではなく曲のパフォーマータグを優先し、同じアルバム内にある同じパフォーマーの曲を若い順に再生します。途中の曲はすっ飛ばします。というか、別アルバム扱いですね。
これは意図した動作ではない、ってな訳で、コンピレーションアルバムでもちゃんと通して再生させる方法について考えていました。
曲のタグをアルバムアーティストのみにし、曲単位のパフォーマータグは削除するという手もあるのですが、それはなんか勿体ないなと。
なら、アルバム単位でファイルを作ってしまえ。ってなわけで、Matroskaを検討。こいつはコンテナとしては優秀でしたが、タグが曲ごとについてくれませんでした。曲それぞれにタグ情報はちゃんと残っているようなのですが、プレイヤー側がそれを読み出してはくれないよう。ID3Tagではなく、チャプターデータとしてXMLで追加してやる必要があるらしい？ ちょっとその辺はよく分かりませんでした。
また、amaroKの再生エンジンはxineなのですが、こいつがなぜかMatroskaを認識しない。xine自体はちゃんと読めるバージョン何ですがねぇ。Fedora向けに用意されたrpmの構成がよろしくないのかしら。けどFFmpegもMatorskaはちゃんと認識してたし、mplayerでは再生出来たので不思議っちゃー不思議。どっかで設定できるんだろうけどちょっと分からなかった。今後の課題だな。
とりあえずamaroKで再生できないのでは意味が無い、ということで作戦変更。Oggは結構単純なコンテナで、単純連結でまとめてしまうことが出来ます。まぁうまくいかないときもあったりするようですが、同じエンコーダで同じCDからリップした曲を連結する場合に失敗することはほぼありません。
ただ、連結したところでタグ情報は1曲目しか見てくれない模様。ばらしたらちゃんと残っているあたり、情報としては持っているようですが、再生時に見てはくれないようなんですね。
ですが諦めるにはまだ早い。と言うのは、amaroKはcueシートを読める、という点です。まぁ、cueシート単体を読める訳ではなく、再生するファイルと同じディレクトリにcueシートがあった場合、そこのcueシートのタグを優先して読んでくれるという機能ですが。よって、ばらばらにリップしたOggを連結し（もとからCD1枚分のOggでももちろん可）、書式に従ってcueシートを自前で用意すればそれに応じてきちんとタグ情報が反映され、かつ楽曲ファイルとしては1つなのでアルバムを通して再生できると言うワケ。
この方法のメリットは、amaroKでもアルバム単位のシャッフルが意図通りに動作、foobar2000もcueは読めるのでWinとの共有にも困らない、ファイル数が減らせる、といった点です。
デメリットは、cueシートの手書きが面倒。この1点につきます。曲をバラすのはさして難しいことではないため、如何にしてcueシートを用意するかが勝負です。続いて、アルバム単位のシャッフルをするのに邪道ではあるのですが、トラック単位でのスキップが不可、ですね。foobar2000は可能ですが、amaroKはcueシートを読んでいるというよりは楽曲ファイルを読んでいるためスキップすると次のファイルへ飛びます。まぁアルバム単位で聞こうとそうした訳ですから（私に取っては）さしたる問題ではありません。
Windowsでリッピングする場合、EACを使うのが一番手っ取り早いでしょう。あれでアルバム1枚分のWAVEファイルとcueシートを用意し、そのWAVEをOggに変換。cueシートはテキストエディタにて適宜書き換え。まぁファイル名の.wavを.oggに変更するだけでとりあえずはOK。
その後foobar2000にcueシートを読み込ませ、タグを取得ないし自分で書けば出来上がり。foobar2000はOggとcueの両方を読み込めるため、foobar2000のデータベースに2重に登録されるような形になりますが、さしたる問題ではないでしょう。
Linuxでリッピングする場合はどうしたもんかなぁ？ 曲を単体でリッピングするよりCD1枚分でリップする方が楽なんだけど・・・。あと、cueシートを作成してくれるリッパーなんてあったっけか？ どうやらfoobar2000はwineで動くらしいから、コンバータとしてwineで動かすのも手かしらねぇ？ あれはコンバータとしては非常に優秀だし(笑)
まぁ探せばきっとあるでしょう。今日はcueシートを手書きで書きましたが、あれはしんどい。時間の計算が累計であるため間違いやすい。まぁcueシートはただのテキストデータだから書き換えるのはすぐできるけどね。
そんなわけで、cueシートを今更手書きで書くのは相当しんどいので、過去の遺産については放置の方向で(苦笑) 今後はcueシートで管理しましょうかね。
将来的には(tta+cue).mkaが理想なんだけどなぁ。なんでxineはmkaが読めないんだ？ そこもちゃんと調べないとなぁ。。。

結局のところ、ダメだったんですね

昨日喜々として
「Beryl起動してもX落ちなくなりました！」
とBlogを更新したわけですが、何の因果か、Blog更新後10分程度でXがお亡くなりになりましたOrz　結構長い時間耐えてくれていたと思ったんだがなぁ・・・。
その後はまぁ見るも無惨で、再ログインした後はあまり長時間は持ってくれませんでした。むぅ、やっぱ環境が悪いのかしら？
とにかく落ちるようでは話にならない。が、Berylを起動していなければ安定に動作するあたり、ドライバかあるいはXに問題があるんだろうけれど・・・、設定ファイルなんてxorg.conf以外になんかあんのかしら？　それとも起動スクリプトのxinit.rcか？　起動スクリプトとか確かにちょいと確認してやった方がいいかも知れないなぁ・・・。　なんせ8代もメジャーアップグレードを繰り返してるわけで、その間に起動プロセスも変化してるもんなぁ・・・。変なオプションとかが邪魔してたりして。
そうか、今は1CDLinuxとかもあったな。Fedoraベースもいくつかあったはず。Beryl起動できる1CDLinuxでもって、うちの環境で問題が起きないかチェックするのも１つだな。それから再インストールしても遅くはない。
HDD欲しいけど先立つものがないからなぁ・・・。ふむ、なんかバイトしないとやばそうな雰囲気になってまいりましたよ・・・？＾＾；

つまるところ、どうなんだ？

昨日、Fedoraの更新を行いました。
大体週に一度更新しており、昨日もその定期更新です。
で、更新パッケージ内容にkernelが含まれていたんですね。kernelを更新するとNVIDIAのモジュールもついでに更新することになるため、次回起動時にはひょっとしてBerylがちゃんと起動するようになっていたりしないかしらと期待してたりしました。
で、今日Berylを起動して見たところ、なんと今のところ安定して動いています！ これだからなかなか再インストールには踏み切れないんだよなぁ・・・＾＾；
実際のところ、まだ今日１日しか様子を見ていないので、明日起動したらやっぱりダメという可能性も十分に残されているので油断は禁物。
まぁでも、昨日まで使っていたkernelとNVIDIAモジュールの組み合わせだとほぼ100%BerylのせいでXが再起動するという状態でしたので、それから考えると非常に安定しているといえますね。
ん〜、明日も使ってみて安定しているようなら、kernelは更新対象から外しておこうかなぁ・・・。そこまで頻繁に更新しなくても特に問題にはならないと思うし。
くそぅ、HDDに空きがあれば別パーティションに新しいFedora放り込むんだけどな。無駄に64bitとか。
ただ、HDDやっすいのよなぁ。320GBが8000円切るとかどうなってんのよと＾＾；幸か不幸かそんなに困っている訳ではないからなぁ。音楽パーティションがそろそろやばいから引っ越したいというのはあるけど、それ以外はなんだかんだでやっていけてるし。
けど今DLしてる全45曲収録の「Final Fantasy VII: Voices of the Lifestream」がネット上で無料配布中を共有パーティションに置いたらえらいことになりそうだ。なんと2.2GB。音楽パーティションの残り容量が3GBなので、あっけなく空きを食い潰しちゃうよ（ぉ
ん〜、いよいよHDDを追加する時期が来たか・・・？ それともまたいらないデータを整理して誤魔化すか・・・？
ちょいと逼迫してきましたよ、と(苦笑)

えんがちょ

とあるアルゴリズムをちょっくら拡張してみたのが昨日で、今日はその効果を検証してみました。
結論。使えねぇOrz
従来の方法に対してアドバンテージ何かないかなー？と色々と調べてみましたがなさげ。きっちり理論を詰めて実装した訳じゃないけど、ちょっと予想GUY! 逆にうまく動作しない原因を調べないとだめだな。そこを詰めたら改善できるかも。
もしくは、他の手法と組み合わせるかだな。今原因不明のフィルタ係数発散を起こしているアルゴリズムがあるからそこのフィルタ係数更新の部分に組み込んでみるかな。処理的に重くてメモリ量が増えるけどそれに見合っただけの高速化が得られるなら救いがあるさ、うん。
にしても卒業するまでにそれの理論をがっつり詰められるかなぁ・・・？ ・・・、今のうちに行列の勉強しといた方がいいかしら・・・？

私も、確認出来ました

今日は入社前研修の教材のお勉強をやってみました。
電気回路の教材で、学習編をやり、その後試験編をやってその結果をエクセルに貼っつけて提出しろというものでした。
で、横着していきなり試験編やったんですよ（ぁ なんとかなるかなーと。
はい、見事撃沈（チーン
100点中40点 サーセンwwwww
問題自体はそこまで難しくは無い（簡単でもない）ですが、なんせ時間が無い。20問問題があったんですが、1問5分。戻ることは出来ず、5分以内に答えなければ勝手に次の問題に進みます。
ふっつーに回路の計算をする問題とか出てくるのでもう必死。おまけに事前に勉強もせず、いきなりやったもんだからもう大変。
ということで、今回やったのは提出せず、ちゃんと学習編やってから再挑戦します＾＾； あまりにもふがいないですからねぇ・・・。ズルはするもんじゃないですね（当然
20日が提出期限だから早めにやんないとな。
で、昼過ぎに後輩へ研究の解説。B4にコールバック関数の扱いやらポインタやらエンディアン、ダブルバッファリングとかを理解しろと言う方が無理なのは分かってるんですけどねぇ。それが卒研なんだから仕方ないよね。
とりあえず私がいるうちはある程度説明できるけど、いなくなった後が心配だなぁ。私以外に実装を把握している人間が居ないから、彼が綺麗に引き継いでくれないとちょっと面倒なことに＾＾；
大変だろうが頑張ってもらわなくては。
で、そいつを片付けた後、しばらくぐて〜っとしてたのですが、昨日から引き続いて行っていたプログラムの修正を開始。アルゴリズムは合ってると思うんだけどな〜と思いつつ眺めていたら、2ヶ所ほど間違い発見。分かりにくい間違いなんだよねあそこ＾＾；
時間領域での畳み込みは周波数領域では積になるけど、配列への要素の詰め方を間違うと全然違う結果になるからなぁ。今後も気をつけなくては。
で、それ修正して動作することを確認。元々あったアルゴリズムの拡張だけれど、理論を突き詰めるのはとりあえず後回しで動くかどうかを確認するために実装してみましたよ、と。
後は従来法と比べてどの程度有利かをちまちまと調べようってとこですね。理論は本気で突き詰めるとなると残りの在籍日数ではちょいと厳しいかなぁ・・・。後輩に投げるつもりで実装したけど、なんか理論まで完成させてから卒業してとか言われそうだ＾＾；
理論の解析は鬼のようにややこしいんだよなぁ・・・。できれば逃げたいぜ・・・！！！
今日中間発表のレジュメも一応作ったし、来週いっぱいでスライド作ったらOKかな。後輩のために出勤するのもしんどい話やし、Gmailのアドレス教えて、いざとなったらメッセで話しかけろと伝えておくか。
ま、夕方から夜中に掛けてしかいないけどね！（ぁ

挫折と成功

昨日に引き続き、Plaggerのインストール挑戦。
色々とやってみたけど、やっぱり依存するモジュールのインストールが完了しませんでした；；
強引に
cpan> force install Plagger
とかやってみたんですが、まぁ当然ながら動きませんでしたOrz
で、FedoraでどないしたらPlagger動くねんとググったところ、どうもYumでリポジトリを公開しているらしいと。そいつをインポートしてインストールしたらできるぞと。
な、なんだってーーー！！！
となると、今までの苦労はなんだったんだ・・・？
まぁ苦労は買ってでもしろと。そういう教訓なんだと言い聞かせ、インストール開始。
依存パッケージ260個！
どんだけ依存してんねんと(苦笑) まぁそりゃこれをCPANからインストールしようとしてもなるほど失敗する訳だよな〜と思いましたね。
で、無事インストールも終了しまして、Mixiのマイミク日記の取得に挑戦。
したんですが、フェッチ件数0。
「あっれ〜？パスワード間違ったかな？」
とか思ったんですがどうもそれもなさそう。さらにググってみますと、どうもMixiのモジュールを少々修正する必要があるらしく、そこを修正したらちゃんと動きました。
mixiって結構頻繁にログインページとか変更してますしね。今後もマイナーチェンジの度にモジュールを修正する必要はありそうです。
これでマイミクの日記はRSS化することが出来ました。WinはY!Widgetで更新状況をチェックしてますし、日記などを見るときはmixiブラウザを使っているのでRSSを取得する必要性は薄いのですが、LinuxではSuperKarambaのウィジェットにmixiチェッカーがあるわけでもなく、APIが公開されている訳でもないためRSS化できるPlaggerは魅力的だったんですよね。Sageに登録して、さらにcronで30分ごとに更新するように設定。これでLinuxでも自動でマイミク日記を取得できます。
そりゃいいんですが、cronって強制的にメール送りつけて来ましたっけ？＾＾； 実行内容をメールで送ってくれるんですが、別に無くてもいいんだよなぁ・・・。30分ごとに送られてくるのもなかなかに邪魔くさい。まぁ実行ログが見れるという点では意味があるけど・・・。
ま、気が向いたら探しておこう。やりたいことは全部できたんだし。
他にもPlaggerは面白いことができそうだ。ぼちぼち調べて行きますかな。Perl組めたら自分で色々とモジュールが作れるんだろうけど・・・、ちょいとそれはハードル高そうだ＾＾；
とりあえずは便利な利用法の紹介しているサイトとか巡回してみますかねぇ＾＾

指針となるのは主観という名の怪物

今日はPlaggerのインストールに挑戦してました。
理由はmixiの更新状況をRSSで取得したかったから。
まぁ何かとここ最近話題だし、インストールして扱うまでに持っていくのはそんなに難しくないだろうと思っていたのですが、ところがどっこい、これが完全に裏切られました＾＾；
まずPerlを今まで一度も扱ったことがなかったのが最大の敗因かも。
CPAN？なにそれ？おいしい？
とまではいかなくても(苦笑)、CPANからどうやってモジュールをダウンロード&インストールすればいいのかはさっぱり知りません。
で、知らないならググれ、たまにはインフォれってことで調べてみたんですが、なぜか出てくるのはWindowsでのインストール方法ばかり。流行りは流行りだけど、なにもWindowsでやらなくたっていいじゃないかとか思ったよ。自宅サーバといえばLinuxじゃないか！（こら
そんなこんなでなんとか参考になりそうなサイトを発見。ここでしっかりと最初から熟読してやればまだよかったものを、つい流してコマンドからいきなり実行しちゃったんですね。これが運の尽き。
CPANからモジュールをダウンロードし、展開してコンパイル。ここまでは良かったのだけれど、インストール先がデフォルトでは/usr/local/libなど。当然、ユーザアカウントでは書き込めない。よってエラー。
最初はなんでエラーが出るのかさっぱりでした。でよいさほいさどっこいさで調べてみると、参考にしていたサイトの冒頭にちゃんと書いてありましたOrz よく読め自分。
で、そこに書いてあるとおりやったつもりだったのですが、結果としては失敗しました。原因はよく分かっていません。単に己の知識不足かなと。
正直ここまで手間が掛かるとは思ってなかったんだよなぁ・・・。けど実現できたら色々と面白そうだから、とりあえずなんとかインストールはしてみたいところ。CPANの環境設定がまずってるだけだとは思うから、そこを重点的に調べて再挑戦しよう。
ぢつのところ、一部インストールに成功したモジュールもあるのですが、どこにインストールされたのか不明だったり・・・。明日最初から全部やり直そうとは思ってますが、ほんと、どこにインストールされたんだろう・・・？＾＾；

OS再インストールを拒む理由

Windowsだと割合あっけなく再インストールやるんですけどね＾＾； Linuxはほとほと再インストールする気が起きないんです、これが。
今までにも何度か致命的かもと思えるような状態に陥ったことはありましたが、その都度のらりくらりとかわしてきたんですよね。パッケージが新しくなって解決されたりとか、なんとか自力で解決したりとか。
まぁ、そんな試行錯誤の上に成り立っている現在の環境なので、かなり設定等はくちゃくちゃになっているとは思うのですが、今更直す気にもなれずそのまま放置状態。このままじゃ悪化の一途をたどるのは分かってはいるんですけれどねぇ・・・。
かつて経験してきた環境の変化としては、FC1から2になったときだったかな、ファイルシステムの文字コードがEUC-JPからUTF-8になったこと、ほぼ同時期に文字入力システムにIIIMFが採用されたこと、その後しばらくしてIIIMFもKinput2もサポートから外れ、SCIMになったこと、そしてCompizやBerylが採用されたことです。
ファイルシステムの文字コード変更は移行するかしないかで悩んだんですが（このときも再インストールは検討した）、一挙に全部ファイル名をリネームすることで対応しました。そういったスクリプトが出てきてくれたのが幸いでしたね。日本語のファイル名をつけていたのはマルチメディア系のみであり、自分のホームディレクトリ以外には影響がほぼでなかったので失敗してもシステムに影響はあたえないことから安心して実行できたというのもあります。
文字入力システムの変更は、過渡期には結構右往左往してましたね。IIIMFがデフォルトの設定となり、Kinput2がオプション扱いになったりしていたのですが、結局Kinput2に戻して使ってました。IIIMFを使っていた時期もあったのですが、あんまり馴染みませんでしたね。
その後SCIMとUIMが台頭し、さらに変換エンジンにもCannaとFreeWnn、SKKに代わりAnthyやPrimeなどが登場。なかなかのカオスっぷりでしたね。今でもまだやや混沌としている感はありますが＾＾；
今でこそSCIMが標準になっていますが、SCIMがFedoraに対応したのは割と遅かったです。SCIMは出た当時、Qtと相性があまり良くなかったため、XIMと相性の良いUIMを使っていました。Qtにqt-immoduleが搭載されるようになってようやくSCIMも安定し出し、リポジトリにも搭載されたので今はSCIMを使っています。
変換エンジンのAnthyは比較的更新が速く、そして割と高い確率で学習結果を忘れてくれるので（ぉ、今でもあまり賢いイメージがありません(苦笑) CannaはCannaでおバカな素敵変換をやってくれたものですが、学習結果が即座に反映されるので使い込んで行くと特に不便は感じないんですよね。
それに対してAnthyは学習結果を忘れたりするためなんかおバカな印象。やはり日本語の扱いは難しいのだろうね・・・。
そして登場した3Dデスクトップ。これはまだまだ出たばかりで不安定ですが、見た目のインパクトは大きいですね。派手好きな私は例に漏れず早速導入したのですが、果たしてどうにも不安定。今までもシステムが不安定になった事は多々ありましたが、どこかにヒントがあったんですよ。エラーログが吐かれるとか、同様の状態に陥っている人がいたとか。
ただ、今回は同様の事例はほとんど聞きません。Berylを有効にしていたらログイン後10分程度でXがお亡くなりに。そのときXがエラーを吐いていないのが気になる。ログを確認するのが基本だとはいわれるけれど、書いてないんだから仕方ない。
また、Xが強制再起動してから再ログインすると、今度はKDEがやたらと不安定に。いきなりKDE系のアプリがクラッシュしたり（単発でぽつぽつクラッシュすることもあれば、一斉にほぼすべてのKDEアプリがクラッシュすることもある）、デスクトップが無効になったりします。デスクトップのプロセスってなんなんだろ。あれはさすがに普段チェックしてないからお亡くなりになっても呼び出せなくて困るのよね・・・。いつも放置してるけど。アイコンと壁紙がなくなるくらいでそこまで実害はないしね。
さらにさらに、KDEがクラッシュしなくてもBerylのウィンドウデコレータがお亡くなりに。これはBerylマネージャからウィンドウデコレータの再起動か、ウィンドウマネージャの再起動を選べば復活するのでまだましな不具合ですが、これが出始めるとシステムが不安定になってきたというサインなため、やっぱり鬱は鬱ですね。
このウィンドウデコレータのクラッシュについては類似の案件が1個だけ見つかりました。原因はグラボの熱暴走ではないかとのことだったのですが、私のグラボがそこまで熱くなっていないときですら発生するのでこれは微妙なところ。
そもそもNVIDIAとは相性悪い可能性はあるけどね＾＾； 元々AIGLXはATI（現AMD）をベースに作られた技術だし。
とまぁこう色々とあった訳なのですが、最後のBeryl以外はなんとか乗り越えてきたんですよ。だから今回も乗り越えられないかなぁという期待と、OS入れ直して直るかわからないという不安があります。
そう、OS入れ直した結果それでもBerylが不安定だった、ってことになったら、なんか悔しいじゃないですか。
今のところ、Beryl以外は非常に安定し、自分好みの環境にセッティングされています。Berylの機能は私にとってもうなくてはならないものになってしまいましたが、それとシステムの再インストールとを天秤に掛けると、やはりBerylを我慢する方に傾きます。
HDDに空きがあったら、新規で別のFedora放り込んで確認するんですけどね。ちょっと空きがないために確認のしようがない状況。
ほんと、原因は何なんだろうなぁ・・・。それさえ分かれば、自分のスキルと相談して動静がはっきりするのに。うぅ、動きにくいYO!

まだ私には早すぎたようだ

どうやってGoogleカレンダーとデスクトップアプリで同期を取ろうか、そう思っていましたが、Googleカレンダーのデータを一定間隔でローカルに反映させることは容易であることが分かりました。
と言うのも、GoogleカレンダーはiCal形式のファイルを提供しており、その形式にさえ対応していれば、そのファイルを一定間隔でDLしておきさえすればそれを読み込むだけでローカルに反映させることが出来るわけです。
で、iCalに対応したスケジューラやらカレンダーソフトは結構ごろごろしてます。LinuxではKOrganizerあたりがなかなか使い勝手よさげですね。直接HTTPプロトコルからファイルを読んでこれるあたりさすがKDEコンポーネント。ぬかりがないぜ。
ただ、ローカルで予定を書き込んでそれをGoogleカレンダーに同期というのは楽じゃない。そういう目的で作られたアプリなら別でしょうけれど、それは高望みというやつですからねぇ。
一応、Mozilla系列のSunbirdならばそれが可能なようです。Javaと連携するようですね。GoogleカレンダーはAPIが公開されているので、予定の追加などはAPIを使えば可能です。よーは、カレンダーソフト側がそのAPIを組み込めば可能っちゃー可能なわけで。Sunbirdはそーゆーのをやってのけちゃうらしい。すげーや。
その選択肢は非常に惹かれるモノがあったのですが（Sunbird+JavaはWinもLinuxもいける）、やっぱりデスクトップアクセサリのウィジェットに予定を表示させたい！と思ったのでなんとかその方向性を模索。
してるうちにあまりにもXの調子が悪くなってきたためLinuxでの作業を断念。Windowsに移行。
Linuxの話は「続きを読む」にて。
で、Windowsにきてとりあえずカレンダーソフトを探す。有名所で言えばRainlenderだけど、こいつがGoogleカレンダー、あるいはiCalに対応しているか調べたところ・・・、ばっちりビンゴ！　まぁカレンダーソフトならiCalは大概対応してますわな、やっぱり。
ついでに言えば、どうやら有料版の方はGoogleカレンダーに正式に（？）対応しているらしい。それはそれですごく興味がわいたけど、できたら無料で使いたいのでiCalを利用する方向で妥協。
実際iCalファイルをローカルに取り込み、それを反映させたところきっちり反映してくれました。ただ、イベントとして認識していないのか、イベントウィンドウに特に何も表示されないのが気にはなります。
単に1週間以内の予定が入っていないだけでした＾＾；
また、イベントの種類は反映されていないみたい？　まぁGoogleカレンダー側で特にそんなカテゴリ分けがない以上ある程度は仕方ないのかも。インポートしたカレンダー毎に一括してカテゴリを分けるコトは可能なので、Googleカレンダー側で目的に応じたカレンダーを複数作成し、それをそれぞれRainlenderに取り込めば問題なさそうですね。Rainlenderも複数のカレンダーを扱えますし。
さらにさらに、知らなかったのですが、Rainlenderはver.2になってからLinux版も出していたんですね！　これはありがたい。だって、WinとLinuxで同じSkin使えるんですもの＾＾
とりあえずオープンソースというわけではないのでライブラリがきちんと合ってくれるか不安ですが、まぁなんとかなるでしょう。後でLinux版も使ってみたいところです。
とりあえずSkinを改良してみようと仕様を確認してみたのですが、仕様そのものはスッキリしてますね。test用のサンプルを見てみましたら事細かくアイコンが作成してあって、ぶっちゃけ萎えましたが＾＾；　まぁ本気でやるにはそれだけ必要と言うことですね。大変だ・・・。
ただ、既にあるモノを改良するだけならさほど難しくはなさそうです。デフォルトでついてくるカレンダーは背景画像が何もないタイプのモノなので、てけとーに背景を見繕ってやればそれだけでもそれっぽくはなります。細かな修正はそのうちでいいでしょう。
とりあえずローカルへの同期は簡単に実現できて何よりです。次なる課題はいかにしてローカルでの変更をGoogleカレンダーに反映するかですが・・・、これはいさぎよくブラウザからやった方がいいですかねぇ？＾＾；　外出先からは携帯でも予定は追加できるわけですし、PCがあるならブラウザでやればいいか・・・？

まさか対応予定があるとは考えてすらいなかったよ

MS、Flash対抗「Silverlight」を正式リリース
MicrosoftのAdobe Flash対抗技術、Silverlightが正式リリース。Flashはほんと幅広く浸透しましたからねぇ。それに対してどこまで肉薄できるか、見ものではあります。
ただ、正直あんまり気にもしてなかったんですよね、Silverlightは。だって、Microsoftでしょう？ しかもWindowsMediaを利用すると聞いちゃぁ、
「あぁ、Linuxは関係ないさな」
と思うのも無理は無いと思うんですよ、えぇ。オフライン、あるいはオンラインでもただ埋め込んである程度ならMplayerなどで視聴可能ですが、これがブラウザのプラグインとなり、WindowsMediaはコンポーネントの1つとなってしまうと話は別です。Linux用のプラグインなんて提供される訳はないよな、そう思ってました。
その点FlashはLinux用のプラグインも提供してくれているし、まぁSilverlightはどうでもいいか、せっかくの.NETなのになぁとあまり情報も集めないでいたんですよ。そしたらなんと、「Moonlight」プロジェクトとしてMonoと協力してLinux版も開発中だとか！
SUSEがMicrosoftに擦り寄ってどっかんどっかん叩かれたけど、意外なお土産を落としてくれたもんだ、うん。
けど、WindowsMediaコンテンツについてはどうするんだろう？ Mplayerは別プロジェクトだし、そもそもオープンソースだから組み込む訳には行かないだろうし・・・？ 動画再生も可能にしたら、どうせならWMPのLinux版みたいなのも作ってほしいもんなんだけど（ぉ C#でそこまで組めるのかは分かりませんが＾＾；
既にMac版はリリースされているということで、クロスプラットフォーム展開は考えているようです。.NETはMicrosoftが推し進めてますしね。PDF対抗技術と違ってそうそう簡単には潰えない・・・と信じたい(苦笑)
ブラウザ用のプラグインもそうだけど、.NET FrameworkにJavaでいうSwingみたいなのをつけてほしいなぁ。そしたらLinuxでのプロジェクトも増えそうなものなのに。GTKはちょっち微妙っすよ＾＾；

なんか色々と行き詰まった

自分の論文は一応書き上がりました。これで一安心、かな？
中間発表までにスライドを仕上げなくてはいけませんが、まぁなんとかなるでしょう。つかしなきゃな。
で、SuperKarambaの日本語パス問題をどうにかしようと奮闘中ですが、ちょっと諦めモード。Python自体は日本語パスだろうと問題なく処理します。PythonからUNIXのプロセスを直接呼び出せるんですが、それは日本語を含むパスだろうと何も問題にならないんですね。ですが、SuperKarambaのPythonモジュールであるAPIに日本語のパスを渡すとダメみたい。謎だ・・・。
一応KDEのツールキットであるQtは文字列をunicodeで扱うことが出来るため、おそらくはSuperKarambaも文字列はunicodeで扱っていると思うのですが・・・、なんでだろ。
SuperKarambaのウィジェットにはamaroKの再生中のアルバムジャケットを表示するものがあり、そいつは日本語のパスにおかれたジャケット画像であろうと問題なく表示していたので、これを参考にしたらいいんじゃね？と思ってスクリプトを見てみたんです。
するとびっくり。amaroKは登録したアルバムジャケットの画像を自動でサムネイル化し、ランダム名にてキャッシュしてたんですね。そのキャッシュ画像の保存場所は各ユーザのKDEアプリ設定等が保存される場所で、日本語のパスが含まれていないため何の問題もなく表示されていたのでした。一度アルバムジャケットとして登録したらその画像がどっか行っても問題なかったという訳ですね。知らなかった・・・。
ということで、SuperKarambaで日本語を含むパスにアクセスする方法についてはひとまず断念。アスペクト比を固定して一定のサイズ以下に縮小して表示することまでは出来たのでひとまずはこれでよいかなと。スライドショーで表示してみて思ったけど、枠なしってのは思いの外味気ないなぁ。ちゃんと枠でもつけようかしら。
話は打って変わって、家のXの設定について。大学のPCではBerylが不安定とか言うこともないので、大学のLinuxマシンのxorg.confを持って帰ってきて比較してみたんですよ。
そしたら違いなんてろくすっぽないんですね。ドライバを再インストールとかもしてみましたが、再起動して数分でXが強制再起動喰らいましたOrz /var/log/Xorg.0.logファイルにも何もエラーが書き込まれてないんですよねぇ。おかげで原因不明。手の施しようがないのが辛いところ。
大学のマシンがX再起動とか喰らわないあたり、やっぱり私の環境がまずいのだろうと。もう今更どの設定ファイルがおかしいのかとか考えたところで埒があかないでしょうから、OS入れ直した方が早いんでしょうけれどね・・・。Fedora8が出たときに本格的に考えましょう。
さて、ここ数日SuperKarambaに掛かりきりで寝不足。明日も頑張らなきゃ行けないし、さっさと寝るかぁ・・・。

ていうかありえな〜い

あんまり気付いてなかったけど、今月どうも忙しいらしい（ぇ
今月末に中間発表があるのですが、B4の進捗具合がそれなりにヤヴァイ。
中間発表までに、こんくらいは片付けておきましょう
そう考えていたところまでに遥か及ばない。そんなにのんびりしていたつもりはなかったんだけどなぁ。自分はともかく、ちょいと後輩の方は前倒しで進めていかないと大変そうだ。
ということで、私の研究を引き継ぐ後輩の面倒を見ることに。サボっている訳ではないけれどなかなか結果を出せない後輩のプログラムの間違い探し。他人のプログラムって見るのしんどいんだよなぁ・・・。まぁプログラムは受け取ったし、明日くらいに眺めてみよう、うん。
そんな自分も今週中に論文をほぼ完成させる必要アリ。今日はシミュレーション結果をゴリゴリ集めてましたよ、えぇ。全部集めてしまう気でいましたがちょいとミスで集めきれず。無念。
普段私はあまりファイルからの入出力を実装しないんですね。扱うのは音声信号だし、それって結局ただの数値データなので、入出力はリダイレクトで片付けることが多かったんですよ。
それが今はWindowsでの開発なので出力はともかく入力がやりにくい。しゃーないので今回は実装してるんですが、慣れていないもので見事ミスしてましたOrz
1行読み込んでいるつもりできちんと読めてませんでした。おかげでそれ以降の入力が全部ずれ込んで、1時間ちょっとぶん回したプログラムの結果が水泡と帰しました；；
その部分の修正だけは施したので明日また1時間ぶん回そう。
やっぱC++は実行速度速いですね。まぁC#のメリットはもっと違うところにある訳で、それを比較するのは間違いでしょうけれど。けどメモリ管理はもっと自分で管理用のクラスなりライブラリを作っておく方が良さげやな。ケアレスミスが多すぎて怖いや。
さて、研究は研究、趣味は趣味。さてさて今からまたSuperKarambaスクリプトと戯れましょうかね＾＾

何故？ 何故なの？ 何故なのよ・・・・・！！！

おっと気付けばこんな時間。早く眠りたいと思いつつ備忘録的なBlogポスト。
今日はSuperKaramba&Pythonと格闘しておりました。Pythonは今回初めて触るので結構戸惑いましたねぇ。内部での処理についてはどうということはないのですが、日本語の文字列に関する扱いにしばらく頭を悩ませました。
というのも、Pythonは内部での文字列処理を基本unicodeで処理するのですが、外部(コンソールなど)に出力しようとすると、きちんとエンコードを指定してやらないとunicodeのまま出力するため16進数をそのまま出力したりasciiをそのまま出力したりしちゃうんですよねぇ。それは困るぞ、と。
でまぁそれはencode()メソッドを呼び出し、引数にシステムの文字コードを与えてやることで解決できることが分かりました。
それで万事解決、と行けば良かったのですが、そうは問屋が卸さない。文字列処理としてはそれでよいらしいのですが、なぜかパスとしてそれを与えてもきちんと認識してくれない模様。これがSuperKarambaの仕様なのかどうなのか、そこが分からないんですよねぇ・・・。
エンコードしないまま文字列を引き渡すと処理できないと文句垂れられるし、エンコードして引き渡すと"そんなパスねぇよ！"とでも言わんばかりのnull pointer。ちょいと今の段階ではお手上げに近いなぁ。
パスに日本語が使われていると正しく処理できないというのはどうしても腑に落ちないんだよなぁ。Python自体はunicodeで処理するからパスは正しく扱えるはず。ってことはSuperKarambaがunicodeのパスを受け取ってそれをどう処理しているかだけど・・・、それは正直分からないんだよなぁ。ソースコードを追いかけるしかないのか・・・？ SuperKarambaに燗する日本語の情報が少ないからなぁ。未だに"SuperKaramba"でぐぐると私のBlog記事が上位に表示されるってそれどーよ？(ただし、iGoogleだから補正は掛かってると思う)
う〜ん、これが解決できないと悔しいなぁ。画像スライドショーウィジェット作ったけど、日本語を含んだパスは使えません、では利便性悪すぎ。どうにかこうにか解決しないと。
PythonでKarambaスクリプトを無理に作らなくても表示自体は可能だけど、画像の拡縮とかそのあたりの制御はKarambaモジュールが最初から用意してくれてるからそれを利用するのがスマートだと思うんよなぁ。
KarambaでのPythonスクリプトの扱い方は大体分かって来たから、後は日本語を含んだパスの問題だけだ。これはPythonよりもKaramba側に要因がありそうだから、今はそれはほっといて細かい部分を詰めて行ってみよう。きっと解決策はあるでしょ。Karambaもファイルシステム自体はQtのライブラリ呼んでるだけだし、そのライブラリはもちろん日本語パスを扱えるのだし。
さて、今日はもう寝て、明日また頑張ろう。
私のLinux環境は不安定やからなぁ・・・。安定させるには再インストールが一番手っ取り早いが・・・、どうせならFedora8まで頑張ってみたいところ。Fedora8までいくと、なんとRH8からカウントしてOSアップグレード10代目。節目までは突っ走ってみたいわ(笑)
そこまで行ったら64bitに入れ替えたいわね。けどものぐさな私のことだから、どうせならFedora10まで行こうかとか考えちゃうのかしら？w

んなわけねーじゃないですか

え〜、昨日、収束はしたけれど微妙に納得のいっていなかったプログラムですが、行列の演算を間違っておりましたOrz
自分で表記した行列の要素の詰め方が間違っており、なおかつ行列の積の順序を間違えているという体たらく。行列の積としてではなく、各要素毎の演算として表記したら間違いは起きなかったのですが、それだと表記がくちゃくちゃになるため、行列で表記した方がスッキリするんですね。
で、それならいっそのことついでに実装も行列演算を実装しようってことで実装したのが運の尽き。実装方法は行列演算に忠実だったのですが、その要素の詰め方を間違っており、しかもその詰め方だと行列を掛ける順序が逆だったという罠。
まぁ原因も分かってスッキリしたのでいいです。論文は至急書き直す必要がありますが、まぁ提出期限は今月21日なのでどうとでもなるでしょう。幸い図の修正は必要ありませんし。テキスト部分のみの修正なら気をつけさえすれば知れた作業量ですね。
ところで今日は飲み会でした。私達修士2年生が全員就職先が決定したと言うことで、そのお疲れ会です。駅前の居酒屋でぱ〜っと宴会。
今日は私にしてはハイペースに呑んだのでがっつり酔っぱらって帰ってきました＾＾；　きっと帰りの電車でのテンションはおかしいものだったに違いない・・・ｗ
帰ってきてからもすっごく眠かったからなぁ。まぁお風呂入ってむしろ眠気は覚めたんだが（ぉ　おかげでBlogを掛けるほどに意識は回復。楽しい飲み会ではありましたね。
ただ、講座だけでなく同期の間でも私の立ち位置はヲ○クというか虐げられているような感じになってきてしまった気がする＞＜
悲しいかなでも私ドMらしいんだよな〜。いくつかの簡易判定法を試してみた（試されたこともあったな）けれど、いずれもM判定。というかドM判定Orz　まぁ、薄々は感じていたけどね・・・。
ま、楽しけりゃいいか！（ぉ
さて、今週のノルマは論文の修正とプログラムの整理・必要なデータ採集かな。なんか家のPCより大学のPCの方が実行速度が遅く感じたのは何故だろう・・・？　クロック的には大学のPCの方がHTを考慮しても早いのに。やっぱ実クロックが同程度ならデュアルコアの方が強いのかしら？　特にマルチスレッドに対応したプログラムにしたわけではないんだけどな。FFTをマルチスレッドにも出来たけど、あえてするほどでもないと思ったし。というか、FFTの時間を短縮できたとしても、処理全体の1%にも満たない気がするし。アルゴリズムの根本的な改良が必要だからなぁ。それも今週のうちに草案を練っておくか。
さて、今週もビリっと頑張るぞ〜！

ぐさー、だくだくだくだく

ここ数日悩み続けたプログラム収束しない謎ですが、ようやく解決。無事収束するようになりました。
が、正直言って納得できていなかったり。ちょいと理論にも関わってしまうのでもう少し細かい部分を詰めてチェックはしなきゃですね。
ただ、動作するようにはなったのでひとまずは安心。C#に比べるとやはり実行速度が上がってますね。比べるのはいかんことではありますが。また、FFTのライブラリがありがたいことにメモリ節約に貢献してくれましたし。
ただ、メモリ管理はやはり面倒だし、バッファオーバーフローなどのケアレスミスも相変わらず多いので、あまり組みたくないのが本音＾＾；
動作確認用のプロトタイプはC#で、がっつり条件を変えてベンチ的なシミュレーションを行いたいときはC++で実装、ってのが私に合っている気がします。最近ではMATLABも多少覚えてきたのでそちらもプロトタイプ作成に使えそうですね。
今回組んでいて思ったのは、配列渡したらグラフ描画してくれるライブラリが欲しいなってことです。C#にはあったんで持ってるんですが、C++用で扱いやすそうなのが見当たらないんですよねぇ。あるとは思うんですが。やっぱり結果をぱぱっと確認するにはグラフ描画ってのが便利ですからねぇ。Linuxならgnuplotにアタッチしたらいいんですけど、Winだとどうなんだろ？　なんか便利なライブラリないかしら。そう考えるとやっぱりMATLABは便利よねほんと。
とりあえず今までの研究で取り組んできたアルゴリズムはC#に集結させているので、それをC++にも移植して後輩に残しておきたいところ。C#は後輩たちには不評だからなぁ。便利なんだぜ？（苦笑
さて、懸念していたプログラムができあがったので、ここからは趣味の時間だ！　さぁて、カレンダーウィジェットでも作りますかねぇ＾＾

なんですか、もう

C#で組んだシミュレーションプログラムをC++に移植し始めて約1週間。ようやく終わりが見えてきました。
というか、デバッグデバッグで、ようやく結果らしい結果が出たってとこですね。それでもまだ正しい結果を吐いてくれないので地道にチェックして行かなくてはいけませんがOrz
単純にアルゴリズムを移植しているだけの部分が半分、根本的に書き換えたところが半分ってところなので、割とコーディングはスッキリしたけれどまだ把握できていない部分もあったりします。とりあえず、FFTWは非常に優秀ですね。
にしても、久々にC++で組むとほんとケアレスミス連発しちゃいますね・・・。今回やっちまったミスのうち9割がバッファオーバーフローなどのメモリの扱い。C#と違って配列のインデックスをオーバーしてもC++はなんも言いませんからねぇ・・・。おかげで踏み越えるわ踏み越えるわで大変でした。書き換えなんて起こらないはずの関数を抜けたら変数のアドレスが訳分からん数字に書き換えられてるとかほんと悪夢だった。まぁ、アドレスが書き換わっていたために100%バッファオーバーフローの類だろうなと気付けただけマシなバグですが。今もまだプログラムが完全には動いていないので、どっかにメモリ周りのバグが潜んでいそうで怖い。しっかと潰して行かなくては。
今回一番やらかしたのはmemset関数とmemcpy関数の扱い。両方とも引数にバッファサイズを要求してくるのですが、処理したいバッファのバイト数を与えなくてはいけないので、配列長*単位サイズを計算しないと行けないんですね。が、ついつい配列長だけを渡してしまってコピーや値の設定が正しく行われず、結果が狂うと言うことが多々ありました。sizeof関数とかC#ではほとんど使わないからなぁ・・・。まぁそもそもmemsetとmemcpyに該当するモノが無かった気がするけど＾＾；
ここまでミスするんならいっそのことmemcpyとmemsetはラッパークラス作った方がいいんじゃないかという気がしてきた。C++って変数の型情報取得とかできたっけなぁ・・・？できたとして、それをsizeofの引数に渡せるのかしら？
まーそれよかsizeofの癖を付けた方がマシか＾＾；
さらに、FFTWの扱いも失敗してた。
forwardFFT = fftw_plan_dft_r2c_1d(length, doubleArray, complexArray, flags);
backwardFFT = fftw_plan_dft_c2r_1d(length, complexArray, doubleArray, flags);
といった形で1次元DFTと1次元IDFTのプランを生成し、それぞれのメソッドを持たせたFFTクラスを作った訳なんですが（超単純なラッパークラス）、このときマニュアルをちゃんと読んでなくてですね、実数配列のサイズと複素数配列のサイズの扱いの違いを理解していなかったんです＾＾；
実数配列をDFTすれば、その結果は複素数となります。が、その複素数の配列は実際にはちょうど真ん中から折り返すような値の配置になります。つまるところ、実数配列のサイズがNのDFTを行うと、本来ならNサイズの複素配列を必要とするところをN/2+1で表現可能というわけです（Nは整数であり、割り算は切り捨てです）。
また、逆にそういった真ん中から折り返したような複素配列をIDFTすると実数だけの結果が得られます。
FFTWのサンプルの多くは通常のDFT/IDFTを紹介しており、入出力のバッファには複素配列を与えています。が、私は今回、DFTは実数を入力とし、IDFTはエルミートな複素配列を入力とすることを前提としていたので先のプランを用意したわけです。
でそこまではよかったのですが、うっかり複素配列もサイズNで確保しちゃってたんですよね。別にバグは起きませんし、用意されていたとしても使われないのですが、せっかくメモリを節約できるのに勿体ないですよね。マニュアルを読み直して良かったよほんと。
ただ、そこで複素配列のサイズをN/2+1に変更したため、DFT後に一時バッファから出力バッファへコピーしたり、あるいはIDFTの前に入力バッファを一時バッファにコピーしたりという作業でコピーする領域のサイズをNのままにしており、ここでも見事メモリ領域を破壊してました；；
まったく、焦ってコトはやるもんじゃないですね・・・。
とまぁそんなこんなでツマラナイミスに苛まれつつ、なんとか動きかけのところまで持ってきました。残すところもうあとわずか。ほんとだと8月中に片付けたかったんですが、間に合わず。デッドラインは9月末ですが、できるだけ早く片付けたいところ。この土日で片付けたいな。
ところでVC++のデバッガの使い方ってどうやったら勉強できるんかなぁ？　もっと使いこなせたらきっと便利やと思うんやけど・・・。表面的な機能しか使えてないし、もうちょっとどうにかしたいところ。
特にnewで確保した配列をウォッチリストで手軽に監視する方法ないだろうか・・・？　確かにC/C++の仕様から言って配列とポインタにほぼ差がないから表示しにくいってのは分かるけど、何か方法ないもんかなぁ？
デバッガとにらめっこしてた、そんな今日1日でした（苦笑