Rubyについて Part 18

思いついたら思わずカッと書いていた。
移植先のWindows環境でだけセグメンテーションフォルトを起こす
巨大拡張ライブラリのデバッグでここ数ヶ月もやもやしていた。
今は反省している。

反省するくらいならソースとバックトレース。

なんとクノーピクスの４ってドイツ生まれなのに最初からルビーが入ってるらしい。
ルビーが入ってるディストリってめずらしくね？
ふつうはパールとかパイソンとかじゃね？

エサがついていませんよ

ざっとwcしたら6マソ行ありますが…。＞ソース

そこから問題箇所を分離することも出来ないのか?
数ヶ月何してたんだ。

苦労して一個つぶすとつぎのバグって感じで問題箇所が沢山あるんでつよ。
その上、移植元が毎日ウプデートされまつ。
バグ修正を期待してチェックアウトしてくると時々エンバグもされているようで…。
ちなみに今苦労してる分は昨晩の最終更新を取り込んで今朝テストして発現した分。

（つーか発生箇所から手繰って原因箇所を見つけるまでが大変。
見つけたら多くのバグは1時間から半日くらいで直せます。
デバッガがマトモに使えると楽なんですがねぇ・・・。
MinGWにRubyにC++で書かれた拡張ライブラリという取り合わせがよろしくないのか
gdbはセグメンテーションフォルトがRubyにハンドリングされると正常終了しちゃうし、
WinDbgはフォルトを捕捉できるけどgccの吐くシンボル情報が見られないし…。）

ちなみにブツはコンパイラもどき。
ただ対象分野には詳しくてもコンパイラについては詳しくない人が書いたから
無茶苦茶癖のあるデータ構造とロジックが特徴です。

ん？一瞬、例のフランス人のやつかと思った。

C++で書かれたモジュールの参照関係と依存関係が
型についてはtemplateと継承、オブジェクトのやり取りに関してはポインタ渡しと参照渡し、
後はちりばめられた大量のキャストと多重定義された大量のメンバー関数を組み合わせて
まるでスパゲティのごとくなっていて、
それらがトップ・レベルのRubyで書かれたコードを経由して情報をやりとりする設計。
その上、上述のようにデータ構造の設計が超独自で複雑。

中身もBisonやFlex向のソースをはじめConservative GCはあるは、XMLは読むは、
挙句そのXMLソースにCコード断片やRubyコード断片が埋め込まれてるはでもう大変なんすから。
(6月の段階ではSQLやオリジナルのパターン言語も組み込まれていた。)

最初なんか参照関係が入り組みすぎた複雑極まりないビルド手順を解きほぐして
make一発でコンパイルできるようになるまで
2−3週間掛かりましたからねぇ･･･。
（並行してWindowsでは上手く動かないXMLパーザの差し替えとか
Conservative GCのインターフェースを今時の版に更新とかもしてましたが）

普通、こんな無茶なコードは何万行にもなる前に書いてるほうがイヤになって
投げ出して一から書き直すのが普通だと思うんすが、
これを殆ど一人で3年掛けて書き上げたヨーロッパ人は肉食のパワーかヨーロッパ魔術か、
とにかく力業で動かしちゃったんですわなぁ。
で、なまじLinuxではつっかえつっかえでも動いてるもんだから
Windowsに移植するって話になって今春5月中旬に今のチームに移って来たばかりの私に
「Windowsでプログラム書いたことがあるから」ってお鉢が回ってきたんですなぁ。
（件のヨーロッパ人は「Windowsはぜんぜんわからナイ。」そうで。）

>>100
うは。そう。まだ終わってなかったんですよ。
そろそろ名無しに戻りますよ。