11:43現在,私の席から30cmの距離にある外壁に削岩機で穴をあける作業が行われています.タマラン.
先週飛行機内で大活躍したMDR-NC11も気休めにしかなりません.そういえばこれについて書くのを忘れてました.いわゆるノイズキャンセリングヘッドホンというやつで,耳栓型なので,装着しただけで周囲の音がかなり押さえられます.上のURLを見てもらえば分かりますが,耳の穴に入れるタイプなので,一般の耳かけタイプのように引っ掛けているところが痛くなることもなく,先日の旅行では14時間席を立つとき以外はつけっぱなしで過ごしました.始めはPCのファンの音を低減できないものかと購入したのですが,中〜高音域にはあまり効果がなく,むしろ高域のホワイトノイズが付加されるような感じです.ただ,低音にはそれなりに聞いて,飛行機内のゴーという音は安眠できる程度に押さえられました.さすがに削岩機の音は無理なようですが:-).ランニングコストは単4電池1本で連続20時間は軽くもちます.電池が切れかけると効果が弱くなるように感じるのは気のせい??
中高域を通すのは,人から話しかけられた時に聞き逃さないようにとの配慮だと言う説明をどこかで読んだ気もしますが,高域はカットしてほしかった.お勧め度は微妙.私は耳の形が変なのか,これまでイヤホンで1時間以上連続して装着できるものに当たった試しがなかったのですが,そういう意味で普通のイヤホンとして結構満足しています.耳カスが付きやすいので,耳掃除をこまめにしようというプレッシャーにもなります:-).
お昼の間少し逃げようと思ったら,あちらもお昼に.ちょっとずらして静かなうちに作業を進めよう.
久しぶりに特許の手続きをしたんですが、法務局の電子証明書が30分ぐらいで発行されてかなりびっくり。世の中便利になったもんです。
さて、その特許庁のインターネット出願ですが、利用可能な認証局がファイル形式のもので4つ、ICカード形式のものは11個とわけの分からない状況になってます。GPKIがコケちゃった影響でしょうか。
で、そのリストの中身もかなりバラエティに富んでいるのですが、各認証局の対応システムが微妙に違うというのがなんとも…。使う立場からすると.tbig red.「なんでこうもバラバラなんだ。責任者出て来い!」って感じですが、こうなったことの責任者なんているはずもなく。
ついでに各省庁の電子入札システムのページも一通り見てみたんですが、うん、まあ。
前回のサーチパスの問題がどうにも気持ち悪いので調べてみました。先に結論を書いておくと、Ruby本体のコンパイル時のオプションによってライブラリのサーチパスが変わり、その影響でbundlerがgemを見つけられなくなるという不具合のようです。
まずは問題のおさらいですが、tDiaryのtarボールを展開するとgemのファイルが".bundle/ruby/1.9.1/"以下に置かれます。ところが、私の環境ではこのパスを見つけられずエラーになってしまいました。調べてみると、
という状況でした。また、@machuさんの環境では1.9.3でもそのままで問題無く動くということでした。とここまでが昨日の時点での話で、ライブラリのサーチパスがかなり怪しいです。
さて昨日も書いたのですが、Ruby関連はFreeBSDのportsを利用しているので、調べてみると、/usr/ports/Mk/bsd.ruby.mk に
: RUBY_DEFAULT_VER?= 1.9 RUBY_VER?= ${RUBY_DEFAULT_VER} : # Directories RUBY_LIBDIR?= ${_RUBY_SYSLIBDIR}/ruby/${RUBY_VER} RUBY_ARCHLIBDIR?= ${RUBY_LIBDIR}/${RUBY_ARCH} RUBY_SITELIBDIR?= ${_RUBY_SITEDIR}/${RUBY_VER} RUBY_SITEARCHLIBDIR?= ${RUBY_SITELIBDIR}/${RUBY_ARCH} RUBY_VENDORLIBDIR?= ${_RUBY_VENDORDIR}/${RUBY_VER} RUBY_VENDORARCHLIBDIR?= ${RUBY_VENDORLIBDIR}/${RUBY_ARCH} : GEMS_BASE_DIR= lib/ruby/gems/${RUBY_VER} GEMS_DIR= ${GEMS_BASE_DIR}/gems DOC_DIR= ${GEMS_BASE_DIR}/doc CACHE_DIR= ${GEMS_BASE_DIR}/cache SPEC_DIR= ${GEMS_BASE_DIR}/specifications GEM_NAME?= ${PORTNAME}-${PORTVERSION} GEM_LIB_DIR?= ${GEMS_DIR}/${GEM_NAME} :
/usr/ports/lang/ruby19/Makefileに
post-patch: @${REINPLACE_CMD} -E \ -e 's,-l$$pthread_lib,${PTHREAD_LIBS},g' \ -e '/^RUBY_LIB_PATH/s,\.\$$\{TEENY\},,' \ -e '/^RUBY_SITE_LIB_PATH2/s,\.\$$\{TEENY\},,' \ -e '/^RUBY_VENDOR_LIB_PATH2/s,\.\$$\{TEENY\},,' \ ${WRKSRC}/configure
という記述がありました。ところが、これが原因かと思ってさらに追ってみてもどうにもおかしい。前者はパッケージを作るためのパスの設定でコンパイル時には使用されておらず、後者はTEENYを削除していてそれっぽいのですが、ソースを展開してできるconfigureスクリプトには該当する行が無く、さらに探すと展開されたソースツリーのdoc/ChangeLog-1.9.3に
Thu Feb 5 11:21:35 2009 Nobuyoshi Nakada <nobu@ruby-lang.org> * configure.in (RUBY_LIB_VERSION): added for library version, to split from core version. [ruby-dev:37748] * configure.in (RUBY_LIB_PATH, etc): moved actual version dependent stuff to version.c.
と2009年の2月にはconfigureから消されているようで、今現在は意味の無いコードのようでした。よく分からないのでsandboxを作ってRubyをportsを使わずにソースからインストールしてみると、ちゃんと(?)/usr/local/lib/ruby/1.9.1/以下にインストールされるので、ますます謎です。
ここでいったんRubyの追跡をあきらめ、gemのサーチパスが変わってしまう原因を追ってみますが、こちらのportsはソースには全く手を入れておらずにsetup.rbを実行しているだけでした。いよいよ深みにはまってきたなぁと思いつつgemのソースを追います。ここでかなり時間がかかりましたが、なんとか探し出したところ、gemのサーチパスはdefaults.rbというファイルの中のdefault_dirで定義されているようでした。
def self.default_dir path = if defined? RUBY_FRAMEWORK_VERSION then : elsif ConfigMap[:rubylibprefix] then [ {~orange:ConfigMap[:rubylibprefix],~} {~orange:'gems',~} {~orange:ConfigMap[:ruby_version]~} ] else : end @default_dir ||= File.join(*path) end
このConfigMapはrubygems.rbの中で、
unless defined?(ConfigMap) ## # Configuration settings from ::RbConfig ConfigMap = Hash.new do |cm, key| cm[key] = RbConfig::CONFIG[key.to_s] end else :
のように初期化されています。RbConfig::CONFIGってなんぞやとぐぐってみると、「RbConfigというのがあってビルド時の情報とかが取れる」というブログの記事が見つかりました。こちらに習って確認すると、
% ruby19 -rpp -e"pp RbConfig::CONFIG" {"DESTDIR"=>"", "MAJOR"=>"1", "MINOR"=>"9", "TEENY"=>"1", : "ruby_version"=>"1.9", : "rubylibprefix"=>"/usr/local/lib/ruby",
おぉ、ruby_versionが"1.9"だ。同じくソースを直接コンパイルした環境で試すと、
% ruby -rpp -e"pp RbConfig::CONFIG" : "ruby_version"=>"1.9.1", :
と、ちゃんと"1.9.1"になっています。いよいよ核心に迫ってきています。
そうすると、このruby_versionをどこかで変更しているはずだと思ってさがしてみると、/usr/ports/lang/ruby19/Makefileに、
CONFIGURE_ARGS= ${RUBY_CONFIGURE_ARGS} \ --enable-shared \ --enable-pthread \ {~orange:--with-ruby-version=minor~} \ --with-sitedir="${PREFIX}/lib/ruby/site_ruby" \ --with-vendordir="${PREFIX}/lib/ruby/vendor_ruby"
という記述を発見。configure --helpで確認すると、
--with-ruby-version=STR ruby version string for version specific directories [[full]] (full|minor|STR)
とあったのでビンゴ。FreeBSDのportsではこの"--with-ruby-version=minor"指定でライブラリのインストールパスを"1.9"にしておいて、最初のbsd.ruby.mkでパッケージ化する際のパスを調整しているようでした。
残る疑問は、Rubyのバージョンが"1.9.3"でもライブラリのパスがデフォルトでは"1.9.1"になっている点ですが、こちらは、1.9.2のリリースノートのFAQに答えがありました。
{''標準ライブラリが/usr/local/lib/ruby/1.9.1にインストールされる''} このバージョン番号は「ライブラリ互換バージョン」です。Ruby 1.9.2は1.9.1とおおよそ互換なので、ライブラリはこのディレクトリにインストールされます。
まとめると、
ということのようです。たいへん恐縮ながら、
`center large red` ライブラリの互換性を保証するために(も)使われる名前がコンパイルオプションで自由に変更できるようになってちゃ駄目なんじゃないでしょうか?
途中まではFreeBSD固有の問題かなと思っていたんですが…。
`green`
- taru-k [私も同じような経験をしました… http://www.on-sky.net/~kitahara/diary/inde..]