雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2003-08-18

工事

11:43現在,私の席から30cmの距離にある外壁に削岩機で穴をあける作業が行われています.タマラン.

先週飛行機内で大活躍したMDR-NC11も気休めにしかなりません.そういえばこれについて書くのを忘れてました.いわゆるノイズキャンセリングヘッドホンというやつで,耳栓型なので,装着しただけで周囲の音がかなり押さえられます.上のURLを見てもらえば分かりますが,耳の穴に入れるタイプなので,一般の耳かけタイプのように引っ掛けているところが痛くなることもなく,先日の旅行では14時間席を立つとき以外はつけっぱなしで過ごしました.始めはPCのファンの音を低減できないものかと購入したのですが,中〜高音域にはあまり効果がなく,むしろ高域のホワイトノイズが付加されるような感じです.ただ,低音にはそれなりに聞いて,飛行機内のゴーという音は安眠できる程度に押さえられました.さすがに削岩機の音は無理なようですが:-).ランニングコストは単4電池1本で連続20時間は軽くもちます.電池が切れかけると効果が弱くなるように感じるのは気のせい??

中高域を通すのは,人から話しかけられた時に聞き逃さないようにとの配慮だと言う説明をどこかで読んだ気もしますが,高域はカットしてほしかった.お勧め度は微妙.私は耳の形が変なのか,これまでイヤホンで1時間以上連続して装着できるものに当たった試しがなかったのですが,そういう意味で普通のイヤホンとして結構満足しています.耳カスが付きやすいので,耳掃除をこまめにしようというプレッシャーにもなります:-).

お昼の間少し逃げようと思ったら,あちらもお昼に.ちょっとずらして静かなうちに作業を進めよう.

本日のツッコミ(全1件) [ツッコミを入れる]

- taru-k [私も同じような経験をしました… http://www.on-sky.net/~kitahara/diary/inde..]


2009-08-18

[SSL]行政サービス用認証局が…

久しぶりに特許の手続きをしたんですが、法務局の電子証明書が30分ぐらいで発行されてかなりびっくり。世の中便利になったもんです。

さて、その特許庁のインターネット出願ですが、利用可能な認証局がファイル形式のもので4つ、ICカード形式のものは11個とわけの分からない状況になってます。GPKIがコケちゃった影響でしょうか。

で、そのリストの中身もかなりバラエティに富んでいるのですが、各認証局の対応システムが微妙に違うというのがなんとも…。使う立場からすると.tbig red.「なんでこうもバラバラなんだ。責任者出て来い!」って感じですが、こうなったことの責任者なんているはずもなく。

日本商工会議所
http://ca.jcci.or.jp/mokuteki1/index.html
日本電子認証株式会社
http://www.ninsho.co.jp/hojin/list/index.html
株式会社中電シーティーアイ
https://repository.cti.co.jp/G2B/government.html
セコムトラストシステムズ株式会社
http://www.secomtrust.net/service/ninsyo/forgidtsys.html
株式会社NTTアプリエ
https://www.e-probatio.com/ps2/system/
株式会社帝国データバンク
http://www.tdb.co.jp/typeA/typeA/02.html
株式会社ミロク情報サービス
http://ca.mjs.co.jp/core/index.html
四国電力株式会社
http://www.yonden.co.jp/business/ninsho/list.html
ジャパンネット株式会社
http://www.japannet.jp/ca/service/denshi_nyusatsu/index.html
東北インフォメーション・システムズ株式会社
https://www.toinx.net/ebs/service/area_map.html

ついでに各省庁の電子入札システムのページも一通り見てみたんですが、うん、まあ。


2013-08-18

[Ruby]Rubyライブラリのパスの謎に迫る

前回のサーチパスの問題がどうにも気持ち悪いので調べてみました。先に結論を書いておくと、Ruby本体のコンパイル時のオプションによってライブラリのサーチパスが変わり、その影響でbundlerがgemを見つけられなくなるという不具合のようです。

まずは問題のおさらいですが、tDiaryのtarボールを展開するとgemのファイルが".bundle/ruby/1.9.1/"以下に置かれます。ところが、私の環境ではこのパスを見つけられずエラーになってしまいました。調べてみると、

  • bundle installすると動くようになる
  • この時、gemは".bundle/ruby/1.9/"以下にインストールされる
  • 元の".bundle/ruby/1.9.1/"を".bundle/ruby/1.9/"に変更したり、シンボリックリンクを張ればそれらのファイル群でもちゃんと動く

という状況でした。また、@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とおおよそ互換なので、ライブラリはこのディレクトリにインストールされます。

まとめると、

  • Rubyには言語のバージョンと独立したライブラリ互換バージョンという概念が存在する
  • デフォルトの状態ではライブラリ互換バージョンの値と同じ名前のディレクトリにライブラリがインストールされる
  • ライブラリのインストール先ディレクトリの名前は、configureスクリプトで"--with-ruby-version"オプションを指定する事により変更可能
  • この"--with-ruby-version"をつかってディレクトリを変更してしまうと、gemのライブラリ検索パスも変わってしまう
  • このため、例え同じバージョンのRubyであっても異なる"--with-ruby-version"オプションで構築された環境間では、{gemやbundlerのパスに関して互換性が無くなってしまう}

ということのようです。たいへん恐縮ながら、

`center large red` ライブラリの互換性を保証するために(も)使われる名前がコンパイルオプションで自由に変更できるようになってちゃ駄目なんじゃないでしょうか?

途中まではFreeBSD固有の問題かなと思っていたんですが…。

`green`