Point Cloud Libraryで法線推定をしたときの結果が正しくない不具合を修正

これもだいぶ前のことですが、Visual StudioでビルドしたPoint Cloud Library (PCL)で、pcl::NormalEstimationOMPで法線推定を行ったときにデータレースを起こして正しく法線推定できない不具合を修正しました。

github.com

最初にPull requestを送ったときは単にfree functionを呼ぶべきところを同名のmember functionと間違えたのだろうと思っていたのですが、結局はVisual Studioのtwo phase name lookup(か、そのあたり)の振る舞いが標準とは異なるのが原因でした。 two phase name lookupに関してはVC++ユーザーのあいだでは広く知られた問題のようですが、寡聞にして存じませんでした。

ちなみにPRにコメントしているとおり、最近のVC++には標準準拠の振る舞いにするオプション(/permissive-)があるのですが、残念ながらOpenMPを有効にすると無効にされてしまいます。

LDAP認証を有効にしたNGINXのDockerイメージを作成する

Docker HubにはオフィシャルなNGINXイメージがあるのですが、NGINX単体ではLDAP認証を行うことができません。NGINXでLDAP認証を行うには、サードパーティーのモジュールであるnginx_ldap_authモジュールを追加してNGINXをビルドする必要があります。

最近の公式イメージは、AMD64であればビルド済みバイナリを取得、そうでなければソースからディストリビューション固有のパッケージをビルドしてインストールと、スマートなやり方をしています。今回は昔の公式イメージと同様に、素朴にソースコードをビルドしてそのままインストールすることにします。また、こういう場合はマルチステージビルドを使うべきですが大目に見てください。

gist.github.com

たぶん、いらないオプションもありますが……。

Point Cloud Libraryが一部のCPUでビルドできなかったのを修正

だいぶ前のことですが、Point Cloud Library (PCL)を一部のCPUでビルドできなかったのを修正し、Pull requestしました。

github.com

GCCの-marchというオプションはCPU固有のアーキテクチャを指定して最適化するオプションなので、アーキテクチャによってはそもそもこのオプションが存在せず知らない引数が指定されているとしてビルドに失敗してしまいます。

PCLはCMakeを使っているので、当該オプションを指定している箇所でcheck_cxx_compiler_flagを使ってコンパイラが-marchというオプションを持っているかチェックし、なければ代わりに-mtuneを使うように変更しました*1。

今日日使われていそうな非IntelアーキテクチャというとARMかPowerPCだと思いますが、ARMには-marchがあるようなので、PowerPCでPCLをビルドする人*2には意味があるのかなといったところです。

*1:このフラグをセットするcmakeファイルとその変数名からするとSSEが前提なのでアレですが

*2:いますか？

Docker ComposeでKibanaが動作する環境を構築する

Docker Composeが使える環境にてKibanaでデータの集計とその可視化をすることになったのですが、minimalなdocker-compose.ymlが見当たらなかった*1ので、Docker Composeのリファレンスを眺めつつdocker-compose.ymlを書いてみました。 お試しなので、Elasticsearchはシングルノードで動かします。 Dockerは18.09.5、Docker Composeは1.24.0、ElasticsearchとKibanaは7.0.0です。

最終的に以下のようなdocker-compose.ymlになりました。

version: '3.3'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.0.0
    volumes:
      - es:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    environment:
      - discovery.type=single-node
  kibana:
    image: docker.elastic.co/kibana/kibana:7.0.0
    ports:
      - 5601:5601
volumes:
  es:
    driver: local

Elasticsearchはデータの操作用に9200番ポートのみを開けています。 シングルノード構成でDockerのネットワーク外のElasticsearchと接続することもないので、9300番ポートは公開しません。 また、データの永続化のためにボリュームを割り当てています。

KibanaはElasticsearchにデータを保存するので、Kibanaはvolumeをマウントする必要はありません。 また、Kibanaが接続しに行くElasticsearchのURLのデフォルト値はelasticsearch:9200なので、上記のdocker-compose.ymlの場合は接続先の設定をする必要もありません(Docker Composeがネットワークを作成する際、サービス名をホスト名としてDockerが持つDNSに登録するようです)。 あと、networksを書かなくても自動的に一つのプライベートなネットワークが割り当てられるようなので、networksも省略しています。

コンテナの作成は以下の通りです。

$ docker-compose up -d

Elasticsearchに対して適当にGETしてみます。以下のような応答が返ってくれば成功です。

$ curl -XGET localhost:9200
{
  "name" : "c3b6be5bda80",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "tvBg1C7XQ_S8BlnifjGXmA",
  "version" : {
    "number" : "7.0.0",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "b7e28a7",
    "build_date" : "2019-04-05T22:55:32.697037Z",
    "build_snapshot" : false,
    "lucene_version" : "8.0.0",
    "minimum_wire_compatibility_version" : "6.7.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

あとはブラウザでlocalhost:5601にアクセスしてKibanaの画面が出れば成功です(もちろん外部からアクセスするときはlocalhostは読み替えてください)。 コンテナの起動とアクセスのタイミングによってはKibanaがElasticsearchに接続できていなさそうなメッセージが出ますが、少し待ってリロードすると繋がります。 公式のdocker-compose.ymlのように

    depends_on:
      - elasticsearch

と書いていても効果がなかったので、上記のdocker-compose.ymlには書いていません。

*1:この記事を書いているときに見当たりましたが