[git]branch名にスラッシュは使えるが、使うなら最初から使うこと

他の人のgitリポジトリを見ていたのだが、ブランチにスラッシュを使っていた。
作業者ごとに掘っていたり、課題ごとに掘っていたりと、なんか見やすい気がする。

やだ、カッコイイ、やってみたい(ミーハー)！

$ git checkout -b test1
$ git checkout -b test1/help
fatal: cannot lock ref 'refs/heads/test1/help': 'refs/heads/test1' exists; cannot create 'refs/heads/test1/help'

話が違うじゃないか・・・。

ネット検索すると、branch名と同じ名前のディレクトリをmkdirするときにエラーが出たので失敗している、ということらしい。
Using the slash character in Git branch name - Stack Overflow

mkdir -pしてないからディレクトリが掘れないのか？と思ったが、そうではない。

$ ls -F .git/refs/heads/
master  test1

ああ、branchで作るのって、ディレクトリじゃなくてファイルなんだ。
てっきり、ディレクトリを作って、その中に管理ファイルを置くものだとばかり思っていたのだ。
mkdirして失敗するのは、既にディレクトリと同じ名前のファイルが存在しているからだ、ということになる。

branchつくって作業をしていたけど、ついでにこっちの作業も並列で進めたくなって、でも元のbranchから派生させるようなものでもないから今のbranchから作りたくて、どこかの時点でマージさせたい、ということがあって、そこでスラッシュを作って派生しているのがわかるようにしようと思っていたのだ。
アンダーバーで区切ればよいのだけど、単語の切れ目で使っているので、それはそれで分かりづらい。

ともかく、gitのbranch名にスラッシュは使えるのだが、使うなら最初からスラッシュを付けて作っておかないと後からはできないよ、という話でした。

[c++]Boostのdijkstra_shortest_paths()

Cで、dijkstra法による経路探索を行いたかった。
最短の経路探索法なら何でもよいのだが、思いつくのがdijkstra先生の方法しかなかったのだ。

一応、大昔に受けた授業でやった記憶だけは残っている。
動的計画法だのなんだのかんだの。
だから、アルゴリズムの本を読めば記憶が甦ってくるんじゃなかろうかと期待したのだが、うん、ダメだね。

そして最初に書いたように、経路探索を行いたいだけで、別に経路探索するアルゴリズムを自分で実装したいわけではない。
ライブラリでもサンプルソースでも、動けばよかろうなのだ。

よかろうなのだが、なかなか気に入ったソースが見つからない。
よく見るのは、M x Nの2次元配列を作るタイプだ。
しかし、今回は動的に増えていくので、そういう書き方だとやりづらいし、メモリをいっぱい使うことになるので嫌だ。

1ヶ所見つけたのだが、そこはサイトがGPL1.2で、これはこれでよろしくない。
もう少しゆるめのライセンスがよいのだ。

そこで妥協したのが、C++にすることだった。
今作っているCのライブラリさえ使えればよいので、C++でもよいのだ。

C++といえば、やはりBoostよね。

---

Boost Graph Library: Dijkstra's Shortest Paths - 1.65.0

うーん。。。すごく見づらいぞ。
蛇のアイコンもあるし、pythonと関係あるのか？

もっとわかりやすいサイトがあるはず、と探すと、ありました。
グラフ - boostjp
ありがたいことに日本語だ。

始点Sから終点Zまでの経路探索をするサンプルになっている。
ノード・・・じゃなくてvertexと表現している。頂点か。
そして、頂点と頂点を結ぶ辺をedgeという。
edgeには重みがあり、それはweightだ。

というのはサンプルソースの最初の方を読んでなんとなく分かったが、型とか使い方になるとサンプルソースを読んでも今ひとつ分からない。
いきなりdijkstraのところからやるのではなく、Boostのgraphというものについての考え方や方針を把握した方がよさそうだ。
これも同じページの最初の方に書かれている。

が、しかしこれは・・・複雑だ。
日本語で説明してあって、さらに例まで載っているからわかるものの、そうじゃなかったら使い切れない気がする。

[btc]confirmation

Bitcoinだけではないと思うが、ブロックチェーンに関することをやっていると「confirmation」というものに出くわすと思う。

自分がBitcoinで取引するためにトランザクションを作ってブロックチェーンに公開する場合、だいたいこういう流れになる。

1. 自分が送金したい相手に対してのトランザクションデータを作る
2. トランザクションデータをブロックチェーンに公開するため、どこかのノードに送信する
3. (トランザクションデータが正しくて、ブロックチェーンのノードに受け入れられたとする)
4. そのノードが、他のつながっているノードに対してトランザクションデータを転送する
5. 一定期間が経つと、マイナーがブロックを作り始める
6. あるマイナーが作ろうとするブロックに、自分が送信したトランザクションデータが取り込まれる
7. そのマイナーが他のマイナーとの競争に競り勝ち、作ったブロックがブロックチェーンに公開される

大ざっぱに、だ。
まだマイニングしたことがないので、詳細な流れは把握していない。

さて、confirmationというのがこの流れのどこに出てくるかというと、「ブロックに取り込まれたときが1confirmations」だ。
ブロックに取り込まれるまでは、mempoolという貯木場みたいなところにトランザクションが浮かんでいるだけだ。

では、2confirmationsはいつかというと、1confirmationsになったブロックに、次のブロックが連結したときだ。
以降、ブロックが載っていくごとにconfirmationは増えていく。

---

一般的に、confirmationが6以上であれば大丈夫、といわれている。

大丈夫？何が？？

最初に書いておかねばならんが、私はこの辺の数学的な検証については非常に疎い。
つまり、うん、わからんのだ。。。
だいたいどこにでもそう書いてあるから、そうなんだろう、くらいの根拠しかない。
まあ、6というと、6σとかあるから、なんかそれっぽいな、程度しか言えることがない。

ただ、Bitcoinのブロックチェーンには「展性」という脆弱性がある。
トランザクション展性、などと呼ぶらしい。
詳しくないので割愛するが、実際に開発している間に受けると、かなりびっくりする。
自分がトランザクションを作って、トランザクションをブロックチェーンに公開して、それが自分の立てたノードに受け入れられたところまで確認しているのだが、コーヒー飲んでおしゃべりして、そろそろconfirmationが増えたかと思って確認しようとしたら、TXIDが存在しない、ということになるのだ。

ああいうのを受けてしまうと、いろいろ考えますわな。

[c/c++]設定ファイルを読みたい

プログラムを作っていて、設定ファイルを使いたいことがある。
引数に設定してもよいのだが、個数が多かったり、同じ設定を何度も使うことになったりすると、どうせなら設定ファイルにしてしまいたいのだ。

Linuxには、これといった設定ファイルの書式がなさそうではあるが、だいたいはこんな感じだと思う。

• 項目=設定値
• コメント行は#
• =の前後にスペースがあったり、空行があってもOK

「項目=設定値」だけであれば、こんな感じのことをやっていけば読込むことができる。

char name[32 + 1];
fscanf(fp, "name=%32s\n", name);

(\0は%32sの中に入るんだっけ・・・)

しかし、こんなのをゴリゴリとコーディングしていくのも面倒だ。
それに、これだとスペースや改行を処理することができないので、割り切ってしまえばよいものの、なんか、ねぇ。

また、そういうのを自作したいわけでもない。

---

ネットで「linux 設定ファイル 編集」なんて検索しても、期待するものが見つからない。。。
ようやく見つけたのが、こちら。

benhoyt/inih: Simple .INI file parser in C, good for embedded systems

iniファイルのパーサーだそうな。
セクションを[]でわけるし、コメントは「;」だけど、コメントはINI_INLINE_COMMENT_PREFIXESで変更できるらしい。
READMEに載っているサンプルで読込んでいるtest.iniは[protocol]と[user]というセクションがあるけれども、がなくても使えるのではなかろうか？

まずは、ライブラリを作る。

$ git clone https://github.com/benhoyt/inih.git
$ cd inih/extra
$ make -f Makefile.static
$ cd ../examples
$ gcc -o tst ini_example.c -L../extra -linih
$ ./tst
Config loaded from 'test.ini': version=6, name=Bob Smith, email=bob@smith.com

うん、シンプルでよいじゃないか！

では、test.iniのコメントを#にして、カテゴリーを削除したファイルではどうなるか・・・。
うーん、エラーにならず、変な値が読み取れてしまった。

サンプルソースを見ると、handler()の中でsectionを比較するようになっていた。
MATCH()マクロからsection比較している部分をなくすと、読み込めるようになった。

よしよし。

---

最後に、#をコメントにしたMakefileを載せておこう。

https://gist.github.com/hirokuma/a2c4bab70d43db8ddf17b1a673da1b3e

Makefileでgccの文字列マクロを設定するときって、こうやるのね。。。
#もエスケープせんといかんのは、盲点だった。

[c/c++]中途半端にハンガリアン記法風の名前を使っている

私がC/C++を覚えていた頃は、変数名などの名前付け方法に「ハンガリアン記法」というものがあった。

なくなるものではないので、今もあるとは思うが、面倒なのであまり使われていないと思う。
私も、ちゃんと使ったことはない気がするのだが、型を変数名に反映させるなんてやめてくれー、と思っていた。

しかし、だ。
自分でコーディングするときに、型を変数名に反映させている場合があることに気付いた。

boolとポインタだ。
boolの場合は「bFlag」とか「b_flag」とかだし、ポインタは「pData」とか「p_data」とかだ。

もしかすると、これもハンガリアン記法になるんじゃなかろうか。
いや、そもそもハンガリアン記法ってなんなのだろうか？

---

ハンガリアン記法 - Wikipedia

ハンガリー出身の人が考案者だからハンガリアンなのか。。。
チャールズ・シモニーさんらしいから、チャールジアンとかシモニアンとかでもよかったんじゃなかろうか。
でも、逆ポーランド記法みたいなこともあるし、それはそれでよいのかもしれん。

そして、論文に書いてあった「type」を、データ型として当てはめてしまったので型を反映させるような読まれ方になってしまったが、考案者としては「変数の意味や使用目的」と意図していたそうな。

まあ・・・「type」をそう読み取ってしまったのは、仕方ないよな。。。
それに、私もWikipediaを読んだだけで、原文を当たったわけではない。
だから、本当にそうなのかはわからんが、それっぽいよな。

こちらが、たぶん原文。
Hungarian Notation
なんだ、Microsoftの人だったのか。

表に例があるし、コードもあるのだが、データ型を名前にしている感じはしないな。

Wikipediaには「アプリケーションハンガリアン」と「システムハンガリアン」の2種類があると書かれているが、これは論文に書いてあったものではなく、Microsoftがハンガリアン記法を決めたときに作ったものなのかな。

---

Wikipediaに書いてあるシステムハンガリアン風の書き方で私が使っているのは、これらだ。

• 論理型(頭にbをつける)
• ポインタ型(頭にpをつける)
• ファイルスコープの変数(頭にmをつける)
• グローバルスコープの変数(頭にgをつける)
• typedefした型(お尻に_tをつける)

最近はC++を使ってないので、classを作ったらどうするかはよくわからん。
大文字で始める、くらいのルールにしそうな気がする。

ファイルスコープのポインタ型、みたいな合わせ技もあるのだが、それは「mpData」みたいな書き方にしている。

引数は大文字で始まり、スタック変数は大文字を使わない、というルールにしているつもりなのだが、あんまり守ってない。。。
Dataとdataとか、pDataとp_dataとか。
なるべく守ろうとするのだが、1つの関数を書いていて大きくなりすぎてしまったからstatic関数に分ける、なんてことをやってしまうと、変数として小文字を使っているので、関数の仮引数を大文字にしてしまうと面倒になるので放置、ということがしばしば。

ああ、そういうのが変なるールを作ったことによるコストなのだよな。。。

プロジェクトだと、ある程度コーディング規約を決めないとバラバラになりすぎるのだけど、ぎちぎちにしてしまうとコーディング自体が楽しくなくなるので、難しいところだ。

[linux][c/c++]現在時刻の取得

Linuxで時間の取得を行いたい場合がある。
今の時間だ。
time(NULL)でepoch timeを取得していたのだが、それでよいのか自信がなくなってきた。

マイコンの場合、RTCに設定した時刻が取ってこれるだけで、それ以上でもそれ以下でもない。
それに、RTCから自分で値を引っ張り出さないといけないので、epochも何も気にしようがない。

しかし、time()はきっとライブラリ側でOSが管理しているしくみに置き換えられているはず。
Linuxで時間といえばgettimeofday()だよなあ、と検索したのだが、どうもgettimeofday()は廃止予定らしい。
gethostbyname()もそんな感じだったな。。

推奨されているのは、clock_gettime()。
まずは動かしてみよう。

https://gist.github.com/hirokuma/17bdf87bf3c8c6f29008e74635f9984e

2017/08/18 10:10くらいにBash on Ubuntu on Windowsで実行させると、こうなった。

$ ./tst
tv_sec=1503018649, tv_nsec=105938100

ネットでepochを現在時刻に変換するサイトを見つけてやってみると、JSTとして変換すると現在時刻になった。
dateコマンドでは、こうなる(あれこれしているうちに5分くらい経ってしまったが)。

$ date
Fri Aug 18 10:15:53 DST 2017

これは、内部ではUTCで管理していて、出力時にJSTの下駄を履かせているという考え方でよいのだろうか？
(DSTになっているのも気になるが。。。)
VirtualBoxで動かしているXubuntu16.04でも同じになったので、Bash on Ubuntuがそうしているわけではなさそうだ。

そして、epoch timeは各地の時刻ではなく、UTCで出すというのが共通の認識ということでよいのだろうか。
数字しかないので、UTCがデフォルト、のようなルールがないと困るのだけど、明示的に書いてある資料が見つからない。

オライリーの「C言語クイックリファレンス」には、

• time()は現在のカレンダー時刻を返す
• これは、紀元と呼ばれる
• Unixの紀元はUTCの1970年1月1日 00:00:00

とある。
そして、「紀元」は"epoch"だから、epoch timeはUTCということでいいんじゃないかな。
うんうん、そうしておこう。

tig

ファイル履歴管理にgitを使っているのだが、未だにコマンド慣れしていない。
慣れない操作で失敗するのも嫌なのでGUIのツールを使っていたのだけど、最近はクラウド上につくったVMを扱わんといかんことも多くなり、なるべくgitをコマンドラインで使うようにしている。

でも、ある程度はGUIっぽく表示してくれた方が見やすいじゃないか。
そう思って探していると、tigというコマンドが見つかった。

gitを逆に並べたtigだが、コマンドラインで動かすツールながらも、GUIっぽく出してくれる。
なんというか、FDみたいなコマンドになるのかもしれん。
・・・FDってWindowsのみだったかも。

tigの操作は、ちょっとviっぽい。
カーソルの移動がそうだからか。

使うのは、ステージに挙げたりcommitしたりするところが主だ。
git addするとき、ファイルのパスをいちいちコマンドで書くのが面倒なのだよ。

tigを立ち上げて、sを押して更新したファイルの一覧を出し、uを押してcommitしたいものをステージに上げる。
上げ終わったら、大文字のCを押してcommitするエディタを起動する。
うちではnanoが立ち上がった。

historyなんかも重たくなく見られるので、使いこなせると便利そうだ。

---

ただ、最近はtigする気力も無いので、VirtualBoxでGUIが動く状況であればVisual Studio Codeを使っている。
差分なんか見やすいしね。

[勉]MIPI

Xilinxからメールが来た。

MIPI D-PHY 搭載のザイリンクス UltraScale+ デバイス

MIPI?
初めて聞く単語なので、これは調べねばなるまい。

---

Mobile Industry Processor Interfaceの略らしい。

デバイス古今東西(17) ―― 撮像デバイスの変遷と次世代標準インターフェースMIPI規格｜Tech Village （テックビレッジ）　／　CQ出版株式会社

「モバイル機器向け」なのだそうだ。
記事が2010年なので、7年前にはすでにあった規格ということになるな(2003年らしい)。

シリアル通信というと、UART, I2C, SPI, USBなどなど、たくさんある。
そこに連なるようなものなのか、

こちらが、mipi allianceのページ。
https://www.mipi.org/

仕様書をちょっとくらい見てみようかと思ったけど・・・数が多くて止めた。
Specifications Overview

カテゴリーだけで、これだけある。

• Audio
• Camera and Imaging
• Chip-to-Chip/IPC
• Control and Data
• Debug and Trace
• Display and Touch
• Physical Layers
• Software Integration

まあ、NFC Forumの規格もたくさんあったし、そういうものかもしれん。

---

これで終わってしまうのはさすがに悔しいので、Xilinxのメールで紹介された規格くらい調べておこう。

「MIPI D-PHYを搭載」

mipi allianceの説明ページは、こちら。
PHYなので、物理層なのだろう。
スマートフォンのカメラやディスプレイ向きのようだ。

技術的な内容は出てこなかった。

MIPI ‐ 通信用語の基礎知識

同期式とのこと。
ソース同期と書いてあるので、クロック線は持たず、データ自体がクロックと同じ意味を持つということか。
マンチェスターみたいな感じかな？
マンチェスターだと1bitを2データで表すが、差動だと1データ分の時間で2データを表現できるので、倍の速度になるのかも。
上限が1Gbpsとなっているので、なにか技術的に上限が発生するのだろうが・・・そこまではわからんな。

---

これで終わろうと思ったが、最後に見たページではもう少し情報が載っていた。
前田真一の最新実装技術あれこれ塾：第47回 内部ディスプレイ接続規格 (4/4) - MONOist（モノイスト）

高速モードは1.5Gbpsみたいだ。
そして、予想と違ってクロック線があり、ビデオ信号だとレーンを複数用意するようだ。
下手に予想するもんじゃないな。

hexdumpで16進数を出力したい

バイナリファイルをソースコードに埋め込みたいことがある。
画像データを配列として使いたい場合などだ。

ファイルから読み込んで%02xなどで出力させるだけなのだが、いちいちコマンドを作るのも面倒だ。
hexdumpというコマンドがあるのでやってみたが、オプションを使えばなんとかいけそうなものの、よくわからん。
だいたい、なんで2バイトごとに出すのがデフォルトなんだ？

と、コマンドに文句を言ってもしょうがないので、オプションを調べよう。

hiro99ma blog: hexdumpのフォーマット

0xを付けた出力をしたい場合は、これでよい。
これは8バイトごとに改行しているので、8/1になっている。

$ hexdump -e '8/1 "0x%02x, " "\n"'  abcdef.bin

pythonで、ひたすらずらずら並べた文字列を作りたいこともある。

$ echo "$(hexdump -e '1/1 "%02x"' abcdef.bin)"

echoはなくてもよいのだけど、改行を付加しないので、コマンドラインで実行すると見づらかったのだ。

で、hexdumpを16進数の1桁ダンプ以外で使うことが無さそうなので、aliasに登録しようとした。

alias hexdump='hexdump -e '\''1/1 "%02x"'\'

いやあ、こんなに難しいとは。。
シングルクオーテーションで全体を囲む中にシングルクオーテーションを入れたい場合は、

• 一度シングルクオーテーションを閉じる
• \'を付ける
• シングルクオーテーションを始める

ということをせんといかんそうだ。

青文字がシングルクオーテーションで囲んだ範囲、赤文字がエスケープしたシングルクオーテーションとなる。

alias hexdump='hexdump -e '\''1/1 "%02x"'\'

aliasをシングルクオーテーションで囲むのは、スペースも含めて入れてほしいという場合だけのはず。
まあ、これで登録しても、aliasコマンドで見ると

alias hexdump='hexdump -e '\''1/1 "%02x"'\'''

なんだけどね。

[c/c++]lmdbでの検索

たまにはFPGAを離れて、DBのことをやってみるのもよいだろう。
そうだな、lmdbなんてどうだろうか？

最後にlmdbのことをやったときは、付属サンプルのmstest.cを見ていくだけだった。
今回は、KEYから検索したり、VALUEから検索するときのことを考えよう。

今のところ、私のlmdbに対するイメージはこうだ。

mdb_env_create()で1つのENVを作り、mdb_env_open()する。
ENVからmdb_txn_begin()でTXNを開始し、同じトランザクション内で処理したいものをmdb_dbi_open()でDBIを開く。
あとは、TXNとDBIのセットでmdb_put()したりmdb_get()したり。
終わってトランザクションを確定させたいなら、mdb_txn_commit()してmdb_dbi_close()。
変更したものを破棄するなり、読込むだけで保存するものが無ければ、mdb_txn_abort()だけ。
mdb_put/get()だけでなく、cursor系のAPIもある。

さて、検索するには、どのAPIを使うのがよいのか。。。

いまのところ、私の認識はこうだ。

• KEYが指定できる場合は、mdb_get()
• それ以外は、cursor系APIでDBIの中を全部探す

SQLではないので、自分でやるしかないだろう。
mdb_cmp()で比較するようなことができるのかと思ったが、関係なさそうだ。

自分でやるしかないので、全部KEY-VALUEに突っ込むだけではなく、DBIをうまいこと分散させるのもよいだろう。