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 を使うとできる。

github.com

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 が 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 する必要があるっぽい

解説

on:
  push:
    branches:
      - master
  workflow_dispatch:
jobs:
  deploy:
    runs-on: ubuntu-18.04
  • チェックアウトする
    steps:
    - uses: actions/checkout@v1
  • 静的HTMLサイトを生成するのに必要な道具をセットアップする
    • ここは Pelican でも何でもお好みのツールをセットアップすればOK
    • この例では coverage report のための gcovr と Google Test Framework、Doxygen ドキュメントのために DoxygenGraphViz をインストールしてる
    • 最後の rm -rf googletestmake 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
    - 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

「出生から死亡までの連続した戸籍すべて」

「出生から死亡までの連続した戸籍すべて」とは

死亡時の戸籍はまぁわかるとして、 出生時の戸籍ってのは生年月日がわかればいいという話ではなく 出生を届け出てそれにより登録された最初の戸籍が必要です。 途中の戸籍になんとなく生年月日とか書いてあって思わせぶりだけどそれだけじゃだめです。 出生から死亡まで途中の戸籍関係のイベント結婚、離婚、転籍、…など全ての段階の戸籍が必要です、 これが「出生から死亡までの連続した戸籍すべて」。

で、

  • 出生時は通常両親の戸籍に入っているはず
  • 結婚時にそこから抜けてるはず
  • 死亡時の戸籍ってのは要は最新の戸籍なので最新の本籍地で取得できるはず

↑これだけで済めば簡単な話ですが…

  • 法律が改正されると戸籍が新しくなる(改製される)
    • 相続時は改製前の戸籍(改製原戸籍)も必要になる
    • 直近では昭和30年代と平成10年代に改製があった模様 (法改正から各自治体が戸籍を改製するまでにはバラツキがある)
  • 転籍してる場合は転籍元も辿らないといけない
  • 途中結婚してる場合は結婚前のものも必要

と。

「出生から死亡までの連続した戸籍すべて」の取得方法

「とてもじゃないけど移動が無理」 というケースを除いて、 郵送請求ではなく役所に行った方が話が早いです。

  • 「出生から死亡までの連続した戸籍すべて」ですが、 実際には「最新の死亡時の戸籍から古い方へ遡って出生まで辿っていく」ことになります
  • 結婚・離婚・転籍などがないとしても「法律改正」による「戸籍の改製」が途中で発生していることがあり、 その場合、1つの役所に対して複数の戸籍を請求する必要があります
  • しかし、個人情報保護の観点から、ある役所に被相続人の戸籍がいくつあるかは、電話等の問い合わせでは教えてもらえません
    • いまほど個人情報保護がさけばれていなかったころはできたらしい
  • なので、郵送請求の場合は「一通取り寄せて、次に遡ってまた請求する」というのを延々繰り返す必要があり、 そのたびに封筒やら切手やら定額小為替やらを用意する必要があります
    • まとめて請求できるところもありますが、その場合も何通で手数料がいくらになるか事前にはわからないので、定額小為替を多めに送って戻してもらうとか面倒なことになります
  • 一方で役所に訪れて「相続手続きのため○○の載っている戸籍をすべて」と伝えれば全部まとめて出してくれて精算も簡単
    • 請求書の請求目的欄に「相続」という項目がある自治体もありますが、なくても窓口で「相続で使うのでここで取れるものをすべて」と伝えればOK

というわけで具体的な手順としては、

  1. 死亡時の本籍地市区町村役所に行き「相続手続きのため○○の載っている戸籍のうちここで取得できるすべて」を請求する
  2. 取得した一番古い戸籍を見てその前がどこかを調べる。 その人の欄にその前はどこから来ているかが書かれているはず。 もし自信がなければ or 見ても分からなければ、 役所側も慣れてるので貰った時に「出生まで遡るんですが、次はどこに行けばいいですか?」と聞けばOK
  3. 出生を届け出たことにより戸籍に入ったことが書かれているところまで遡れたら終了
  4. 次の市区町村役所に行き「相続手続きのため○○の載っている戸籍のうちここで取得できるすべて」を請求する
  5. 2 に戻る

なので、本籍地が変わっていればいるほど、2〜5のループを繰り返さないといけなくなります。

まぁ、被相続人(亡くなった方)の本籍地の変遷が、 手続者が知ってる範囲なら予定も組めるんですが、 「取ってみないと分からない」だと予定が組めないですし、 いざ行って取ってみたら「え、こんなところに本籍地置いてたことあるなんて聞いてない…」ってことがないとも言えないので、 そこらへんは個々の事情を鑑みて郵送請求も検討すればいいと思います。

本籍地は…

  • 結婚しても出生時の本籍地から動かさないでおけば、自分が死んだときに相続人がラクをできる
    • まぁ、結婚の場合、夫婦ともに同じ本籍所在自治体というケース以外では、夫婦のどちらかは動かざるをえないわけですが
  • 「最新の戸籍の請求が簡単になるから…」と引っ越しのたびとかに本籍地を変えないほうがいい
    • 最新の戸籍なんて郵便一発で請求できる

「自分が死んじまったあとの面倒なんて知らねーよ」 というのも一つの考え方かとは思いますが、 遺族ってのはその時期は気持ち的にも手続き等々的にも落ち着かない時期なので、 少しでもラクに済むならその方がいいはず。

その他、雑多な話

  • 相続関連で相続開始(≒死亡)からの期限があるのは下記
    • 3ヶ月
    • 4ヶ月
      • 被相続人の確定申告
        • 被相続人が死亡時に未申告の収入があった場合 (給与所得やら、不動産収入など)
    • 10ヶ月
    • 「借金ない」「生前、確定申告が必要な所得とかなかった」「相続税控除されるくらいの遺産額」ということであれば、手続きを慌てる必要は実はない
    • 逆に「借金やローンが残ってる」「まだ働いてた (給与収入、事業収入があった)」「家賃収入などがあった」「遺産額が控除限度額(3000万円+(600万×相続人人数))を超えるかもしれない」ってときは四十九日より前に動き始めた方がよさげ
  • 相続時の戸籍は一揃えあればOK
    • 金融機関の数だけ必要とかいうことはない (向こうでコピー取って返してくれるはず (コピーを持参するのは NG))
    • 複数の相続人が同時に複数の金融機関に手続きに行くとかなら話は別ですが…
  • 司法書士などは不動産相続による登記変更を伴う場合、職権による戸籍請求ができるらしい
    • 登記変更がない場合はいちいち委任状が必要になる?
  • 役所は 8:30 からやっているところが多い
    • 9:00 からだと思ってる人が多いので、9:00前に行くと比較的空いてる事が多い

二要素認証のコードが覚えやすいような気がする件

きっかけ

最近テレワーク続きなこともあって二要素認証を使う機会が多いんだが、 あの数字の羅列が結構覚えやすい数字のことが多い気がしてちょっと考えてみた。

前提

  • 数値は完全な乱数だと仮定する
  • 「覚えやすい = 同じ数字が2回以上現れる」だと仮定する
    • 4〜6桁くらいのコードで同じ数字が複数の桁に現れると、リズムが良くなって覚えやすい気がする
    • 他にも「345 nnn」みたいな3桁以上連続の数え上げが現れるとかも覚えやすいけど、ここではちょっと外す
  • 6桁のコードで考えてみる
    • 自分がよく使うから

確率

6桁のコードの中に1回現れた数字が全く現れない確率は

 \dfrac{10}{10} \times \dfrac{9}{10} \times \dfrac{8}{10} \times \dfrac{7}{10} \times \dfrac{6}{10} \times \dfrac{5}{10} = \dfrac{151200}{1000000} = 15.12\%

「6桁のコードの中に同じ数字が2回以上現れる」のは↑の確率の余事象だから

 100\% - 15.12\% = 84.88\%

なるほど、8割以上の確率で同じ数値が現れるんだとすると、 「覚えやすい数値ばっかりだな」と感じるのも無理ないってことか。

余談

高校数学の成績とかめっちゃ悪かった人なので、 間違いとかはこっそり指摘してあげてください(爆沈)