ubuntu20 にいれたdockerがdocker pullでproxyが通らない(解決)

ubuntu20 にいれたdockerがdocker pullでproxyが通らない(解決)

いろいろ調べてみたが、http_proxy環境変数を通せばよいらしいが、うまくいかない。
systemdなどの設定ファイルなどにhttp_proxyを入れてみたが変わらず。
原因は、snapでインストールしていたためで、環境設定用ファイルがデフォルトとは違う場所にあったため。
情報がなかなか見つからず、調べるのに時間がかかった。

snapでdockerをインストールした場合の設定ファイルは

/etc/systemd/system/snap.docker.dokerd.service

にあり、さらにそのファイルには、

EnvironmentFile=-/etc/environment

の行があり、なにやら環境設定はそれに書け、ということらしい。

/etc/environmentファイルにhttp_proxy環境変数を追加することで解決できた。

/etc/environment (修正前)

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"

/etc/environment (修正後)

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
HTTP_PROXY="http://<proxy_server>:<port>"
HTTPS_PROXY="http://<proxy_server>:<port>"

設定ファイルを修正したら、dockerを再起動する。

$ sudo snap stop docker
$ sudo snap start docker

これで、docker pull すると、指定したproxy server経由でdocker imageが取得できるようになった。

インターホン故障

年末年始にかけて自宅インターホンが壊れた

　自宅(集合住宅)のインターホンが故障してしまい、なぜか自分の部屋だけ
呼び出し音が鳴らず、不在通知が何個も郵便ポストに入っている状態。
再配達を依頼するにしても、このままでは受け取ることができず、不在通知、再配達の
無限ループに陥ってしまう。(別の場所で受け取るという手もあるが面倒くさすぎる)
なんとかして宅配の方に連絡先の電話番号を伝える必要があるのだがなかなか難しい。
そこで、「１階玄関のインターホンのそばに部屋番号と電話番号を貼り付けておく」
ということも考えたが、これだと、悪意のある訪問者にも電話番号をさらすことに
なってしまうので、さすがにやめた。
　ここで、ひと手間かけて、Google Glideノーコードのアプリ作成ツールで
電話番号を表示するだけのアプリを作り、このアプリのQRコードをポストに張り付けて、
不在通知を入れる時に気がついて連絡してもらえばいいのでは？
などと考え、とりあえずアプリを作成はしてみたものの、はたして、そんなことまで
やってくれるのか？という不安が残る。（そもそもそんな端末もってる？）
　一応、テスト的にやってはみたものの、修理は数日できてくれたので、
この試みがうまくいくのかどうか、結局、わからずじまいだった。

Qiita Advent Calendar

Qiitaで恒例のAdvent Calendarが始まっている。

Qiita Advent Calendar 2021 - Qiita https://qiita.com/advent-calendar/2021

この時期はやはり忙しく記事を書いたり調べたりする余裕はなさそう。
ふと思うのだが、日本のIT技術者のほとんどは年末・年度末は納期に追われて忙しい時期なので、こういうイベントに興味はあっても参加できない人が多いのではなかろうか。
（記事を書いている人がひまだとかいうつもりはまったくなく、ちゃんとネタを仕上げることができる人は偉いと思う。）
いっそ、GW前後あたりや、６月と１２月の年２回の開催とかにしたら、どうなんだろう。

cRIO(RealTimeLinux) C/C++ SDKをDockerで動かす

cRIO(RealTime Linux)用C/C++SDKをDockerで動かす

前回の投稿「 cRIO(RealTimeLinux)用のC/C++クロスコンパイル環境をUbuntu上に作る - 取るに足らないブログ 」では、UbuntuにcRIO(RealTIme Linux)のC/C++ SDKをインストールする話でしたが、 今回は、さらにDockerにC/C++SDKをインストールして、ビルドする環境を作ってみます。

インターネットに接続できてDockerがインストールしてあるPCがあれば、 DockerfileからSDKの入ったコンテナーイメージがすぐに作れます。

LabVIEW開発をメインでやっている人が一時的にC/C++ビルドできる環境を用意したい といった場合は、Dockerでビルドできる環境を作ったほうが楽かもしれない、という話。
実際、Dockerfileは数行だしコピペで作って、Docker buildすれば、あら不思議、30分もかからずに ビルドできる環境が手に入る。いらなくなれば作成したイメージを消せばよい。

C/C++ SDK ダウンロード

ひとまず、必要なのは、cRIO(RealTime Linux)用C/C++SDKです。
以下のページがからダウンロードしてください。

GNU C &amp; C++コンパイルツールx64 のダウンロード - NI

DockerfileとSDKインストーラ

適当なフォルダを作成して、以下のDockerfileと、ダウンロードしたSDKのファイルを配置します。

Dockerfile

From ubuntu:20.04

RUN apt-get update && apt-get install -y \
    python3 \
    cmake \
    ninja-build

RUN cd /tmp; mkdir sdkdir;
COPY oecore-x86_64-core2-64-toolchain-6.0.sh /tmp/sdkdir
RUN chmod +x /tmp/sdkdir/oecore-x86_64-core2-64-toolchain-6.0.sh \
    && /tmp/sdkdir/oecore-x86_64-core2-64-toolchain-6.0.sh
RUN rm -rf /tmp/sdkdir

Docker イメージビルド

DockerfileとSDKインストーラのあるフォルダに移動
Dockerビルドコマンドを実行

  $ docker build -t <tagname>:<version> .

baseは、Ubuntu20.04(64bit)にした。

インストーラをコンテナー側にコピーした後にインストールするのが無駄な気がするが うまい方法が見つからなかったので、ひとまずこのまま。

作成したDocker イメージの確認

  $ docker images

Dockerのイメージサイズが3G超えている。
Ubuntu自体は72Mなので、SDK、その他もろもろの方がでかそう。

Docker コンテナを実行

ホームディクトリにソースを配置するフォルダを作成（以下の例ではworkとした）
ソースをそのフォルダにコピーして、Dockerコンテナーを動かす。

  $ docker run -it --rm -v $PWD:/work <tagname>:<version> /bin/bash

docker では --it /bin/bashとすれば、コンテナ側の端末を開いた状態になるので、 そこで、CMakeやninjaを使ってビルドする、という形になる。
-v で、ソース、プロジェクトのあるフォルダをDockerコンテナ側に割り当てます。

ソースの編集・ビルド

ソースの編集などは、LinuxとかWindowsのVisualStudioCodeなど、ホスト側で使い慣れたもので編集、 ビルドは、Dockerコンテナーの端末から実行する、形になります。

サンプルソース

サンプルソースはこちら

alucky4416 / docker_ubuntu_rtlsdk_x64 · GitLab

cRIO(RealTimeLinux)用のC/C++クロスコンパイル環境をUbuntu上に作る

C/C++SDKをUbuntu20.04 64bitにインストール、サンプルをビルドするまで

以下、cRIOと記載した場合は、 CPUにAtom(x86_64)、OSにRealTimeLinuxを搭載 したものを指します。また、LabVIEWやRealTimeモジュールのバージョンは2018以降と考えてください。

SDKのダウンロード

C/C++ SDKは、NIダウンロードサイトで入手可能。400MB近くあるので注意。

GNU C & C++コンパイルツールx64 のダウンロード - NI

Windows版SDKはログインしなくてもダウンロードできるが、LInux版SDKはダウンロードできない（ダウンロードボタンが無効になっている）
Windows版SDKのDLが誰でもOKで、Linux版SDKのDLにはSSP購入が必要とか、なんだか変な条件だと思う。
そういえば、LabVIEW CommunityEditionのLinux版も相変わらずActivation不能の状態で半年以上放置されたままで、 なんのためにLinux 版をリリースして公開までしているのか、さっぱりわからん。
これだけLinuxが普及しても、NIのLinuxユーザへの塩対応は相変わらず。
（Silverlightのサポート切られたり散々な目にあわされているのにMSローカル技術依存から脱却できず。このままRasPiに市場をとられることになりそうですね。）

SDKの使い方についての資料

WIndowsホスト用SDKをVisualStudioCodeから利用する方法についてのドキュメントが公開されていますので、 それを参考にします。

NI Linux Real-Time Cross Compiling: Using the NI Linux Real-Time Cross Compile Toolchain with Visual Studio Code - NI Community

Linuxホスト用SDKのインストール

SDKには、C/C++コンパイラなどの最低限の開発ツールが含まれています。
（Ubuntu用のC/C++やツールチェインは不要、インストールしなくてもよいです。）
それに加えて、CMakeとninjaというビルドツールのインストール。
さらに、CMakeかninjaのインストールでPythonが必要らしかったので、それもインストール。

$ sudo apt-get update
$ sudo apt-get install python3 cmake ninja-build

サンプルのビルド

先に紹介したCrossCompileのドキュメントから、Windowsホスト用のテンプレートをダウンロードして、 それを元にLinuxホストでビルドしてみます。

テンプレートのダウンロード
Template.zipダウンロード

CMakeList.txtの修正

CMakeList.txtは、Makefileにあたるもので、ビルド手順を設定したファイルです。
ダウンロードしたTemplate.zipを展開して、NI_Linux_RT_x64_Template/build/CMakeList.txtをコピーして利用します。

  1. SDKのインストールされたパスに修正する
  2. サンプルアプリケーションのビルド設定を追加する

Windowsホスト用のCMakeList.txt
コンパイラなどのツールのパスがWindowsホスト用になっています。

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

# root path for toolchains
set(toolchain_path C:/build/18.0/x64/sysroots)

# compilers
set(CMAKE_C_COMPILER ${toolchain_path}/i686-nilrtsdk-mingw32/usr/bin/x86_64-nilrt-linux/x86_64-nilrt-linux-gcc.exe)
set(CMAKE_CXX_COMPILER ${toolchain_path}/i686-nilrtsdk-mingw32/usr/bin/x86_64-nilrt-linux/x86_64-nilrt-linux-g++.exe)

# compiler flags
set(CMAKE_SYSROOT ${toolchain_path}/core2-64-nilrt-linux)
set(CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES ${toolchain_path}/core2-64-nilrt-linux/usr/include/c++/4.9.2 ${toolchain_path}/core2-64-nilrt-linux/usr/include/c++/4.9.2/x86_64-nilrt-linux)
set(CMAKE_<LANG>_FLAGS "-Wall -fmessage-length=0")
set(CMAKE_<LANG>_FLAGS_DEBUG "-O0 -g3")
set(CMAKE_<LANG>_FLAGS_RELEASE "-O3")

# define search behavior
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

Linuxホスト用に修正したCMaikeList.txt
コンパイラなどのツールのパスをLinuxホスト用に修正しています。
それに加えて、project(hello)、add_executalble()でビルド設定を追加しています。

cmake_minimum_required(VERSION 3.2)

project(hello)

add_executable(hello ../src/hello.c)

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

# root path for toolchains
set(toolchain_path /usr/local/oecore-x86_64/sysroots)

# compilers
set(CMAKE_C_COMPILER ${toolchain_path}/x86_64-nilrtsdk-linux/usr/bin/x86_64-nilrt-linux/x86_64-nilrt-linux-gcc)
set(CMAKE_CXX_COMPILER ${toolchain_path}/x86_64-nilrtsdk-linux/usr/bin/x86_64-nilrt-linux/x86_64-nilrt-linux-g++)

# compiler flags
set(CMAKE_SYSROOT ${toolchain_path}/core2-64-nilrt-linux)
set(CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES ${toolchain_path}/core2-64-nilrt-linux/usr/include/c++/6.3.0 ${toolchain_path}/core2-64-nilrt-linux/usr/include/c++/6.3.0/x86_64-nilrt-linux)
set(CMAKE_<LANG>_FLAGS "-Wall -fmessage-length=0")
set(CMAKE_<LANG>_FLAGS_DEBUG "-O0 -g3")
set(CMAKE_<LANG>_FLAGS_RELEASE "-O3")

# define search behavior
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

プロジェクトフォルダを作成、フォルダ構成は以下のようにする

<Project>
  <src>
    hello.c
  <build>
    CMakeList.txt

CMakeList.txtの配置

CMakeList.txtファイルはbuildフォルダに配置する

サンプルソース(hello.c)を作成

サンプルソース(hello.c)を作成して、srcフォルダに保存する

hello.c

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
  puts("Hello, world");
  return EXIT_SUCCESS;
}

CMakeでNinja用のビルドファイルを生成
build フォルダに移動、以下のコマンドを実行

 $ CMake -G Ninja

生成されたビルド設定を元に ninja を使って、実行ファイルをビルドする
build フォルダに移動、以下のコマンドを実行

 $ ninja

hello.c から hello という実行ファイルが瞬時に作成される。
出来上がった実行ファイルを、cRIOにコピーして動作を確認する。
Windows版のSDKでの開発についてのドキュメントでは、VisualStudioCodeを使った手順の説明となっており、 このあと、GDB を使ったリモートデバッグの方法の説明になる。
VisualStudioCodeはLinux版もでてきているので、興味のある方はトライしてみてほしい。

サンプルソース

サンプルソースはこちらで公開しています。
alucky4416 / docker_ubuntu_rtlsdk_x64 · GitLab

蛇足

できあがった実行ファイルのサイズは、Go言語で同じようなソースからビルドした実行ファイルよりかなり小さい。
(Go言語でビルドした実行ファイルはかなり大きい、という表現の方が適切かな?)
今回、SDKを使ってcRIO用にビルドした実行ファイルはcRIOでは当然動くが、Ubuntu(x64)で実行しようとするとエラーになる。
CPUも同じx86_64で、OSもLinuxだから動きそうな気がするが、外部ライブラリ依存の違いなのかと思う。

LabVIEW:: 順応性VI (Malleable VI)のサンプル

LabVIEW:: Malleable(順応性)VI について

聞き慣れない英語で、今ひとつ、ピンとこない、使いあぐねています。
英語だと、Malleable = 従順な、順応性のあるという意味らしいのですが、同時に導入されたアサート(Assert)と相まって、使いどころも思いつかない。
とりあえず、サンプルを作ってみれば少しはイメージがつかめるかと思い、以前より、作り的になんとかならないかと考えていた「RGB To Color」を題材にサンプルを作成してみた。

RGB To ColorのMalleable化

LabVIEWの標準に付属しているRGB To Color関数が配列データには対応していない。 RGB to Color VI - LabVIEW 2018 Help - National Instruments

f:id:alucky4416:20210523092744p:plain
RGB to Color

実際の画像データ処理では、配列データになっていることが多いので、
このVIを使って、R/G/Bのそれぞれの配列データを、Colorに変換するとなると、
ForLoopで処理することになるが、それだとやはり処理に時間がかかる。

f:id:alucky4416:20210523093133p:plain
RGB to Color on ForLoop

RGB To Color のダイアグラムを見ると、Join Numbersという関数を使っており、
U8 同士をUpper/Lowerで結合してU16に変換（あるいは、U16同士をUpper/Lowerで結合してU32に変換） を組み合わせて、R/G/BのデータをUpper/Lowerで結合してU32のColor値に変換している。

f:id:alucky4416:20210523093307p:plain
RGB to Color Diagram

Join Numbersには、配列データを渡すことができるので、以下のようにForLoopにしなくてもR/G/Bの配列データをColorの配列に変換できる。

f:id:alucky4416:20210523093615p:plain
RGB to Color Speed up version

これで高速化が図れましたが、今回は、さらにこれをMalleable VI化してみることにします。

作成手順

  1. LabVIEWのファイルメニュー>>新規で作成するメニューが表示されるので、「順応性VI」を選択

    f:id:alucky4416:20210523094914p:plain
    FileMenu>>New>>MalleableVI

  2. 通常のVIとほぼ同じで、拡張子.vimがフロントパネル・ダイアグラムが表示される。

    f:id:alucky4416:20210523095110p:plain
    Malleable VI

  3. 関数パレットのストラクチャから「タイプ特化ストラクチャ」を選択してダイアグラムに配置
    Type Specialization Structure - LabVIEW 2018 Help - National Instruments

  4. タイプ特化ストラクチャの「承認(Accepted)」に、LabVIEW標準関数のRGB to Color.viのダイアグラムの中身をコピペする。

    f:id:alucky4416:20210523095313p:plain
    Type Specialization Structure

    ダイアグラムエラーのため、このケースは非承認に変わります。

  5. 入出力端子をタイプアサーションシーケンスの外に移動する

    f:id:alucky4416:20210523100302p:plain
    Pull the terminal out of the structure

    エラーが解決されたため、ケースが承認に戻ります。

  6. 他のケースは「無視」となっていますが、空のダイアグラムままにですが、そのままにしておく。

  7. 入出力端子をVIのコネクタパンに割当

    f:id:alucky4416:20210523101229p:plain
    Assign terminals to the connector pan

  8. このVIを保存。ひとまず RGBtoColor.vim として保存する。
    これで順応性VIのRGB To Colorの完成。

新しくVIを作成して、先に作成した順応性VIのRGB To Color.vim をダイアグラムに配置。

f:id:alucky4416:20210523102047p:plain
Using RGBtoColor.vim

入力RGBに渡すデータが配列の場合、出力Colorも配列に変化する。

仕組みの説明

タイプ特化ストラクチャの「承認(Accepted)」に合致しているものがあれば有効になり、最初に合致したもの以外は無視される。
今回の順応性VIのRGB To Color.vimでは、入力端子のR/G/Bにスカラー値を配線すれば、Join Numbersはスカラー値のまま計算、結果出力もスカラー値になります。
入力端子R/G/Bに１次元配列を渡せば、Join Numbersが配列での計算になり、結果出力も配列になります。
多態性VIの場合は、適用するデータ型ごとにVIの作成が必要だったのに対して、順応性VIの場合は、一つのVIで対応できるので作成が楽です。
順応性VIは、通常のVIと違い、VIの端子に接続されたデータ型は決まっておらず、渡されたータ型による動作の違いをプログラム的に対応させる、ことができるVIということのようです。

順応性VIとアサートの仕組みの導入と共に追加されたいくつかの順応性VI型の標準関数には、タイプ特化ストラクチャを使っていないものもあります。そうしたVIは、Variant型を使用しています。
データ型によらず処理が共通化できるものは、タイプ特化ストラクチャすら不要ということでしょう。

LabVIEW for Linux Ubuntuでのアンインストール

Ubuntu にインストールしたLabVIEWのアンインストール

インストールに使用したisoファイルをマウント、

sudo ./UNINSTALL

を実行するのだが、
Ubuntuにインストールした場合は、結局、以下のフォルダ２個を rmコマンドで削除しなさい、とメッセージがでるだけなので、その通りに実行すると、一瞬でアンインストール完了となります。 Windowsのそれに比べると、非常にあっさりしていてよろしい。

. usr/local/natinst/LabVIEW-20??-64/
. /usr/local/lib64/LabVIEW-20??-64/

ということで、フォルダを２つ削除するだけでよいので、アンインストールのためだけに isoファイルを大事にとっておく必要はありません。

Windows版LabVIEWのように大量のレジストリ登録などもなさそうなので、バージョンアップやバージョンダウン？も気軽にできそう。