emacsclient でファイルを開かずにフレームを開く
Emacs の起動高速化の関連でちょっと調べてた件。
普通に emacsclient
コマンドを使うとファイルを指定しないといけないんだが、
$ emacsclient -c
でフレームだけ開ける。 終了を待ち合わせないで良いなら
$ emacsclient -c -n
で OK。
これを使って
「Ubuntu, macOS, Windows あたりの環境において
アイコンクリックで高速にEmacs起動するようにできないかな…」
とか考えをめぐらし中…。
ログイン時に emacs --daemon
するか、
初回アイコンクリック時だけ emacs --daemon
してから emacsclient
叩くみたいなことしないとダメかなぁ…。
Doxygen で internal な実装群を隠す
隠すやり方がいくつかあるんだけど、 どう隠したいかで使うべきコマンドが違うみたい…。
遭遇したケース
通常、 source file local な class やメソッドに対する Doxygen コメントとかは
Doxygen の設定の EXTRACT_〜
を適切にすれば出力されないはず。
私が今回遭遇したケースは
- constexpr function なのでヘッダーに実装を書いてる
- Google C++ Style Guide に則るとヘッダーファイルでは無名名前空間が使えないので
impl
という名前空間に入れてる - 勢い余ってせっかく書いた doxygen コメントは残しておきたいが、内部実装なので API リファレンスとしての Doxygen の output からは除外したい
- そういった実装が複数連続してる存在してるのでまとめて隠したい
この場合は @cond
, @endcond
を使うとできる。
Doxygen における条件による出力の出し分け方
いくつか方法がある。以下網羅できてるかは知らない。
#ifndef
を使う方法
- 隠したいところを Doxygen 解釈時以外には絶対に定義されないマクロの
#ifndef
で括る
#ifndef DOXYGEN_SHOW_CLASS_FOO /// This class provides so FOO features. class Foo { }; #endif // !defined(DOXYGEN_SHOW_CLASS_FOO)
ENABLE_PREPROCESSING = YES
にする- 出力したいときは
PREDEFINED = DOXYGEN_SHOW_CLASS_FOO
にする
これは @cond
が実装される前に使われてた方法らしい。
- C / C++ として何か作用したいわけではないのに、 C / C++ としてのソースが汚れる
- ソースコードの読み手が慎重になる必要がある
- プリプロセッサマクロを解釈するようなツール群が期待しない動作になる or 期待動作のために追加設定が必要になる、かも
- エディタのコードハイライティング
- lint など静的解析ツール
- ...
あたりが欠点かなぁ…。
@cond
を使う方法
これは上で書いたので簡単に言うと #ifndef
とかの代わりに Doxygen コマンドを使う、と。
/// @cond DOXYGEN_SHOW_CLASS_FOO /// This class provides so FOO features. class Foo { }; /// This class provides so BAR features. class Bar { }; /// @endcond
- 出力したいときは
ENABLED_SECTIONS=DOXYGEN_SHOW_CLASS_FOO
のようにする
これは使いやすいよね。コードハイライティングがおかしくなったりもしないだろうし。
ちなみに常時出力しないのでよければ @cond
のうしろ(「セクションラベル」と呼ぶらしい)は省略できるらしい。
/// @cond /// This class provides so FOO features. class Foo { }; /// This class provides so BAR features. class Bar { }; /// @endcond
まぁ、どういう意図で @cond
で括っているかの表明にもなるから、私だったら省略しないルールにすると思う。
@if
を使う方法
これが紛らわしい。
@cond
がざっくりまとめて出力・非出力を切り替える目的に使えるのに対して、
@if
はコメントブロック内で一部の出力条件を変える目的に使う。
この「コメントブロック内〜」が重要なんだけど私は最初読み飛ばしちゃってて混乱した。
要はクラスなり関数なりの説明のまとまりの中で一部を出力する条件を記述するのに使えるってことらしい。
今回のように目的が「コードを読んだ人には見せるけど Doxygen 出力からは隠す」だと
/// This class provides so FOO features. /// /// @if CLASS_FOO_SECRET /// This is not doxygen-documented secret, Ha ha. /// @endif class Foo { };
みたいなことになる。
ENABLED_SECTIONS=CLASS_FOO_SECRET
としてやれば括ってあるところも出力される。
ただ、コメントブロックをまたげないので、
今回のように複数関数をまとめて出力する・しないを切り替えたいような用途には使えない。
これだけだと私にはあんまりありがたみが感じられなかったんだが、
/// This class provides so FOO features. /// /// @if english /// Details by English. /// @elseif japanese /// 日本語での詳細記述。 /// @endif class Foo { };
こんな感じで言語を切り替えるのに使ってるのは、
そういえば以前に見たような記憶がかすかにある…。
ENABLED_SECTIONS
と出力先を切り替えながら出力すると
複数言語分のドキュメントが生成できる、と。
Dependency Walker のいま
Windows で exe/dll の依存関係を追跡するツール Dependency Walker のいまについて。 ちょっと調べれば情報に行き当たるので、 大して書くこともないんだが…。
- Dependency Walker は Visual Studio の配布物からは独立して、単独ツールになったっぽい
- Windows 10 では Dependency Walker は安定して動かないらしい
- C# で書き直して OSS 化した Dependencies というツールがあるっぽい
- github.com
- scoop の extras bucket を入れてあれば
scoop install dependencies
で一発でインストールできる
ちなみに Dependency Walker が VS の配布物から外れたのは10年以上前らしく、 私が Windows アプリの本格的な開発から外れて長いのが分かりますw
gcovr や Doxygen の HTML を自動的に deploy する
やりたいこと
- GitHub のリポジトリ上のものを種に生成される静的 HTML サイトを自動的に deploy する
- Doxygen で生成した HTML
- gcovr で生成した Coverage report の HTML
- ...
GitHub Actions で actions/upload-artifact
を使えば
ディレクトリ単位の成果物を workflow の実行に紐付けてアップロードするのは簡単にできるのだが、
ディレクトリごとの ZIP ファイルになってしまうので
いちいちダウンロードして解凍しないとブラウザで確認できない。
これはちとめんどくさい。
どこかのサイトに自動的にアップロードされて、 必要に応じて自動的に更新されると嬉しいなー、と。
道具
- GitHub Pages
- deploy 先として使う
- あらかじめ設定しておいたブランチに push さえすれば、その内容を https://username.github.io/repository_name/ というサイトとして見られるように deploy できる仕組み
- GitHub Actions
- GitHub 謹製の CI/CD システム
- 静的 HTML サイトの構成を作って deploy するのに使う
peaceiris/actions-gh-pages
- 「あらかじめ設定しておいたブランチに push」をやってくれる GitHub Actions の action
下準備
- リポジトリの Settings で GitHub Pages の設定を
gh-pages
ブランチを deploy するように設定しておく- あとからやってもいいが、 push 時にしか deploy されないみたいなので、あとから設定した場合は設定後一度 push する必要があるっぽい
解説
- 2020/09/06 時点での GitHub Actions の workflow は https://github.com/MinoruSekine/libfixedpointnumber/blob/9085595bb0848fb1bcb7f634f1af63e8d2383ee6/.github/workflows/deploy_github_pages.yml
- 読んで分かることしかしてないけど、以下パートごとに解説
master
ブランチへpush
時にこの workflow が動くようにする、PRマージ時もこれで動く、ついでにworkflow_dispatch:
を書いておいてデバッグ等で便利なように手動トリガー可能にしておく
on: push: branches: - master workflow_dispatch:
runs-on
は https://github.com/peaceiris/actions-gh-pages にどれをサポートしているか書いてあるのでその中から選ぶ
jobs: deploy: runs-on: ubuntu-18.04
- チェックアウトする
steps: - uses: actions/checkout@v1
- 静的HTMLサイトを生成するのに必要な道具をセットアップする
- ここは Pelican でも何でもお好みのツールをセットアップすればOK
- この例では coverage report のための gcovr と Google Test Framework、Doxygen ドキュメントのために Doxygen と GraphViz をインストールしてる
- 最後の
rm -rf googletest
はmake install
するために checkout してきたソースコードとビルド生成物を消してる- これをやっておかないと
googletest/
以下の Doxygen とか作ろうとしちゃう /tmp/
とかへ checkout するなり、Doxyfile
で exclude するなりすればいいのだが、手を抜いてるだけ
- これをやっておかないと
- name: Install gcovr run: | sudo pip3 install gcovr - name: Install graphviz and doxygen run: | sudo apt update sudo apt install -y --no-install-recommends graphviz doxygen - name: Install googletest run: | git clone https://github.com/google/googletest.git cd googletest cmake -DBUILD_GMOCK=OFF -DCMAKE_CXX_STANDARD=11 . sudo make -k -j all install cd .. rm -rf googletest
- 静的HTMLサイトを生成する、この例では
make site
でout/site/
以下に静的HTMLサイトが生成されるようにしてある ( https://github.com/MinoruSekine/libfixedpointnumber/blob/9085595bb0848fb1bcb7f634f1af63e8d2383ee6/Makefile#L216 )
- name: Build site run: | make BUILD_TYPE=coverage -k -j site
- Deploy する、
publish_dir
以下が deploy される- 実際にはリポジトリの
gh-pages
というブランチに push されるだけ
- 実際にはリポジトリの
- name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./out/site
できあがったサイト
- 以上で、 PR マージなどで
master
ブランチが更新されるたびに静的 HTML サイト(Doxygen ドキュメントと coverage report)が更新される - というわけで出来上がったのが minorusekine.github.io
四捨五入の実装って地味に面倒なんじゃないか? という話
C言語だと round()
とかが整備されたのって C99 からじゃないかと思うんだが、
まぁまぁ詳しい事情は置いておくとして
二十年くらい前までって四捨五入って当たり前に個々に実装してたような記憶がある。
で、その実装もたいてい
「0.5足して切り捨てればいいじゃん」
という実装だったと記憶している。
別に間違ってないんだけど、これってその型が表現できる最大値から 0.5 以内のところって
たぶん正しく動作しないよね??
そのへんはどうしてたんだろうか…
まさに「個々に実装してた」の「個々」の事情で 最大値スレスレにならなきゃ問題にならないからいいってことなんだろうか…。
というのを
GitHub - MinoruSekine/libfixedpointnumber: Library for fixed point number by C++11
の実装を思案してて気になったのでした…。
まぁ「0.5足して切り捨てる」だけだと値が負のときの動作が JIS Z8401 相当になることは諦めてるわけで、 その時点で「個々」の事情で起き得ないところは動作の正しさを諦めてるってことか…。
「本籍地はむやみに動かさないほうが良い」という私見
いきなり免責
- 私、法律の専門家でもなんでもないので、間違っていてもなんの責任も当然とれません
- 参考にするのはいいけど自己責任でお願いします
私見的結論
- 本籍地を動かすのは必要最低限にしとくのが良い
戸籍にまつわるよもやま
戸籍の請求
戸籍が変わるイベント
- 出生
- 結婚
- 離婚
- 死亡
- 法律改正
- 転籍
- 自己都合で本籍地を変更する場合
- …
戸籍が必要になるイベント
- いろいろあるけど、大抵のケースで必要になるのは最新の戸籍だけ
- 最新以外の戸籍が必要になるほぼ唯一のケースが相続
- 相続では被相続人(つまり死んだ人)の「出生から死亡までの連続した戸籍すべて」が必要になる
- 金融機関やら、法務局(不動産相続があって登記変更する場合)に見せる必要がある
- 「見せる」と書いたのは「提出してもたいていコピーをとって返してもらえるから
- だからといって、コピーを持っていくのは NG
- 金融機関やら、法務局(不動産相続があって登記変更する場合)に見せる必要がある
- 相続では被相続人(つまり死んだ人)の「出生から死亡までの連続した戸籍すべて」が必要になる
「出生から死亡までの連続した戸籍すべて」
「出生から死亡までの連続した戸籍すべて」とは
死亡時の戸籍はまぁわかるとして、 出生時の戸籍ってのは生年月日がわかればいいという話ではなく 出生を届け出てそれにより登録された最初の戸籍が必要です。 途中の戸籍になんとなく生年月日とか書いてあって思わせぶりだけどそれだけじゃだめです。 出生から死亡まで途中の戸籍関係のイベント結婚、離婚、転籍、…など全ての段階の戸籍が必要です、 これが「出生から死亡までの連続した戸籍すべて」。
で、
- 出生時は通常両親の戸籍に入っているはず
- 結婚時にそこから抜けてるはず
- 死亡時の戸籍ってのは要は最新の戸籍なので最新の本籍地で取得できるはず
↑これだけで済めば簡単な話ですが…
- 法律が改正されると戸籍が新しくなる(改製される)
- 転籍してる場合は転籍元も辿らないといけない
- 途中結婚してる場合は結婚前のものも必要
- …
と。
「出生から死亡までの連続した戸籍すべて」の取得方法
「とてもじゃないけど移動が無理」 というケースを除いて、 郵送請求ではなく役所に行った方が話が早いです。
- 「出生から死亡までの連続した戸籍すべて」ですが、 実際には「最新の死亡時の戸籍から古い方へ遡って出生まで辿っていく」ことになります
- 結婚・離婚・転籍などがないとしても「法律改正」による「戸籍の改製」が途中で発生していることがあり、 その場合、1つの役所に対して複数の戸籍を請求する必要があります
- しかし、個人情報保護の観点から、ある役所に被相続人の戸籍がいくつあるかは、電話等の問い合わせでは教えてもらえません
- いまほど個人情報保護がさけばれていなかったころはできたらしい
- なので、郵送請求の場合は「一通取り寄せて、次に遡ってまた請求する」というのを延々繰り返す必要があり、
そのたびに封筒やら切手やら定額小為替やらを用意する必要があります
- まとめて請求できるところもありますが、その場合も何通で手数料がいくらになるか事前にはわからないので、定額小為替を多めに送って戻してもらうとか面倒なことになります
- 一方で役所に訪れて「相続手続きのため○○の載っている戸籍をすべて」と伝えれば全部まとめて出してくれて精算も簡単
- 請求書の請求目的欄に「相続」という項目がある自治体もありますが、なくても窓口で「相続で使うのでここで取れるものをすべて」と伝えればOK
というわけで具体的な手順としては、
- 死亡時の本籍地市区町村役所に行き「相続手続きのため○○の載っている戸籍のうちここで取得できるすべて」を請求する
- 取得した一番古い戸籍を見てその前がどこかを調べる。 その人の欄にその前はどこから来ているかが書かれているはず。 もし自信がなければ or 見ても分からなければ、 役所側も慣れてるので貰った時に「出生まで遡るんですが、次はどこに行けばいいですか?」と聞けばOK
- 出生を届け出たことにより戸籍に入ったことが書かれているところまで遡れたら終了
- 次の市区町村役所に行き「相続手続きのため○○の載っている戸籍のうちここで取得できるすべて」を請求する
- 2 に戻る
なので、本籍地が変わっていればいるほど、2〜5のループを繰り返さないといけなくなります。
まぁ、被相続人(亡くなった方)の本籍地の変遷が、 手続者が知ってる範囲なら予定も組めるんですが、 「取ってみないと分からない」だと予定が組めないですし、 いざ行って取ってみたら「え、こんなところに本籍地置いてたことあるなんて聞いてない…」ってことがないとも言えないので、 そこらへんは個々の事情を鑑みて郵送請求も検討すればいいと思います。
本籍地は…
- 結婚しても出生時の本籍地から動かさないでおけば、自分が死んだときに相続人がラクをできる
- まぁ、結婚の場合、夫婦ともに同じ本籍所在自治体というケース以外では、夫婦のどちらかは動かざるをえないわけですが
- 「最新の戸籍の請求が簡単になるから…」と引っ越しのたびとかに本籍地を変えないほうがいい
- 最新の戸籍なんて郵便一発で請求できる
「自分が死んじまったあとの面倒なんて知らねーよ」 というのも一つの考え方かとは思いますが、 遺族ってのはその時期は気持ち的にも手続き等々的にも落ち着かない時期なので、 少しでもラクに済むならその方がいいはず。
その他、雑多な話
- 相続関連で相続開始(≒死亡)からの期限があるのは下記
- 相続時の戸籍は一揃えあればOK
- 金融機関の数だけ必要とかいうことはない (向こうでコピー取って返してくれるはず (コピーを持参するのは NG))
- 複数の相続人が同時に複数の金融機関に手続きに行くとかなら話は別ですが…
- 司法書士などは不動産相続による登記変更を伴う場合、職権による戸籍請求ができるらしい
- 登記変更がない場合はいちいち委任状が必要になる?
- 役所は 8:30 からやっているところが多い
- 9:00 からだと思ってる人が多いので、9:00前に行くと比較的空いてる事が多い
二要素認証のコードが覚えやすいような気がする件
きっかけ
最近テレワーク続きなこともあって二要素認証を使う機会が多いんだが、 あの数字の羅列が結構覚えやすい数字のことが多い気がしてちょっと考えてみた。
前提
- 数値は完全な乱数だと仮定する
- 二要素認証のアルゴリズムで偏ってることとかは考慮しない
- 「覚えやすい = 同じ数字が2回以上現れる」だと仮定する
- 4〜6桁くらいのコードで同じ数字が複数の桁に現れると、リズムが良くなって覚えやすい気がする
- 他にも「345 nnn」みたいな3桁以上連続の数え上げが現れるとかも覚えやすいけど、ここではちょっと外す
- 6桁のコードで考えてみる
- 自分がよく使うから
確率
6桁のコードの中に1回現れた数字が全く現れない確率は
「6桁のコードの中に同じ数字が2回以上現れる」のは↑の確率の余事象だから
なるほど、8割以上の確率で同じ数値が現れるんだとすると、 「覚えやすい数値ばっかりだな」と感じるのも無理ないってことか。
余談
高校数学の成績とかめっちゃ悪かった人なので、 間違いとかはこっそり指摘してあげてください(爆沈)