読者です 読者をやめる 読者になる 読者になる

yumetodoの旅とプログラミングとかの記録

旅や登山の記録やプログラミング関連の話とかフリーソフト紹介とか

ChemBioOfficeがActiveXとかいう太古の技術に依存している件

化学をやっている人間なら名前くらいは聞いたことがあるだろう、ChemBioOfficeのお話だ。

東京理科大学では学生に無償で使えるように契約してくれているのでもちろん私も自分のPCに入れて使っている。

で、これが1年更新だ。ライセンスが切れたついでにChemBioOffice15からChemBioOffice16に乗り換えた。

install Window

ここでインストーラーのこの画像を見てほしい。

ん?ActiveX for IE??

ActiveXといえば開発元であるMicrosoftがすでに放棄した技術だ。地方税電子申告サイトeLTaxのサイトがJavaからActiveXに移ったことで袋叩きにされていた。

toyokeizai.net

ついでにいうとお隣韓国でも大問題になっている

japanese.joins.com

私はC++erではあるが、決してWebに無知というわけではない(仮にもみらいけんのWebページを未だに作り続けている)。当然このようなdeprecatedな技術にはNOを突きつけるべきだ。

ところがだ。これを見てくれ。

ChemDraw Rquire AciveX

The ChemDraw Control Panel requires a supported version of the ChemDraw ActiveX Control.

Registry key not found:
CLSID\{B8350810-35B3-46F8-AA9B-FC649FFF06DF}\ImprocServer32

いやいや、まてよ、何でんなもんに依存していやがるんだ?.NET全盛のこの時代、んなもん使わんでもできることくらい知っているぞ?

しかし現実問題としてChemDraw - Live link機能が使えないとお話にならない。

やむを得ずChemDraw ActiveX for IEChem3D ActiveX for IEをインストールした。

ちなみにcop16.0.1.exeからは特定コンポーネントだけインストールと言うのができないゴミなので、7-zipとかで解凍して、./Windows/PerkinElmer/ChemOffice/PerkinElmer_ChemOffice_Professional_2016.msiを実行するべし。

書きかけ:TsuboneSystemを試しにWindows10環境のlocalで動かしてみよう

node.jsとnpmの導入

更新の激しいnode.jsの導入をまさか公式のインストーラでやる輩はこの世に存在すまい。当然バージョン管理ソフトを使うべきだ。 Windowsだとnvmは利用できない(後述のmsys2上でもnvmのインストールはできるがそこからnode.jsをインストールできない)。というわけで

qiita.com

nodistを使う。まあnvm for Windowsでもいいのだが。

コマンドプロンプト

nodist dist

とすると、提供されているバージョンを一覧で表示できる。

nodist + latest

とすれば最新版が手に入る。執筆時点ではnode.jsは7.9.0が最新だった。あとは

nodist use latest

とすれば最新のnode.jsが利用できる。注意点として、どういうわけかpowershellで動かすとうまくいかない

そのままの勢いでnpmを最新にする。

npm update -g npm

これでよい。

MSYS2

  1. 7-Zipを落とす
    https://sevenzip.osdn.jp/
    より64bit版もしくは32bit版を
    既に入っている人も、2015/11/19に随分久しぶりに最新版が出たのでバージョンを上げるといいです
  2. 7zipをインストール
    ダブルクリックして実行すればいいです。
  3. msys2を落とす
    http://sourceforge.net/projects/msys2/files/Base/
    よりお使いのアーキテクチャ(おそらくはx86_64)をクリックしmsys2-base-[アーキテクチャ]-[日付].tar.xz を。exeの方は1回も使ったこと無いのでわかりません。
  4. 7-zipで解凍
  5. msys2_shell.cmdをダブルクリック、Close Windowと言われたらばってんを押して閉じる
  6. 再びmsys2_shell.cmdをダブルクリック、pacman -Syuuと打ち実行、また閉じる
  7. 再びmsys2_shell.cmdをダブルクリック、pacman -S mingw-w64-i686-clang mingw-w64-x86_64-clangとと打ち実行、また閉じる
  8. pacman -S base-devel mingw-w64-i686-openssl mingw-w64-x86_64-openssl mingw-w64-i686-go mingw-w64-x86_64-go gnupgする

そうしたら~/.bashrc

export GOROOT=${MINGW_PREFIX}/lib/go
export GOPATH=$HOME/.go

を追記します。GOPATHはまあどこでもいいんですが。

Tsubone System3を取ってくる

mingw64_shell.batを立ち上げ(なかったらmsys2_shell.cmd -mingw64)

$ go get -d github.com/kagucho/tsubonesystem3/
$ cd $GOPATH/src/github.com/kagucho/tsubonesystem3

する。この時、$GOPATH/src/github.com/kagucho/tsubonesystem3Windowsから見たパスを調べておく。

MariaDB

Download

まずはインストーラーを取ってくる必要がある。

今回はMariaDB 10.1.22 Stableを利用する。

Downloads - MariaDB

Downloads - MariaDB

からmariadb-10.1.22-winx64.msiをDownloadする。

GnuPG署名検証

Checksumをクリックして、GnuPGの署名をコピーし、mariadb-10.1.22-winx64.msiと同じ場所にmariadb-10.1.22-winx64.msi.sigとかしてテキストファイルを作り貼り付ける。

次にMariaDBのGPG公開鍵を取ってくる。

mariadb.com

にURLだけ載っているので、MSYS2を立ち上げ、

$ wget https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
$ gpg --quiet --with-fingerprint RPM-GPG-KEY-MariaDB

とする。

pub  1024D/1BB943DB 2010-02-02 MariaDB Package Signing Key <package-signing-key@mariadb.org>
 フィンガー・プリント = 1993 69E5 404B D5FC 7D2F  E43B CBCB 082A 1BB9 43DB
sub  4096g/672557E6 2010-02-02

このフィンガープリントが

GPG - MariaDB Knowledge Base

と一致していることを確認する。

そうしたら

$ gpg --import  RPM-GPG-KEY-MariaDB

として鍵を取り込み、

$ gpg -u <自分の公開鍵のid> --sign-key package-signing-key@mariadb.org

で署名する。自分の公開鍵のidは

$ gpg -k

すると

pub   4096R/FE05ED49 2017-03-23 [有効期限: 2019-03-23]
uid                  yumetodo <yume-wikijp@live.jp>
sub   4096R/830A7319 2017-03-23 [有効期限: 2019-03-23]

のように出て来るがこの場合FE05ED49がそれだ。ない場合は

qiita.com

この辺を見て作る。

さて、これで署名検証する準備ができた。Downlaodしたインストーラーのある場所に行く

$ cd <where you downlaod installer>
$ gpg --verify mariadb-10.1.22-winx64.msi.sig mariadb-10.1.22-winx64.msi
gpg: 2017年03月14日 05時37分47秒 JSTにDSA鍵ID 1BB943DBで施された署名
gpg: 信用データベースの検査
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、PGP信用モデル
gpg: 深さ: 0  有効性:   2  署名:   1  信用: 0-, 0q, 0n, 0m, 0f, 2u
gpg: 深さ: 1  有効性:   1  署名:   0  信用: 1-, 0q, 0n, 0m, 0f, 0u
gpg: 次回の信用データベース検査は、2019-03-23です
gpg: "MariaDB Package Signing Key <package-signing-key@mariadb.org>"からの正しい署名

検証終了だ。

Install

基本的には

mariadb.com

を見てインストールするべきだ。

インストールパスを変更したい場合はここでやる。

MariaDBの管理コンソールのrootユーサーのパスワードを設定する。好きなものを入れればいい

あとUse UTF8 as default server's character setは軽くググッた感じONにしたほうがいい気がする(あとで変えられそうだったのでまあ大した問題じゃないはず)

Port番号が3306とMySQLのWell Known Portになっているのは、MariaDBMySQLのforkだからだろうか。

DBの作成とデプロイ

まずはMariaDBのコンソールを立ち上げる。

私はWindows10のスタートメニューに耐えきれずにClassic Shellを入れているがまあMariaDBで検索すれば見つかるだろう。

CREATE DATABASE tsubonesystem;

する。;を忘れずに。

今度はCommand Prompt (MariaDB 10.1 (x64))を立ち上げて、$GOPATH/src/github.com/kagucho/tsubonesystem3Windowsから見たパスに移動する

"D:\Program Files\MariaDB 10.1\bin\mysql" -uroot -p tsubonesystem < test.sql

とするとデプロイできる。

msys2でnode.jsを使えるようにする

これが難儀した。まずmsys2のパッケージ管理システムであるpacmanで取ってこれるところにmingw-w64-x86_64-nodejsがある。これを利用すればいいと思うかもしれないが、まずnode.jsのバージョンがまだ6.x系だった。しかしそれが問題なのではない。ここでnpmを使おうとしてmingw-w64-x86_64-npmを入れようとしたら、そんなものはないという。

github.com

次にmsys2ならnvm使えるのでは?と思ったが、冒頭に書いたようにそうも行かない。

したがって、Windowsに普通にInstallしたnode.jsを利用することにした。

まずコマンドプロンプト

where node

とする。これでどこにnode.jsがインストールされているかわかる。私の場合は

C:\Program Files (x86)\Nodist\bin\node.exe

と表示されたのでC:\Program Files (x86)\Nodist\binにある。

次にmsys2のPATHにここを追加する。~/.bashrc

export PATH="/c/Program Files (x86)/Nodist/bin":$PATH

を追記してさらに、

$ cat "$NODIST_PREFIX/bin/nodist_bash_profile_content.sh" >> ~/.bashrc
$ source ~/.bashrc

としてnodistを呼べるようにしつつ反映する。

注意点として、まれにnpm -g系のコマンドが上手くいかないことがあるので、globalをいじるのはmsys2のbashからではなくコマンドプロンプトからやるほうが無難である。

build

msys2のshellで

$ cd $GOPATH/src/github.com/kagucho/tsubonesystem3
$ make prepare
$ make

する。

それから

どうすればいいんだ?ブラウザで検証したいんだが・・・

CMakeからVisual Stduo 2017でコンパイルしたBoostを探すのは時期尚早かも

Visual Studio 2017がリリースした

さて、Visual Stduo 2017が出てすでに1ヶ月経った。私も重い腰を上げて導入した。

www.visualstudio.com

をみると割りと頻繁にアップデートが来ていたりする。

Visual Studio 2017でBoost 1.63.0をコンパイルする

現在Boostの最新はBoost 1.63.0だ。しかしこいつは2016/12/26に出ており、2017/3/7に出たVisual Studio 2017に対応しているはずもない。

[Boost-users] Building Boost 1.62 With Visual Studio 2017 RC - Google グループ

そこでちょっと小細工をする。Boostのソースをダウンロードして展開した時にroot directoryにproject-config.jamがあると思うが、これを書き換える。パスは適宜読み替えてほしい。

x86向け
import option ; 
 
using msvc : 14.1 : "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\cl.exe"; 
 
option.set keep-going : false ; 
 

のように書き換えて

b2 toolset=msvc-14.1 threading=multi variant=debug,release link=static runtime-link=static address-model=32 --stagedir=stage/x86 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"
b2 toolset=msvc-14.1 threading=multi variant=debug,release link=shared runtime-link=shared address-model=32 --stagedir=stage/x86 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"

の用に実行する

x64向け
import option ; 
 
using msvc : 14.1 : "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe"; 
 
option.set keep-going : false ; 
 

のように書き換えて

b2 toolset=msvc-14.1 threading=multi variant=debug,release link=static runtime-link=static address-model=64 --stagedir=stage/x64 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"
b2 toolset=msvc-14.1 threading=multi variant=debug,release link=shared runtime-link=shared address-model=64 --stagedir=stage/x64 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"

の用にコンパイルします。

ちなみに、Boost1.64.0 Beta2ではproject-config.jamをいじらずとも対応しているそうです。

Visual Stduo 2017のcl.exeのバージョンは?

Visual Stduo 2017は当初cl.exeのバージョンが15.xになると思われていました。しかし、Visual Studio2015付属のcl.exeとの間でバイナリ互換になったため、14.10.xになりました。

github.com

CMakeからBoostを使う

には、find_packageを使うのが一般的です。

FindBoost — CMake 3.7.2 Documentation

CMakeの最新は3.7.2です。早速使ってみましょう

# find Boost
set(BOOST_ROOT ${BOOST_ROOT} CACHE PATH "Set boost root directory" FORCE)
set(BOOST_LIBRARYDIR ${BOOST_LIBRARYDIR} CACHE PATH "Set boost library directory" FORCE)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(Boost_DEBUG ON)
set(boost_required_components
    system iostreams thread
)
find_package(Boost 1.59 REQUIRED COMPONENTS ${boost_required_components})
CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1812 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.63.0

  Boost include path: D:/lib/boost_1_63_0

  Could not find the following static Boost libraries:

          boost_system
          boost_iostreams
          boost_thread

  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.
Call Stack (most recent call first):
  CMakeLists.txt:41 (find_package)

見事エラーになります。

CMakeがコケる原因
set(Boost_DEBUG ON)

して調べたところ、

[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1291 ] guessed _boost_COMPILER = -vc150

というDebug Printが。ん?-vc150

https://github.com/Kitware/CMake/blob/v3.7.2/Modules/FindBoost.cmake#L429-L431

  elseif("x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xMSVC")
    if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.10)
      set(_boost_COMPILER "-vc150")

上に書いたように、cl.exeのバージョンは14.10.xなのでこれはおかしいです。このせいでboost_xxx_-vc150-mt-yyy-1_63を探しに行っていたようです。そりゃ見つかるわけ無いわ。

改善の予兆

CMake3.8.0-rc3ではこの問題が治っているようです。該当commitは

github.com github.com

結論

もうちょっとだけいろいろ待ったほうが良さげ

と言いたいところだが、待てない。

github.com

if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.8)
    set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake/modules)
    include(FindBoost)
    message(STATUS "FindBoost: commit fb3f6fd3fe8eb2ebef26c6fa20624f32ee272760 is used.")
endif()

のようにしてcmakeのmaster branchから最新のFindBoost.cmakeを拾ってきた。

多分cmake3.8になれば解決しているはずなので一時的なwork aroundなのでcmakeのバージョンを見て分岐する。

あと、Boost_USE_DEBUG_RUNTIMEがOFFのとき、lib検索にバグがあるので

gitlab.kitware.com

CMake3.9.0まで待つか自分でFindBoostを引っ張ってくるべきでしょう。

内容メモと感想:【第1回PFLabフォーラム】自動運転からスパコン×Deep Learning、メニーコア×OS、ゲームAI、Xamarinまで豪華な内容盛り沢山!

タイトルの通り、PFLabフォーラムに行ってきた。

atnd.org

私は新宿税務署でアルバイトをしていて13:00まで新宿に拘束されていたので、加藤真平准教授による自動運転とベンチャー起業のお話は聞けなかった。

盛り上がりに欠けるというだけで呼ばれるちょまどさんと三宅さんぇ・・・

高精度3次元マッピング

自動操縦に必要なもの
  1. 周辺地図の構築
  2. 自分の位置の推定(localization)
  3. 行動計画
  4. Act!
三次元地図

→点群

すでに持っている3次元点群と新たに得た点群を重ね合わせる

How?

  • ICP
    すべての点群について計算→重い
  • NDT
    ボクセル(点群の小規模な部分集合)同士の位置合わせ(平均(傾向)・分散共分散行列(ばらつき))

やったこと

NDTの研究

インクリメンタルな地図登録

全部のボクセルを再計算する必要はないよね

従来のNDT : O(n):地図の点群数∝地図登録時間
インクリメンタルなNDT: O(1): 地図登録時間は一定

不均一なボクセルの更新

ボクセル内の点群がある程度貯まると、それ以上増えても平均・共分散に影響が少なくなる
→それ計算しなくてもいいよ!
→更新破棄

1msec程度の削減しかできなかった

モリーキャッシュが壊れそうなアルゴリズムだからまああんま早くならないだろうなぁ。

展望
  • 地図構築をGPU
  • ボクセルの大きさは不均一でもいい? # なんかNext HEVCみたい
  • ドローンで地図作ろう

ボクセルの大きさは不均一でもいいというのは、
rigayaの日記兼メモ帳 技研公開 2016
NHK技研でHEVC(今もっともよく使われているh.264の次世代のh.265のこと)の次世代コーデック開発で、 http://blog-imgs-104.fc2.com/r/i/g/rigaya34589/Giken2016_09s.jpg

圧縮の際の分割ブロック制御で似た話があったなぁ。


自動運転データストリーム

うん、私も???ってなりながら聞いてた。最後の方になってなんとなくわかったけど。

LiDARデータ: 360度回転画像を1frame
自己位置推定に使われる

→点群に変換

  • 地図とマッチング
  • 地図生成
  • etc

LiDARからRGB画像から抽出した物体までの距離を算出

Bagデータとして(生データ)収集

ーDeep Larningに流し込みにくい

変換ツールが必要やろ!

  • 撮影画像
  • Depth可視化画像

動画+LiDARでブレーキ予測できるか実験


Deep Larning

並列化された畳み込みニューラルネットワークのスケーラビリティに関する研究
→ # とは

ニューラルネットワークの大規模化

  • ResNet: 152層

CNN: 畳み込みニューラルネットワーク

パターン認識に特化

ちょっとこの辺は知識不足なので


この辺をあとで読もうを思っている。

→並列化したらうまく動くの? # GPUのほうが並列しているのは?

複数データの同時学習

  • Lowering Convlolution
  • 複数CPUでの学習

HTTとOpenMPとMPI

畳み込み層→重い
出力pixelごとに内積計算するから重い
→ Lowering Convlolution
→ 行列化→それは早い→行列生成がメモリーネック・浮動小数点演算→辛い

pipelined Lowering

細分化

特定の条件下でLowering < Pipelined

Lowering: 6倍
pipelined Lowering: +10% boost

マルチノード化で64並列で46倍


メニーコア

大体のCPUはせいぜい4Core

せいぜいみんなCoreは4つでしょ?Intel Xeon Phiなら>64 Core/ 256 threadやで

2g: 2次元メッシュアーキテクチャ

タイル→正方形状にネットワークにつながっている
タイル同士が通信

でも既存のOSじゃだめやろ!
→よろしいならばフルスクラッチ

まあメモリー管理はOSがやるべき仕事だからわかる。

github.com github.com

スピンロック

並列化するとどんどん遅くなる
→改善アルゴリズム(TTC, HCLH, etc…)多数→検証中

具体的には?
タイル内のロックは低コスト→どんどん使う

展望

高速計算以外でも使わないとアーキテクチャが死ぬ

  • 広帯域IO
  • 低消費電力


人工知能が拓くゲームの未来 - FINAL FANTASY XV が見せる人工知能の世界 -

ゲームAI
人工知能学会誌読もう

FINAL FANTASY XV

仲間、自然、モンスターがAIで動く

  • ルールベースのAI
  • プレイーやーの意思を読むAI
  • 自分の体の認識

現代は知能革命の時代に入りつつある

かつてはAIはゲームシステム内にあった

現代:

  • メタAI(予定調和)
  • キャラクターAI
  • ナビゲーションAI

が協調

AI量産のために

Luminous AI アーキテクチャを作った→アカデミックと違う

  • Luminous AI Graph
  • Luminous Navigation

単一の意思決定は十分でない
複数の意思決定を組み合わせる

→ロボットに適用

メタAI

体がない

映画監督

仲間同士で強調して動作したい

プレイヤーが寂しくないように

ex.) - プレイヤーや仲間のピンチを助けよ

キャラクターAI
  • 知能(AI graph)
  • 身体(ボディ・レイヤー)
  • アニメーション(AnimGraph)

の3つ

AnimGraphというツールでnode(それぞれモーション)を繋いでモーションのブレンド

環境世界 –{センサー・体}–> 知能世界(思考(認識の形成、意思決定、運動の構成)と記憶) –{エフェクト・体}–> 環境世界

  • 有限ステートマシン
  • 階層型ステートマシン

  • ステートマシーン

  • behavior tree

→いいとこ取りしたい

ハイブリッド型ノードフォーマット

www.slideshare.net

ステートマシーンのnodeがbehavior tree
逆も然り
Nodeの共有

→組合せ爆発を防ぐ

ナビゲーションAI
  • 地形を解析
  • 目的におおじた点を見つけ出す

目的地までのパスをを計算する

  • ダイクストラ法(同心円探索)
  • A*(スター)法(指向性探索) → 99%こっち

ナビゲーションメッシュ 地形の情報に合わせて歩ける部分のみ表示

スマートウェイポイント

3次元パス検索

立方体メッシュ(ボクセル化)→焼きなまし法で結合→A*アルゴリズム動かす→立方体のどこを動くか→さらに検索

戦略位置検出システム

自分の能力に合わせてポジショニングするシステム Point Query System

ステアリング
衝突回避
行きたい方向の空間の空きを見る
相互回避

移動モーション解析

  • 止まるときに現在の速度で停止までにかかる時間
  • 旋回性能

よなよなモンスターが頑張ってる

アンビエントAI

街にいる群衆を作る

オブジェクト側に知能を持たせる

キャラクターが近くに行くとキャラクターが操られる

オブジェクト: 情報発信

【会誌発行】人工知能学会誌 Vol. 32 No. 2 (2017/03) – 人工知能学会 (The Japanese Society for Artificial Intelligence) 表紙解説「ファイナルファンタジーXV


XamarinとMicrosoft Azure

Microsoft社の松屋宣伝担当・・・じゃなかった、テクニカルエバンジェリスト兼マンガ家の千代田まどか(ちょまど)さんの発表です。
特にメモ取る内容ではなかったというかツイート実況してたので以下ツイートまとめ。
ちょまどさんに実際に会うのはこれが初めてでしたが、某友人から「こいつはだめだ」みたいな話を聞いていたのでぶっちゃけそこまで期待してなんていなかったんだからねっ!(ツンデレ

内容的には blogs.msdn.microsoft.com に近い感じ。

な、なるほど?(わかっていない顔

セッションの説明 登壇者紹介

今日話すこと4つ

C#とは

暗黒の進化笑う。しかもその説明があながち間違っていないからあれだ。

私はF#知らない勢なのでfmfmという感じ

おまえらdynamicあるやん、という思い

ここでコンソールアプリケーションの説明で「コマンドプロンプト」という名前をど忘れしたちょまど氏。

C#をどんな言語かを見せるためにライブコーディングが始まりました。

REST API叩けばAsync/Awaitとかも見せられるから題材としては適当だよね。

www.infoq.com

本の虫: C++標準化委員会の文書のレビュー: P0022R1-P0092R1

[PDF] P0057R1: Wording for Coroutines

コルーチンの文面案。変更点は、とうとうキーワードが決定されたこと。co_await, co_yield, co_returnになった。なんだか泥臭い名前だ。しかし、await, yieldなど使えるわけがない。

future<void> g()
{
   std::cout << "processing f" << std::endl ;
   co_await f() ;
   std::cout << "resumed" << std::endl ;
}

うーむ。バイク小屋バイク小屋。

ちょっとここまでの講演に圧倒されて危機感を覚えたちょまどさんが慌てて追加した内容っぽい。

MRのほうがVRより古いって本当か?

Virtual reality - Wikipedia Mixed reality - Wikipedia

見ている感じそういう印象は受けないが・・・。

Xamarinのお話

ここで私の友人がXamarinのバグと戦った話を紹介しておきましょう。

Xamarin.Forms または私は如何にして心配するのをやめてバグを愛するようになったか — 173210's Blog

Xamarinとは

  1. 神奈川県座間市マスコットキャラクター
  2. 開発環境

ちょまど「名前空間の汚染が激しい」

ざまりん

Visual Studio 2017

Azure

内容的には

blogs.msdn.microsoft.com

のお話。

MBaaS

ここでプロジェクターが唐突に死亡する事件発生


終了

@meitel1014 (阪大勢) @blessingyukiとお話しつつ、ケンタッキーのチキンとミスドのなんかを食べつつして、その後3人で御茶ノ水まで歩いて各々帰りました。


感想

ちょまどさんのいいようではないけど、思ってたよりアカデミックな感じでびっくりした。

Deep Learningの話は予備知識がたりなさすぎて???ってなってたけど、3Dマッピングのあたりはなんとなく理解できた。

ゲームAIの話は、AIを考えるのはデザイナーの仕事なんだな、というのに驚いた。まあ結果AIを書くためのツールを作ったという話があったけど、そのツールそのものがかなりの価値があるんじゃないか、という思いだった。

ちょまどさんの発表は・・・、まあせっかくAzureの試用ライセンスもらったので使ってみようかなと思っています。

拡張子とファイルのフォーマット

strimuer213p.hatenablog.com

先日Twitterでどうにも りーま氏(@strimuer213p)に拡張子とファイルのフォーマットは関係ないということが伝えられなかったので、ちょっと記事にしてみる。

ファイルの種類

まずいろんなファイルを片っ端からバイナリエディタで開いてみて欲しい。 Windowsをお使いならFavBinEditLinuxをお使いならGHexなどがいいのではないか。もちろんそんなところで宗教戦争をするつもりはないので、好きなものを使えばいい。
おれはコマンドがいいというなら、odコマンドがUnixにはあるし、GNU拡張のodコマンドはasciiの表示もしてくれる。

hex dump

さて、開いてみてわかる通り、つまるところファイルとはただ単にbyte列の羅列だ。
多くのバイナリエディタは16進数でbyte列を表示してくれるが、別に8進数で表示するもののあるし、単に見た目の問題だ。
つまりすべてのファイルは(厳密には)バイナリファイルだと言える。

これをとりあえず大きく2つに分類する。

テキストファイル

コンピュータで文字を扱うときにどうするかというと、特定のbyte列で文字を表す。文字をその特定のbyte列に直すことを、文字エンコード、と言ったりする。
この変換の規則が(広義での)文字コードである。

広義での、とぼかして書くのには理由があって、実際にはかなりややこしいことになっているのだが、

equj65.net blog.shibayu36.org

それはこの辺のサイトに説明を譲る。本題ではないからだ。

話を戻す。

とにかく、ある一つの文字コードによってエンコードされたbyte列のみで構成させるファイルをテキストファイルと呼ぶ。

(一般的な意味での)バイナリファイル

先ほど、

つまりすべてのファイルは(厳密には)バイナリファイルだと言える。

と書いたが、一般にバイナリファイルと言われて指すものはそうではなく、すべてのファイルからテキストファイルを除いたものである。

テキストファイルの種類

テキストファイルといってもさまざまな種類がある。 どういうことかというと、何らかのルールにしたがって羅列されたテキストファイル、というのがある。

例えばHTMLは、W3Cが定めたHTML規格に則って文字列を記述することで、例えばブラウザでいわゆるWebページを作れる。
Markdownは一応CommonMarkが標準規格としてあって、それにしたがって記述すれば、適当なツールでHTMLに変換できる(GFMはなんなんだという話はさておき)。
xmlは特定のデータ集合をソフトウェア間でやり取りするときに用いられ、xml上でのデータ構造そのものに意味がある。

(一般的な意味での)バイナリファイルの種類

バイナリファイルの形式は千差万別である。 C言語の構造体をそのまま書きだしたものと思ってよく、したがってバイナリファイルを扱うには処理系依存との戦いが開催される(C言語規格書の処理系依存部分との戦いの他に、エンディアン(バイトオーダー)との戦いがある)。多くのバイナリファイルフォーマットはバイトオーダーについて規定している(していないフォーマットはバグっている)。 このポータビリティ(可搬性)の低さと、多くのプログラミング言語で扱いが難しいことから、敬遠されやすい[要出典]

今日では、データが膨大になりやすい画像・音声・映像、それを格納するコンテナのフォーマットとして利用される傾向にある。

bmpは画像フォーマットの一つで、0x42 0x4dから始まる。

doc/xls/pptMicrosoft Officeで最もよく利用されていた利用されるファイルフォーマットである。

mp4は一般に映像や音声を格納するコンテナである。mp4そのものは映像フォーマットでも音声フォーマットでもないが、映像圧縮にh.264、音声圧縮にaacを使った(mp4(h.264/aac)と表記することが多い)mp4ファイルが広く流通しすぎた結果、mp4を映像フォーマットと勘違いしている人が多い。

zipはディレクトリ構造をファイルに変換すると同時に圧縮を行うことを想定しているファイルフォーマットである。もっとも圧縮は義務ではなく、複数の圧縮アルゴリズムから選択できる。一般的にはRFC 1951で規格化されたDEFLATEが圧縮アルゴリズムに採用されている。

また忘れてはいけないものとして、実行ファイルもある。Windowsなら.exeという拡張子がついている。

テキストファイルを特定のディレクトリ構造に配置したものをzip圧縮したファイルの種類

上記のようなバイナリファイルは扱いが難しいことから、複数のテキストファイルなどをzipで固めたものを独自のフォーマットとすることも多い。またこうすることで可搬性とデータサイズの小ささを両立しやすい。

こうしたファイルは特定の形式のファイルを特定のディレクトリ構造に配置したものをzipで圧縮していることを要求する。つまりzipファイルの特殊例(部分集合)である。

odt/ods/odp/odb/odg/odfはLibre Officeやその前身のOpenOfficeなどで最もよく利用されているファイルフォーマットである。実はMicrosoft Officeでも取り扱える。OpenDocument Formatと呼ばれ、ISO/IEC 26300などで標準化されている。

docx/xlsx/pptxOpenDocument Formatに対抗してMicrosoftが開発したファイルフォーマットでMicrosoft Officeで現在もっともよく利用されている。Office Open XMLと呼ばれECMA-376、ISO/IEC 29500:2008で標準化されている。

ただしここで大急ぎで補足しよう。

こう書くとバイナリファイルが2種類あると勘違いする人がいるかもしれないが断じて違う。
そもそも特定のディレクトリ構造をファイルに固めることができるファイルフォーマットはなにもzipだけではない(tarとかとか)。
zipファイルだって(一般的な意味での)バイナリファイルに含まれる
あえて数式で書けば、zip∈バイナリファイルだ。

ファイルはOSからどのように管理されるか

すこし話が変わる。FAT32とかNTFSとかext4とかという単語を聞いたことがあるだろうか?

私たちは普段ファイルを管理するのにディレクトリ(フォルダー)という概念を使っている。
これを実現しているのがさっき述べたようなディスクファイルシステムだ。

ファイル名や作成日時、更新日時、アクセス権限や、ディスクのどのセクターに書き込まれているかなどといった(例外はある)ことを管理している。

よく聞く拡張子とは、じつは単にファイル名の末尾から最初に現れた.までの文字列を(ただしファイル名の最初の文字が.の場合を除く)そう呼んでいるに過ぎない。

拡張子の役割

じつは何もない。むしろいらない。(大げさ)

しかし、人間がファイルを見てそれがどういう種類のファイルなのか判別するのにどうすればいいのかという問題がある。

バイナリファイルだけだったら、ファイルを解析して各フォーマットに固有なマジックナンバーを探すことで適切に処理ができる。それをパースして見せるソフトウェアがあれば人間はファイルの種類を判別できる。

しかしテキストファイルはそうはいかない。
xmlやhtmlのように冒頭で種類を宣言している場合はともかく、そうでない場合のほうが圧倒的多数である。

またファイルを解析するという作業は一度ファイルを開く必要があり、ディスクファイルシステムを見ればいいだけである拡張子をみる作業よりコストが高い。

そこで拡張子の出番だ。予めファイルの種類に対応する拡張子(かつてはアルファベット3文字程度が多かったが、しょっちゅう被るので最近は.vcxprojのように長いものが多い気がする)を利用者の間で決めておく。例えばWindowsでは実行ファイルはexecuteを省略して.exeを拡張子にするというコンセンサス(合意)がある。

C言語プリプロセッサとテキストファイルと拡張子

C言語を学習している人のために、もう一つ例を見てみよう。

御存知の通り、C言語ソースコード.cC言語のヘッダーファイルは.hという拡張子を主に使う。ここで

#include "a.h"

のようなソースコードC言語を学んだ人なら誰でも書いたことがあるだろうが、

#include "b.c"
#include "table.csv"

とかいうコードを見るととたんに頭がこんがらがる人いる。

これはC言語の入門書や入門サイト、はたまた学校での講義などが悪い。[要出典]

#includeはヘッダーファイルを読み込むときに使う構文ですよ。
ほら、#include <stdio.h>とかくとprintf関数が使えるでしょ?

などという嘘八百を平気で教えている。ひどいことにプリプロセッサが何かという説明すらしていないことも多い。
ハローワールドを教えた直後ならともかく、一通り教えたあとでもそんなことではお話にならないが、学校での講義や入門サイトはおおよそ例外なくそうなってしまう現状にあり[要出典]、入門書でも記述していなかったりする。
(なお独習Cは筆者にとっては残念なことに正しく解説がなされていたように思う)

C/C++にはプリプロセス時、コンパイル時、実行時の3つの世界が存在するが、

#includeとはこの内プリプロセス時にプリプロセッサによって解釈される構文だ。

機能としては、#include文を対象ファイルから消し去り、代わりに#include文で指定されたテキストファイルをその場所にコピペする、と言うものだ。

cpplover.blogspot.jp

[PDF] N4214: A Module System for C++ (Revision 2)

40年前のコピペ技術である#inludeにかわるモジュール機能の提案。

現在、C++が使っているコンパイルとリンクモデルは、C言語から受け継いだものである。各翻訳単位は、他の翻訳単位のことを一切知らずに処理される。翻訳単位を超えるには、名前リンケージ(シンボル名)を使う。名前に対応する定義はひとつだけでなければならない(ODR)。

翻訳単位の外に見える名前である外部名を、手動によるコピペで管理することを防ぐために、我々は40年前の技術である自動コピペ技術、プリプロセッサーによるヘッダーファイルを未だに使っている。これは、コンパイラーからみれば、コピペである。

ヘッダーファイルの中身はマクロによって書き換わってしまうおそれがあり、誤りの元である。

変数や関数の宣言ぐらいしか書かれていなかった昔のC言語ならば、まだ十分に耐えられたのだが、モダンなC++では、ヘッダーファイルには実行されるコードが記述されている。コンパイラーは翻訳単位ごとに重複した内容を処理しなければならず、現代のC++コンパイル時間の増大の原因になっている。

ただの自動コピペ機能なのだからテキストファイルならなんでも読み込める。まあそのあとコンパイルエラーになるかどうかは別問題であるが、それはコンパイル時のお話だ。

csvプリプロセス時読み込みはcsvに多少細工をしておくことで

qiita.com

に書いたように意味のあることに使える。

拡張子とソフトウェアの関連付け

Windows

Windowsの場合、拡張子とソフトウェアの関連付けはOSレベルで提供されている。

www.atmarkit.co.jp

もっというとレジストリに関連付け情報が記録されている。

レジストリの直接編集によるファイルの拡張子と関連づけ - Glamenv-Septzen.net

Mac

知らず

Linux

ない。なぜならばユーザーはどうせ適切なコマンドにファイルを渡すのだから。

ただ、GUI操作においては、ダブルクリックしたら適切なソフトが立ち上がらないと不便なので、ファイラーが関連付け機能を提供している。

まとめ

すべてのファイルは厳密にはバイナリファイルと言える。
すべてのファイルはテキストファイルであるかそうでないか(一般的な意味でのバイナリファイル)で分類される。
つまり、一般的な意味でのバイナリファイルとテキストファイルは全てのファイルの部分集合である。
またバイナリファイルと言っても、特にzipファイルは特定のファイルが特定のディレクトリ構造をとる場合の特殊例に名前がついていることがある(ex. xlsx)
zipファイルは一般的な意味でのバイナリファイルの部分集合であり、xlsxファイルはzipファイルの部分集合と言える。

さまざまな角度から拡張子とファイルのフォーマットについて見てきた。それぞれが全く異なるものであることがご理解いただけただろうか?そうであれば幸いだし、そうでなくても調べるきっかけくらいにはなっただろう。

をるふちゃんが懲りずにコミュニティを作ったらしいので参加した

wolf-cpp.hateblo.jp

ということで、自称Twitterよりきもち情報濃いめのゆるふわコミュニティに参加しました。

C++の会のSlackよりもだいぶゆるふわしている感じです。C++以外にもC#,lisp,ruby,Scala,php,go,python,Haskellなんかのチャンネルが

一応TOPページは

hackmd.io

から。


早速Wiki編集してきた

hackmd.io


追記

SlackとDiscord両方立ち上げるのが面倒なので、Franzというアプリを入れた。
Franz – a free messaging app for Slack, Facebook Messenger, WhatsApp, Telegram and more

唯一の欠点はDiscordの〜〜をプレイ中という機能が使えないことだろうか。
電卓をプレイ中は草。

FC2からはてなブログに移行した

はじめに

私は今まで フリーソフトの旅(windows) という、FC2のブログサービスを利用してほそぼそとブログを書いていたのだが、この度、はてなブログに移行した。

移行した理由

  • FC2で使っていたデザインテンプレートがHTML4.01で、HTML5にする作業をしてみたが思いの外面倒だった
  • 基本的に写真はGoogle Picasaに置いてそれを呼び出すようにしていたのだが、Google PicasaGoogle Photosになった時に、画像埋め込みリンクが簡単に取得できなくなったが、はてなブログにはGoogle Photosとの連携があるので極めて簡単に写真を貼り付けられる
  • Markdownが使える、HTML直書きしなくていい
  • はてなブログのデザインはGithub上でLESSファイルで提供されており、CSSのように人間を卒業しなくてもカスタマイズできる
  • はてなブログのデザインはレスポンシブデザインに対応している
  • はてなブログのデザインをShippableと組み合わせて自動デプロイする作業に憧れた
  • フリーソフトの旅(windows)」という前のブログのタイトルと中身があっていなかった
  • プログラマー界隈はやっぱりはてぶろ勢が多い
  • カテゴリーがFC2より柔軟

Markdownが使えるっていうのは大きいですね。wysiwygエディタは信用していないので(FC2のやつが吐くコードは糞だった)HTML直書きしていたんですが、さすがにつらみがあった。

移行のときに参考にしたもの

tsubakit1.hateblo.jp

なんかこの方は画像の移行に苦労しているけれど、ほとんどの画像はすでにGoogle Photosにあったので何もする必要がなかった。
Picasaを知る前に書いた記事2本だけはFC2に画像置いていたからこれはMarkdownで自力で書き直した。

また、この方はわざわざはてなダイアリーを経由しているが、そんなことはしなくても普通にいけた。もともとFC2ではHTML直書きしてたから、というのもあるのだろうか。 FC2のときはFC2解析を使っていたのでそのコードを各記事に埋め込んでいたのですが、それはFC2からExportしたテキストファイルの段階で消しました。

デザインの自作

できればあまりデザインを変えたくなかったのですが、FC2のブログデザインで使われている背景画像は著作権的にこっちに持ってこれないので、適当な画像を探していたら、

www.pakutaso.com

を見つけまして、ええやん、となって

github.com

一気に開発しました。

LESSとJavaScriptで開発しています。いや、JavaScriptはいらないはずなんですが、ブログタイトルのmarginpaddingを弄って背景画像とブログ記事の開始位置の相対位置を固定したくて使ってます。CSSだけだとまだ動的に幅の参照とかできないはず。HTML構造ごと変えればCSSだけにできるけどだるいのでJavaScript使ってます。

書いたLESSとJavaScriptはShippableというCIに投げつけて、LESSはCSSにしてminify、JavaScriptGoogle Closure Compilerでminify&ES5化してます。この辺は後でQiitaにでも書く予定。

追記

qiita.com

書いた。

不満な点

HTTPS化できないことかな。

かと言ってサーバー立ち上げたり借りたりしてWordPress使う気にはなれなかったし、 友人が

173210's Blog

でやってるみたいにGithub pages使うことも考えたけど、それはそれでコメントシステムとかどうすんの?という思いがありはてなブログ使っているけど。

まだ移行できていないもの

雲取山に登山した記事

雲取山に登山した記事で国土地理院の地図に書き込みしたものを公開しているのだが、国土地理院側の仕様変更がいつのまにかあったらしく壊れていた。今ちまちまコンバーターを書いている。

SyntaxHighlighter

はてなブログにはもともとSyntaxHighlightしてくれるやつがあるっぽい。実際使ってみたが、正直気に入らない。 あとインポートした記事のSyntaxHighlightは記法がちがうのかうまく行ってないのでどのみちSyntaxHighlighterが必要そうだ。

追記

試しに有効にしたらMaximum call stack size exceededとでて、かつトップバーが読み込まれないので、あきらめモード。data-unlink=""とかそういう問題じゃない。 minifyされてないSyntaxHighlighterで試したらなんかそこかしこで無限再帰している。はてなブログのなにが干渉しているのだろう。かといってiframesrcdoc使うのはなぁ・・・。

広告が表示されない

これは大問題だ。 Imgur この12個のエラー、どうにかならないのか・・・。

元記事からのリダイレクト

これどうすっかな・・・。まあJavaScriptで書くんだけど、URLががらっと変わってるもんで、厳密に各記事をリダイレクトするには変換テーブルを持っておく必要があるな・・・。