コグノスケ

ジージェネレーションフロンティア

SDガンダム ジージェネレーションフロンティアの話。今までのFR設計イベントをメモしておきます。

第一弾

FRアカツキ（シラヌイ）/ 誘導機動ビーム砲塔システム
-- URゲーマルク（覚醒）/マザー＆チルド・ファンネル
-- URシナンジュ /バズーカ
-- URドム/ジェットストリームアタック
-- URデスティニーガンダム（最大稼働）/パルマフィオキーナ

第二弾

FR νガンダム/連続格闘
-- URクロスボーン・ガンダムX1改・改/ヒートダガー＆スクリュー・ウェッブ
-- URサザビー/ファンネル（Ver.2）
-- URジ・O（覚醒）/ビーム・ソード/四刀流 
-- URアルトロンガンダム/ドラゴンハング

第三弾

FRガンダムアヴァランチエクシア/GNソード/ソードモード
-- URストライクルージュ（IWSP)/一斉発射
-- URノイエ・ジール/有線クロー・アーム
-- UR ∀ガンダム/核弾頭
-- URケルディムガンダムGNHW（トランザム）/GNライフルビット

第四弾

FRガンダムデルタカイ/プロト・フィン・ファンネル
-- URグフ・カスタム/ヒート・ワイヤー
-- URガンダムDX（Gファルコン）/ツインサテライトキャノン
-- URデストロイガンダム/ツォーンMk2＆スーパースキュラ
-- URデルタガンダム/ビーム・サーベル/二刀流

第五弾

FRガンダムAGE-2ノーマル/MS/ハイパードッズライフル
-- URザクII改/ヒート・ホーク＆ダミーバルーン爆弾
-- URトールギスIII/メガキャノン/最大出力
-- URガンダムAGE-1ノーマル/ドッズライフル
-- URラフレシア/親バグ＆子バグ

これらのイベントは既に終わっていますが、しばらく経つと再実施されるようです。作り逃したFRキャラクターが居ても、後でまた作れるかもしれませんので、材料となるURキャラクターを、間違って処分してしまわないようにメモしておきます。

しばらくやってみた感想

楽しい点は、小学生の時にハマっていたSDガンダムのカードダス集めの気分が味わえることです。特にFRキャラクター（カードダスのキラキラカードに相当）が当たった時は、出たこれ！って気分で嬉しいですね。

ゲームとしてはつまらないです。もし同じ面を100回以上やる「イベント」を、毎週連発するだけのゲームが面白い！好き！と思う人が居ればオススメしますが…。私は立ちながらか、歩きながらプレイしないと確実に寝ます。

嫌いな点はUIです。いちいちボタンを押さないと進まないのに、ボタンの配置に統一感がありません。片手で遊びづらいです。

ちぐはぐなVisual Studioのエディタとコンパイラ

Visual Studio 2015のコンパイラは、未だにBOMを付けないとUTF-8を認識しません。なぜかShift-JISもコンパイルエラーになります（2013ではなりません）。

MSDNライブラリ（サイトへのリンク）でも「コンパイラおよびリンカーでのUnicodeのサポート（... 中略 ...）BOM付きのUTF-8」などと言いきる始末です。イマイチすぎる…。

Visual StudioのIDEはGitに対応したり、エディタがマルチプラットフォームになったり、コミュニティベース開発に力を入れたり、時代の流れに沿って進化していますが、

コンパイラはダメダメ感が漂います。C++0xの対応はllvm, gccの後塵を拝しワーストです。もはやMicrosoftですら単独でC/C++ コンパイラを開発するのは不可能なのかなあ…？

メモ: 技術系の話はFacebookから転記しておくことにした。

MPEG4-AVC / H.264の2つのフォーマット

今や映像の圧縮方式として当たり前となりつつあるMPEG4-AVC（※）には、2つの形式があります。

• ISO/IEC 14496-1: Annex B - Byte Stream Format
• ISO/IEC 14496-15: NAL File Format

Byte Stream Formatは、俗に言うスタートコード形式（0x000001を目印としてNALUが始まる）で、コンテナを使わない場合、リアルタイム配信（RTSP）、放送系（MPEG2-TSをコンテナ）で良く使われているようです。

利点としては「欠け」に強いことです。何か問題が発生してデータが欠けてしまっても、スタートコードさえ見つかれば、その地点から処理を再開できます。その分、毎度スタートコードを探す処理が必要がある、先頭が欠けても再生できるように重複して情報を入れる必要があるなど、やや非効率的です。

NAL File Formatは、いわゆるサイズ指定形式（数バイトのサイズの後にNALUが始まる）です。ファイル形式（MP4など）に良く使われているようです。

利点としては「効率的」であることです。余分な情報はコンテナに持たせて、ビットストリームからは取り去りますのでサイズが小さくできます。NALUのサイズも予めわかりますから不要なNALUをスキップする際の負荷も低いです。その分、1バイトでも欠けてしまうと、デコードできなくなってしまう弱さもあります。

実はこの2つを変換するのは面倒で、サイズ指定をスタートコードに置き換えるだけではダメです。そんな単純な変換では、上記のような特徴が出せません…。

（※）AVCはAdvanced Video Codecの略です。この規格はISO/IECとITU-Tの共同規格なので、MPEG4-AVCではなくITU-Tの規格名であるH.264と呼ぶ人も多いですね。

変換ツールの使い方

でも、自分でそのような処理を書く必要はありません。世の中にはナイスガイ達が居て、変換が可能なツールを公開してくれています。ありがたいことです。

まずはffmpegを使う場合ですが、コーデックは変更しないのでcopyを指定して、普段の利用ではあまり見かけないbsfオプションを使って変換します。

なぜmp4toannexbという名前かと言うと、MPEG4-AVCの規格であるISO/IEC 14496-1 Annex BにByte Stream Formatの規格が示されているからではないか？と思われます。

avconv -i /path/to/hogehoge.mp4 -vcodec copy -bsf:v h264_mp4toannexb hogehoge.h264

Gstreamerを使う場合はh264parseエレメントを使います。ffmpegと比べるとかなり長く感じますが、大したことはしていないです。

例では、改行を入れていますが、実際には改行を入れずに1行で書いてください。もしGstreamer 1.0系を使う場合は、video_00のところをvideo_0と書く必要があったはずです。たぶん。

 gst-launch filesrc location=/path/to/hogehoge.mp4 ! 
 qtdemux name=dem dem.video_00 ! 
 h264parse ! 
 video/x-h264,stream-format=byte-stream,alignment=au ! 
 filesink location=/path/to/es/hogehoge.h264

普通に動画を楽しんでいる人には、こんな変換は全く縁がありませんが、私にとっては便利なんです。こんなツール達がオープンソースで公開されているというのは、ありがたいことですなー…。

Appleとファウンドリ

「うわ... 私のiPhone 6sバッテリーもたない？」CPU違いの6sでバッテリーベンチをしてみました を読んで。

元々の原価が低いのか、FinFETで首位に立つべく値引きしたか、事情は知りませんが、廉価版のiPhoneほどSamsung製の搭載比率が大きいところを見ると、TSMCよりSamsungの方がAppleの利ザヤがデカいのでしょう。おそらく。

そういえばQualcommはSnapdragon 810（TSMC 20nm）で発熱問題に泣いて、次のSnapdragon 820はSamsung製らしいですね。16nm世代を採用したら次も泣かされそう…。

メモ: 技術系の話はFacebookから転記しておくことにした。

Linuxデバイスドライバを組み込んだときの初期化順序

目次: Linux

Linux用のデバイスドライバを書くときはmodule_init(関数名) と書いて、初期化関数を指定します。

ドライバをカーネルモジュール（*.ko）としてビルドしたときは、insmodした時に初期化関数が実行されます。これは想像に難くないですし、初期化関数にprintkでも入れておけば簡単に確認できます。

では…、ドライバをLinuxカーネルに組み込んだ時は、一体いつ初期化処理が実行されるのでしょうか？Linuxには他のドライバも含まれていますが、実行される順序に決まりはあるでしょうか？

わたくし恥ずかしながら、この辺の仕組みを全く理解していなかったので、コードを調べてみました。既に同じような事を調べている人がいる気がしてなりませんが…まあ良いや。

Linuxの初期化関数

Linuxの初期化は、linux/init/main.cのstart_kernel() から始まります。start_kernel() は山のように初期化を実行していますが、我らがmodule_init() の実行に関係しているのは下記の部分です。

start_kernel()
  rest_init()
    kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);

ここでカーネルスレッドが作成され、スレッドのエントリ関数はkernel_init() です。で、続けて追いかけます。

kernel_init()
  kernel_init_freeable()
    do_basic_setup()
      do_initcalls()
        do_initcall_level()
          do_one_initcall()
            initcall_levels[level][n]()

このような順で呼ばれます。このinitcall_levelsが今回の話のキモとなります。initcall_levelsは下記のように定義されています。

typedef int (*initcall_t)(void);

extern initcall_t __initcall_start[];
extern initcall_t __initcall0_start[];
extern initcall_t __initcall1_start[];
extern initcall_t __initcall2_start[];
extern initcall_t __initcall3_start[];
extern initcall_t __initcall4_start[];
extern initcall_t __initcall5_start[];
extern initcall_t __initcall6_start[];
extern initcall_t __initcall7_start[];
extern initcall_t __initcall_end[];

static initcall_t *initcall_levels[] __initdata = {
        __initcall0_start,
        __initcall1_start,
        __initcall2_start,
        __initcall3_start,
        __initcall4_start,
        __initcall5_start,
        __initcall6_start,
        __initcall7_start,
        __initcall_end,
};

コードを見る限り、二重配列 __initcall_levelsは __initcalln_startという配列を要素として持っていること、__initcall0_start[0], __initcall0_start[1], __initcall0_start[2], ... の順に関数ポインタが先に呼び出され、その後も同様に __initcall1_start, __initcall2_start, ... と続いて __initcall7_startに入っている関数ポインタは後に呼び出されることがわかります。

しかし肝心の __initcall0_startに何の関数ポインタが入るのか？はわかりません。それもそのはず、実はCのコード上に、これら __initcallx_start配列の定義はありません。別の方法で定義されているのです。

この __initcall0_start〜 __initcall7_start配列は、あるマクロで宣言された初期化関数のポインタを全て持つ配列となります。対応関係は下記の通りです。

• __initcall0_start: pure_initcall()
• __initcall1_start: core_initcall()
• __initcall2_start: postcore_initcall()
• __initcall3_start: arch_initcall()
• __initcall4_start: subsys_initcall()
• __initcall5_start: fs_initcall()
• __initcall6_start: device_initcall()
• __initcall7_start: late_initcall()

なぜそうなるか？は後述しますので、とりあえずこんな関係があることだけ頭の隅に置いてください。

おまじないmodule_init() の正体

カーネルモジュールを作るとき、初期化関数を指定するためのおまじないとしてmodule_init(funcname) と書きますが、これは実はマクロでlinux/include/linux/module.hにて、下記のように定義されています。

/**
 * module_init() - driver initialization entry point
 * @x: function to be run at kernel boot time or module insertion
 *
 * module_init() will either be called during do_initcalls() (if
 * builtin) or at module insertion time (if a module).  There can only
 * be one per module.
 */
#define module_init(x)  __initcall(x);

#define __initcall(fn) device_initcall(fn)

#define device_initcall(fn)             __define_initcall(fn, 6)

マクロの定義はmodule_init = __initcall = device_initcallとなっていますので、module_init(funcname) はdevice_initcall(funcname) と書くのと同じです。

最後にmodule_init(funcname) は __define_init(funcname, 6) と定義されています。これもマクロでlinux/include/linux/init.hに下記のように定義されています。

#define __define_initcall(fn, id) \r        static initcall_t __initcall_##fn##id __used \
        __attribute__((__section__(".initcall" #id ".init"))) = fn

何だか小難しいですが、簡単に言うとmodule_init(funcname) つまり __define_initcall(funcname, 6) と書いたら、初期化関数funcnameのポインタを値に持つ __initcall_funcname6という名前の変数を宣言し、セクション .initcall6.initに置け、という意味になります。

その変な名前の変数がどこに置かれるのか？は、リンカスクリプトlinux/arch/arm/kernel/vmlinux.ldsに書いてあります。全部は載せられませんので .initcall6.initセクションに言及しているところを見てみます。

 .init.data : {
    *(.init.data) *(.meminit.data) *(.init.rodata) *(.meminit.rodata) . = ALIGN(8);
    __clk_of_table = .;
    *(__clk_of_table) *(__clk_of_table_end) . = ALIGN(32);
    __dtb_start = .;
    *(.dtb.init.rodata) __dtb_end = .;
    . = ALIGN(16);
    __setup_start = .;
    *(.init.setup) __setup_end = .;
    __initcall_start = .;
    *(.initcallearly.init) __initcall0_start = .;
    *(.initcall0.init) *(.initcall0s.init) __initcall1_start = .;
    *(.initcall1.init) *(.initcall1s.init) __initcall2_start = .;
    *(.initcall2.init) *(.initcall2s.init) __initcall3_start = .;
    *(.initcall3.init) *(.initcall3s.init) __initcall4_start = .;
    *(.initcall4.init) *(.initcall4s.init) __initcall5_start = .;
    *(.initcall5.init) *(.initcall5s.init) __initcallrootfs_start = .;
    *(.initcallrootfs.init) *(.initcallrootfss.init) __initcall6_start = .;
    *(.initcall6.init) *(.initcall6s.init) __initcall7_start = .; ★★これ★★
    *(.initcall7.init) *(.initcall7s.init) __initcall_end = .;
    __con_initcall_start = .;
    *(.con_initcall.init) __con_initcall_end = .;
    __security_initcall_start = .;
    security_initcall.init) __security_initcall_end = .;
    ...

※本来は改行が入っていませんが、見やすいように適宜改行を入れています。

私はリンカスクリプトに明るくないので、間違っていたらごめんなさいですが、基本的には書いた順でシンボル（変数や関数など）をオブジェクトファイル内に並べてくれる、という理解でこの辺りは大丈夫なはずです。

先ほどの __define_initcall() マクロの定義から __initcall_funcname6変数は、コンパイラが .initcall6.initというセクションに入れて、オブジェクトファイルを生成します。わかりにくいと思うので、例で説明します。

例えば、リンカが今までシンボルを並べてきた結果、現在のアドレスが0x10000になっていたとします。あと .initcall6.initセクションには __initcall_funcname6と __initcall_func2name6の2つのシンボルが含まれているとします。

リンカはまず「__initcall6_start = .;」を見て、現在のアドレス（ドットは現在のアドレスを表す）に0x10000: __initcall6_startを定義します。現在のアドレスは変わりません。

次に「*(.initcall6.init)」を見て、全オブジェクトファイルの .initcall6.initのシンボルを順番に並べ、現在のアドレスを進めます。つまり0x10000: __initcall_funcname6, 0x10004: __initcall_func2name6が並び、現在のアドレスは0x10008になります。「*(.initcall6s.init)」も同様ですが、何もシンボルが入っていないのでスルーします。

最後に「__initcall7_start = .;」を見て、0x10008: __initcall7_startを定義します。

すなわち下記のようなアドレス、シンボルの関係になります。

- Linuxカーネル
  - セクションA
  - セクションB
  - セクション .init.data
      - ...
      - 0x10000: __initcall6_start
      - .initcall6.init内の全シンボル
        （内訳）
        - 0x10000: __initcall_funcname6  = funcname() のポインタ
        - 0x10004: __initcall_func2name6 = func2name() のポインタ
      - 0x10008: .initcall6s.init内の全シンボル
      - __initcall7_start
      - .initcall7.init内の全シンボル
      - ...
  - セクションD
  ...

ここで、序盤の謎であった __initcall6_startの謎が解けます。思い出してほしいのですが、変数 __initcall_xxxx6はdevice_initcall(xxxx, 6) で指定した関数xxxxのポインタを値として持っていました。

リンカスクリプトによって、変数 __initcall_xxxx6の一群を __initcall_funcname6から「連続したアドレスに配置する」ので、C言語から見たときには、__initcall6_startはあたかも関数ポインタの値を持った配列に見えるわけです。

static initcall_t __initcall_funcname6 = funcname;
static initcall_t __initcall_func2name6 = func2name;

initcall_t __initcall6_start[] = {
        __initcall_funcname6, 
        __initcall_func2name6, 
        ..., 
};

ただし、C言語ではこのような書き方はできないし、仮に書けたとしても、

&__initcall6_start[0] == &__initcall_funcname6
&__initcall6_start[1] == &__initcall_func2name6

が成り立たないので、厳密に同じことはできません。

この仕組みはC言語だけでは記述するのは恐らく不可能で、リンカとの連携の賜物と言えるでしょう。

ビルドしたバイナリを見る

論より証拠でLinuxカーネルをビルドして、生成されたvmlinuxをreadelfで調べましょう。

実験に使うカーネルは3.14.44でARM Versatile PBボード向けコンフィグでビルドしたものです。拙作のARM9エミュレータememu（emuemuについてはこちら）の動作確認用に実際に動作させていたバイナリです。

まずは -Sオプションでセクションの一覧を見ます。

$ arm-linux-gnueabihf-readelf -S vmlinux

セクションヘッダ:
  [番] 名前              タイプ          アドレスOff    サイズES Flg Lk Inf Al
  ...
  [21] .init.pv_table    PROGBITS        c039b818 3a3818 0005cc 00   A  0   0  1
  [22] .init.data        PROGBITS        c039bde8 3a3de8 003f6c 00  WA  0   0  8
  [23] .data             PROGBITS        c03a0000 3a8000 027380 00  WA  0   0 32
  ...

アドレスc039bde8からc039ffffまで、サイズ3f6c分のセクション .init.dataが居ることがわかります。vmlinuxをバイナリエディタなどで見る場合はOffの位置、つまり3a3de8を見ると .init.dataのバイナリデータが見られます。

Linuxはビルドしたときに全シンボルのアドレスと、シンボル名の対応表を作成してくれます。アドレスとシンボル名の対応はSystem.mapというファイルに出力されます。

$ grep initcall6 System.map
c039fb08 T __initcall6_start

$ grep initcall7 System.map
c039fc94 T __initcall7_start
c039fcb4 t __initcall_deferred_probe_initcall7

System.mapを見てもわかるように、__initcallx_startの軍団は .init.dataセクションの範囲内に全員収まっていることがわかります。

初期化順序

残りの疑問であるinitcall6内の呼び出し順はどうなるか？については、コンパイルされた順番になるようです。

System.mapの __initcall6_start付近を見ると、

c039fb08 T __initcall6_start
★★★arch/arm/ 以下
c039fb08 t __initcall_fpe_init6

★★★kernel/ 以下
c039fb0c t __initcall_proc_execdomains_init6
c039fb10 t __initcall_ioresources_init6
...
c039fb50 t __initcall_pid_namespaces_init6
c039fb54 t __initcall_utsname_sysctl_init6

★★★mm/ 以下
c039fb58 t __initcall_init_per_zone_wmark_min6
c039fb5c t __initcall_kswapd_init6
...
c039fb70 t __initcall_slab_proc_init6
c039fb74 t __initcall_cpucache_init6

★★★fs/ 以下
c039fb78 t __initcall_fcntl_init6
c039fb7c t __initcall_proc_filesystems_init6
...
c039fbbc t __initcall_init_jffs2_fs6
c039fbc0 t __initcall_init_romfs_fs6

★★★ipc/ 以下
c039fbc4 t __initcall_ipc_init6
c039fbc8 t __initcall_ipc_sysctl_init6

★★★crypto/ 以下
c039fbcc t __initcall_crypto_algapi_init6
c039fbd0 t __initcall_aes_init6

★★★block/ 以下
c039fbd4 t __initcall_proc_genhd_init6
c039fbd8 t __initcall_bsg_init6
c039fbdc t __initcall_noop_init6
c039fbe0 t __initcall_deadline_init6
c039fbe4 t __initcall_cfq_init6

★★★drivers/ 以下
c039fbe8 t __initcall_pl061_gpio_init6
c039fbec t __initcall_fb_console_init6
...
c039fc68 t __initcall_ms_driver_init6  -> module_hid_driverが生成した関数
c039fc6c t __initcall_mr_driver_init6  -> module_hid_driverが生成した関数

★★★net/ 以下
c039fc70 t __initcall_sock_diag_init6
c039fc74 t __initcall_flow_cache_init_global6
...
c039fc90 t __initcall_packet_init6
c039fc94 T __initcall7_start

このようになっています。linux/Makefileを見てみると、

ifeq ($(KBUILD_EXTMOD),)
core-y          += kernel/ mm/ fs/ ipc/ security/ crypto/ block/

このように同じ順で並んでいることがわかります。ざっと見た感じだと、サブディレクトリ内のモジュール達（fs, driversの下）も同様に、Makefileに書いた順で初期化されるようです。

要するに、モジュールBがモジュールAに依存している場合、MakefileにはA → Bの順で書かないとなりません。逆に書いてしまうと、モジュールBが先に初期化され、未初期化のモジュールAを呼び出し、カーネルがクラッシュする悲劇が起きます。

ホームディレクトリの .bashrcはどこから来る？

ユーザをuseraddで追加するときに -mオプションを付けると、ユーザ追加と同時に、ホームディレクトリが自動的に生成されます。

生成されたホームディレクトリを見ると、特に何もしていないのに .bashrcや .profileなどが置かれています。これらのファイルはどこから来たのでしょう？

# useradd testuser -m

# cd /home/testuser/

# ls -la
total 12
drwxr-xr-x 2 testuser testuser  128 Oct 11 16:50 .
drwxr-xr-x 8 root     root      184 Oct 11 16:50 ..
-rw-r--r-- 1 testuser testuser  220 Dec 12  2006 .bash_logout
-rw-r--r-- 1 testuser testuser 3515 Nov 13  2014 .bashrc
-rw-r--r-- 1 testuser testuser  675 May 13  2008 .profile

答えだけ言ってしまうと、Debianの場合 /etc/skelというディレクトリが、ホームディレクトリのひな型となります。

# ls -la /etc/skel
total 21
drwxr-xr-x   2 root root  128 May  1 05:06 .
drwxr-xr-x 173 root root 9128 Oct 11 16:50 ..
-rw-r--r--   1 root root  220 Dec 12  2006 .bash_logout
-rw-r--r--   1 root root 3515 Nov 13  2014 .bashrc
-rw-r--r--   1 root root  675 May 13  2008 .profile

Debian以外のディストリビューションでも、ひな型となるディレクトリがあるはずなので、探してみると面白いかもしれません。

ニューマシン

かれこれ5年以上が経過したCore2 Quadマシンにお別れを告げて、新しいPCを組みました。前回同様、部品だけ買って半年くらい放置してしまいましたが、今日やっと組み立て終わって、無事動いております…。

CPU選び

前回はIntel CPUでしたので、次はAMDにしようと思ったのですが、AMDはBulldozer以降CPUの性能がどうもパッとしないようで、AMD APUにすべきかAMD FXにすべきかで少し迷いました。

普段の使い方を思えばCPUの動作速度にはさほど困っていないので、とりあえずTDPが低め（50Wクラス）で一番速いA10-7800を選びました。

AMDのCPUは元々安目の価格ですし、APUを選べばグラフィックカード代まで浮きますので、非常にありがたいです。

そういえばA10-7800を買った直後に、次世代APUのA10-7870Kが発売されましたが、悔しいので見なかったことにします…。

浮いたお金はメモリに

AMD APUのおかげで浮いたグラフィックカード代と、SSDを流用したおかげで浮いたストレージ代（※）を全てメモリにぶち込みました。おかげでメモリが32GB搭載のマシンになりました。

メモリだけで34,000円くらいしました。APUが16,000円くらいなので、大体2倍くらいです。我ながらアホだと思いますが、欲を言えば、搭載上限まで載せたかったです…。

今回買ったマザーボードは16GBモジュールx 4＝64GBが搭載上限でしたが、16GBモジュールが手に入らず諦めました。そりゃまあ16GBモジュールなんて誰が買いますか？って話ですよ。売ってないのも当然です。

一応、真面目な話もしておくと、元々16GBは積む予定でした。というのも、前のマシン（メモリ8GB搭載）は、開発用の仮想マシンと、統合開発環境と、ブラウザを同時に立ち上げて、ゴチャゴチャ作業していると、ときおりメモリが足りん！とお怒りになっていたからです。

仮想マシンと統合開発環境がGB級のメモリを使うのは、最近はもうそんなもんだよね、と思ってますが、なぜかブラウザも意外とメモリを使います。気づいたら1GB以上使っていることがあって油断なりません…。

（※）さすがに5年モノのHDDだけは、いつ壊れるかわからないので入れ替えました。いつもSeagateを使っていたのですが、SeagateはSamsungのHDD部門と合併してからというもの、あまり良い噂を聞かないので、今回はWestern DigitalのWD Blackを選びました。

今日は水曜日なんて誰が決めた？

Facebookでソフトイーサ株式会社の登さんが「日付と曜日の関連に根拠法はあるのか？」というエントリを書かれていて、いつも面白いことに気づく方だなあと思いつつ、私も興味が沸いてきたので調べてみました。

適当にググってもわからなかったので、近代日本の暦の原点ともいえる、太陰暦→太陽暦の変換点から調べることにしました。

政府、太陰暦やめるってよ

かつて太陰暦を使用していた日本ですが、明治6年1月1日をもって太陰暦から太陽暦に切り替え、以降現在に続くまで、太陽暦が使われています。

暦の切り替えについては、明治5年の詔書（国立公文書館 デジタルアーカイブ - 太政類典・第二編 - 太陰暦ヲ廃止太陽暦ヲ行フ附詔書）で頒布されています。

これは太政類典という書物でして、載っている文章を読むと「明治5年11月9日、第337号」と書いてあります。しかし法律という文字はなく、詔書と書いてあります。詔書とは、天皇が公務で意思表示をすること、らしいです。

さらに読み進めると「明治六年（神武紀元　二千五百三十三年）一月一日 水曜日」という記載もあります。

日付と曜日を結びつける法律は、この詔書にあるように思われます。しかし、

• 太政類典なる書物は何者でしょうか？
• 詔書＝法律でしょうか？
• 法律は現在も有効でしょうか？

こんな疑問も沸いてきましたので、もう少し調べてみます。

明治初期の法律制定

国立国会図書館の明治前期法令の調べ方 1. 明治前期の法令の概要、によれば、明治時代初期（明治19年 公文式制定まで）の法律は、制定方法が定まっておらず、太政官や政府の各省から日誌という形で発令されていたようです。今から見れば考えられないフリーダム時代ですね…。

また、国立公文書館の説明によれば、

（引用）
太政類典は、慶応3年(1867)から明治14年(1881)までの太政官日記及び日誌、
公文録などから典例条規（先例・法令等）を採録・浄書し、制度、官制、官規、
儀制等19部門に分類し、年代順に編集したものです。
（引用終わり）

だそうです。ちなみに太政官 記録課 類典科の編纂とのことです。太政官はその後の内閣に相当する機関ですね。

従って、太政類典に記載の詔書は、明治初期の法律と見なして良さそうです。

それにしても国立公文書館のJPEG画像で太政類典を読むのは辛い…見づらくて目が死にそうです…。

今も有効なのか？

明治5年の法律が今も有効なのか…？とお思いでしょうが、国立国会図書館 日本法令索引（明治前期編）によれば、

（引用）
太陰暦ヲ廃シ太陽暦ヲ頒行ス 明治5年11月9日 太政官第337号(布)

現在も効力を有する（平成18年現在）
（引用終わり）

とのことなので、現在も有効な法律だと言えます。頒布が明治5年（西暦1872年）ですから、ざっと140年以上前の法律が今も生きているわけです。何だか気が遠くなる話です。

他の書物について

ちなみに太政類典には明治6年1月1日が水曜という表が載っていますが、別の文書である「法令全書」にはなぜか新暦の日付と曜日の対応表は載っていません（国立国会図書館 デジタルコレクション 法令全書を参照）でした。

法令全書と太政類典で載っている文章の長さが違う原因は、法令全書は別紙を省略していて、太政類典は別紙まで載せているから、と推測したのですが、何がどうなったら別紙扱いなのかが全くわかりません。

国立国会図書館のサイト曰く「布告全書」には「法令全書」で省略されることが多い別紙や別冊が掲載されている、とのことなのでぜひ見たかったのですが…、
「東京までマイクロフィルム見に来いやー！」（書誌情報 - 布告全書 慶応3年12月-明治18年12月）
って書いてあったので、これ以上調べるのは諦めました。

結論

とりあえず、明治6年1月1日（1873年1月1日）は水曜日（詔書には、以降44日についても記載有り）であり、法律に定められていて、法律は現在も有効である、という結論にしておきたいと思います。

画像認識の可能性

「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側を読んで。

Splatoonの画面の特徴を活かした前処理、シンプルな機械学習アルゴリズム、速度で精度をカバーなど、実用レベル（認識率97％ → 99.99％）まで持っていく執念が本当にすごいです。門外漢ながら、非常にワクワクしました。

Splatoonに関しては、サーバ運営側がデータ見せるか、統計取りゃ画像認識は要らんよね？という意見はあるでしょうけど、画像認識なら、過去の動画、非ネットワークゲームの動画、果てはゲーム以外の動画も扱える汎用性が期待できます。

汎用性という視点で見ると19ページ目で汎用手法（OpenCV）が使い物にならなかった、とあって、画像認識は実用には遠いのか…、とも思いましたが、音声認識がほぼリアルタイムで出来るようになってきたのと同様に、画像認識も将来もっともっと良くなって、面白い未来に一役買ってくれるに違いないです。

山の日

当サイトのカレンダー（右側に出ているやつ）を改良して、2016年から施行の「国民の祝日に関する法律の一部を改正する法律」に対応しておきました。

こんな風に言うと小難しく聞こえますが、要は8月11日の「山の日」を追加しただけ、です。

自作ARMエミュレータとエスケープシーケンス

目次: Linux

自作ARMエミュレータ（リンク）の画面、制御文字がそのまま出てしまって非常に見づらいのと、BackSpaceキーすら機能せず非常に使いづらいので、画面が崩壊しない程度にエスケープシーケンス対応を入れました。

趣味とはいえデタラメに作るのは気が引けたので、エスケープシーケンスの規格についてググると、ANSI X3.64という記述をよく見かけます。ですが、肝心の規格書が見当たりません。

他にもISO/IEC 6429とECMA-048という記述も見かけますが、結局どれがメジャーなのか、良くわかりませんでした。

今回は、無料で取得できるECMA-048 5th editionを見ながら作りましたが、きちんと作ると面倒くさそうなので、だいぶ手抜き実装です。

パラメータの解釈が適当（03/00〜03/09以外は誤動作する、3個以上のパラメータは受け付けない）なのと、インタミディエイト？何それ？状態で、イジワルすると変な動きします。

メモ: 技術系の話はFacebookから転記しておくことにした。