A certain engineer "COMPLEX"

開発メモ その92 Visual Studio 2017.3が単体テストを検出できない

Problem


題名の通り。
VS2017からVS2017.3に更新したところ発生しました。
これまでのVisual Studioでも同様の事例はありましたが、ここまできてもこのような現象が発生すると萎えます。

Solution


例のごとくStackoverflowで回答が。

Unit Tests not discovered in Visual Studio 2017
I have been struggling with VS 2017 since I installed it. Now it seems Unit Tests will only run from the command line "dotnet test."My project is ....

ただ、最終的にAnswerにはなっておらず、一部のコメント投稿者は、後述の方法で解決した模様。
私が試したのは、MSTest.TestAdapter, MSTest.TestFramework というMicrosoft製のNugetパッケージを更新する方法でした。

どちらも1.1.18になっていればOKかと。

開発メモ その91 WindowsでMiniconda2と3を共存させる

Problem


PythonのWindows用環境はAnacondaMinicondaが有名ですが、初期パッケージの数が少ないMinicondaを専ら好んで使っています。
そんなMinicondaはPython 2.7Python 3.6をインストールできるパッケージが用意されています。

これを使い分けて、Windowsの環境に共存させたいと思います。

Solution


Case of Anaconda

実は、Anacondaでの2と3の共存については記事があります。

Anacondaを用いてPython2とPython3を共存させる方法 (Windows) - 白猫学生のブログ
はじめに Pythonはずっと昔に3系列にバージョンがアップされましたが,いまだに2系列を使用している人が数多くいると思います.(自分もその一人です) 当時はライブラリ...

今回はこれを参考にさせてもらいました。

Case of Miniconda

やることは変わりません。
私は、Python2をデフォルトにしました。3をデフォルトにしてはいませんが、多分大丈夫?
まず環境変数ですが、

  • Miniconda2のインストール先
    • C:\Program Files\Miniconda2
  • Miniconda3のインストール先
    • C:\Program Files\Miniconda3

とします。
ユーザーの環境変数 (システムの環境変数ではない!!)PATHが、下記の順序で追加されているようにします。

  • C:\Program Files\Miniconda2
  • C:\Program Files\Miniconda2\Scripts
  • C:\Program Files\Miniconda2\Library\bin
  • C:\Program Files\Miniconda3
  • C:\Program Files\Miniconda3\Scripts
  • C:\Program Files\Miniconda3\Library\bin

最後に、コマンドプロンプトを立ち上げ、Miniconda3のインストールパスに移動します。
必要に応じて管理者権限は付与してください。
そして下記のコマンドを叩きます。

Try


コマンドプロンプトを立ち上げ直します。
そして、正しく共存できているかを確認します。

無事に共存できました!!

開発メモ その90 Visual Studio Code on WindowsでCMakeを使うとエラーになる

Problem


最新のCMake 3.9.2が悪いのか、Visual Studio CodeでCMakeを使おうとするとエラーになります。
WindowsのVisual Studio CodeでCmakeを使うという記事はたくさんあります。

VSCodeでC++デバッグ(Windows) - Qiita
# 概要Visual Studio Codeを使ってVC++のデバッグ+ビルドを行う方法CMakeの使い方等はこの記事には載せませんので注意してください。また、記事に対するもっと良い方法...

が、それでも上手くいかない。
Lixnuでは既に自分でも試しており楽勝のはずだったのですが...

具体的には、

Started new CMake Server instance with PID 13456
Build program for generator Ninja is not found. Skipping...
Build program for generator Unix Makefiles is not found. Skipping...
None of preferred generators available on the system.

というエラーが出力されております。

Solution


CMake toolsのIssueにヒントがありました。

CMake server: Unable to determine CMake Generator to use · Issue #132 · vector-of-bool/vscode-cmake-tools
After upgrading my cmake install to 3.7.2, enabling the cmake server option in the vs code settings, and restarting vs code, I get the message: "Unable ...

エラー出力にもありますが、Ninjaが存在しない、って言っているのでそれをインストールします。

What is Ninja?

Ninjaはスピードに特化した小型のビルドツールとのこと。
私はよくわからないので、詳しいことはググってください。

ninja-build/ninja
ninja - a small build system with a focus on speed

とりあえず、Githubのリリースから最新のバイナリをダウンロードして適当なフォルダに配置します。

Setup

続いて、Visual Studio Codeの設定に、下記のような内容を記述します。

設定後、Visual Studio Codeを再起動し、いつものようにCake: Quick Start的な感じで始めることが出来るようになっているはずです。

開発メモ その89 dlibの顔検出性能をCUDA ON/OFFで比較

Problem


前回はdlibをCUDAを有効にしたバイナリ、無効にしたバイナリを生成しました。

具体的に、CUDAを有効にしている状態で、どれだけ性能差が出るのかを比較したいと思います。

Preparation


まずは、実験に使う画像を用意します。
今回は下記を用意しました。


元画像: https://upload.wikimedia.org/wikipedia/commons/b/b7/G7_summit_at_Shimakan.jpg

4368x2912の大きなサイズです。

次に計測を行うソースです。
examples\face_detection_ex.cppという顔検出のサンプルがあります。

これに対して、上述の画像を認識させると

こうなります。

Try


このソースを下記のように改造します。

要するに、入力した画像ファイルを100回認識させ、その処理に要した合計時間と平均時間を算出するようにしただけです。
下記がその結果です。

Left align Total(ms) Average(ms)
w/o CUDA 1007778.0000 10077.7800
w/ CUDA 997522.0000 9975.2200

正直微妙です。約10%しか差がありません。

.NETでLinuxと遊んでみる Visual Studio Code編 第8回

Introduction


前回は、自作のSharedライブラリに定義された関数をP/Invokeで呼び出してみました。

しかしながら、毎回毎回/usr/local/libとかにコピーするのってどうなんでしょう?
Windowsみたいに、実行ファイルと同じディレクトリにSharedライブラリを配置しても動作するのでしょうか?
Windowsの場合、exeが呼び出すdllは、実行ファイルから以下の順序で検索されます。

  1. 実行中のプロセスの実行形式モジュールがあるフォルダー。
  2. 現在のフォルダー。
  3. Windows システム フォルダー。 このフォルダーへのパスは、GetSystemDirectory 関数が取得します。
  4. Windows ディレクトリ。 このフォルダーへのパスは、GetWindowsDirectory 関数が取得します。
  5. 環境変数 PATH 内に記述されたフォルダー。

Linuxの場合、3,4以外は同じ条件で試すことができそうです。
ただ、.NET Coreの場合、dotnet runで動作する場合のカレントディレクトリに関して情報がないので、2もちょっと先送り。
最終的に下記の内容をテストしてみます。

  1. Sharedライブラリをシステムから削除
  2. Sharedライブラリを実行ファイルと同じフォルダに配置
  3. LD_LIBRARY_PATHと実行ファイルと同じフォルダの優先順位

Try


サンプルは、.NETでLinuxと遊んでみる Visual Studio Code編 第7回と同じものを使います。

Sharedライブラリをシステムから削除

これは動かないはずです。
実行ファイルと同じディレクトリ、/usr/local/lib64にSharedライブラリが存在しないことを確認してから実行してみます。

Windowsと同じように、System.DllNotFoundExceptionがスローされました。
期待通りです。

Sharedライブラリを実行ファイルと同じフォルダに配置

きちんと動作しました。

LD_LIBRARY_PATHと実行ファイルと同じフォルダの優先順位

これは気になりますね。
別に.NET Coreに関係なく、Linuxの仕組みと同じような気がしますが...
実行時、どちらが呼び出されたかわかるように、Sharedライブラリ側を修正します。

実行ファイルに配置するSharedライブラリ

/usr/local/lib64に配置するSharedライブラリ

これらをそれぞれビルドして、/usr/local/lib64、実行ファイルと同じディレクトリであるbin/Debug/netcoreapp2.0/にコピーします。
また、環境変数LD_LIBRARY_PATHに/usr/local/lib64を追加します。
一応、各ディレクトリにSharedライブラリがコピーされたことも確認しておきます。
そして、dotnet runで実行します。

結果としては、実行フォルダのSharedライブラリが優先されました。
また、実行フォルダのSharedライブラリを削除しても、/usr/local/lib64のSharedライブラリが使用され、きちんと動作することもわかりました。

Conclusion


結論としては、Windowsと同じく、実行ファイルのあるディレクトリに配置されているライブラリが優先のようですね。