2022年1月の日記

しばらくautoが使えるところは全部autoを使うようにしてみた。
だいぶ馴染んできた。
関数の戻り値の型を後置にするのも見た目が良い。
どうせなら、funcとかfnとかにしてしまいたくなる。
そこで、

#define fn auto
#define let auto

とかしてしまえば、Rustぽくなる。

fn add(int a, int b) -> int {
  return a + b;
}

fn main() -> int {
  let a = 1;
  let b = 2;
  let c = add(a, b);
  std::cout << c << '\n';
}

見た目は悪くない。
ちょっとした遊び。
実際にこんなことをすることはない。

SuperBibleだけ読んでいると気が滅入ってくるので、気晴らしネット上のチュートリアルにトライしていた。
SuperBibleはglfw3を使っている。
しかし、独自に用意されたフレームワークで隠されているので表には出てこない。
一度glfw3を使ったらどういう感じなのかを体験しておくのも良いだろう。
今日はfreeglutの方をやってみた。
思ったより簡単だ。
簡単は言いすぎかもしれない。
考え方は直球で、理解はしやすい。
しかし、コードがシンプルになるかというとそうでもない。
上から順番に命令を並べていく感じで、その命令一つ一つが細かい。
何も考えずにだらだらと書いていたら、すぐに読み難いものになってしまう。
もっとも、これはfreeglutが悪い訳ではない。
glfw3を使っても同じことだろう。
ツールキットの選択肢はあまりない。
SDLとSFMLも試しておきたい。

OpenGLのバージョン1とか2とかやっておく必要あるのだろうか。
検索するとそれらの古いバージョンのチュートリアルが上位に来る。
まだ需要があるということだろうか。
歴史的な価値と興味本位から見ておきたいということで関心はある。

ひたすら寝てた。

ひたすら寝ていた。
18時間くらい寝た。

途中になってたやつを読み終えた。
昨日買ったのとは全然関係のない本。

少し前にDirectXが使えるのは、WindowsとXboxしかないと適当に書いた。
しかし、PS4ではグラフィックスAPIとしてDirectXのようなAPIも用意されているらしい。

GOSICKのBLACKとかBLUEがないか見に行った。
目的のものはなかった。
代わりに、別の読んだことないのが7冊あった。
確保しておいた。
GOSICKは最初の1巻だけ読んで止まっている。
そろそろ読んでいこう。

病院に行くため、有給で休み。
特にいつも通りだった。

帰りに本屋とマルツに寄っていった。
本は4冊購入。

• JavaScript 第7版
  
• ゼロから作るディープラーニング2
  
• ゼロから作るディープラーニング3
  
• 線形代数入門
  

1万5千円程度。
そこそこの出費になった。
プログラミングRustの第2版が出ていたので、確保しておきたかったが、オライリーばかりになるのを嫌って今回は見送った。
でもどうせ買うことになるのだろうから買っておいてもよかった。
線形代数入門は、以前から気になっていた、評判の良い東京大学出版会のやつだ。
この基礎数学はシリーズになって、6冊くらいおいてあった。
次の解析入門と線形代数演習くらいまでは読んでおきたい。

本屋のすぐそばにあるマクドナルドでビッグマックのランチセットを食べた。
じゃがいもが不足しているらしく、マックポテトはSサイズしか頼めなくなっていた。
合計で510円とかなり安い。
昨日はモスのセットを食べたが、980円だった。
モスではポテトを普通にLにできた。

マルツではラズパイ3の公式ケースを買っておいた。
前回見送ったやつだ。
1500円とちょっと高い。
ラズパイ4のは900円くらいなんだが。
ラズパイ4は発熱対策のファンが必須と言われている。
公式ケースをそのまま使うのは厳しいだろうと判断して買っていない。

帰ってから6時間くらい寝た。
18時くらいに起きて、ちょっと熱っぽいなと思って測ったら、38.2℃あった。
朝は平熱だったのだが何があったのだろうと不安になる。
また6時間くらい寝てから再度測ったら、37.0℃まで下ってた。
一時的なものだったみたいで良かった。
この時期に熱が出るとひやりとする。

迎えにいかなければいけなかったので、時間まで図書館で時間を潰した。
借りていた本を消化していった。
ひどいはずれもあれば、当たりもあった。

OpenGLのプログラミングでは、GLUTのようなツールキットと呼ばれるものを使うことが多い。
(オリジナルのGLUTは古過ぎるので、freeglutが使われる。)
ツールキットを使えば、ウィンドウを作成したり表示したりするコードを肩代わりしてくれる。
単に楽ができるだけではない。
OSやGUIに依存したコードは隠されるため、複数の環境で動くプログラムになる。

DirectXのプログラミングでは、このようなツールキットを使うことはあまりない。
DirectXとOpenGLの方針の違いにもよるのだろう。
そもそもWindows環境以外でDirectXが使えるのはXboxくらいしかない。
複数の環境で動くように、OSに依存したコードを隠す必要性はあまりない。
また目的もやや異なる。
おそらくDirectXを扱うのは、ゲームのコードではかなり下の方のレイヤーになる。
例えばゲームエンジンのレンダリングを担当する部分など。
APIは使い易さよりも、効率性や詳細にチューニングを施せるようになっていることの方が重視される。
ツールキットを使って簡単に、手軽にプログラミングできるようにすることとは方向性が合わない。

OpenGLもDirectXとそれほど事情が違う訳でもない。
しかし、OpenGLは複数の環境で使われる。
複数の環境で同じコードが動くようにするには、ウィンドウを作成したり表示したりするコードを隠さないといけない。
それがOpenGLのプログラミングではツールキットが利用される一番の理由だろう。
OpenGLの利用目的の違いにもよる。
DirectXのときと同じように、ゲームエンジンというプログラムの一部の下の方のレイヤーとして用いられるなら、やはりツールキットの利用は目的に合わない。
いつかはツールキットを利用しない、生のOpenGLのコードを書く必要に迫られるかもしれない。
それとは別に、興味本位からも一度は触れておきたいところだ。

参考：OpenGLに関わるライブラリのリスト

今日からOpenGLをメインにやることにした。
それで OpenGL SuperBible 7th Edition という本を軸にトレーニングをしていこうと思う。
数年前に6th Editionを1/4くらい読んだところで中断していた。
その後、去年、Amazonで割りと安く7th Edtionを購入することができた。
買っただけでまったく手つかずの状態だった。
もう6thはいいから、7thから始めようと思う。
とりあえずサンプルコードをダウンロードしてきて、ビルドした。
Solusの場合、glfwとmesalib-develというパッケージを追加でインストールする必要があった。
いくつか起動しないものがあるものの、ビルドはすんなりいった。

ちょっとやっかいな問題がある。
この本では、テクスチャにktxと、3Dモデルにオリジナルのsbmというフォーマットを使っている。
本にはそれらのためのツールである、ktxtoolとsb6mtoolというのもサンプルに含めていると書かれているが、存在していない。
ネットを検索してみても情報は何もない。
OpenGLの入門書としては定番の本だと思っていたので、何も情報がないのは腑に落ちない。
GitHubのリポジトリは7年間更新されていない。
1年以上前からホームページは壊れていて、コンテンツが表示されない。
以前6thを読んでいたときも同じことで悩んでいた。

Texの記法で書いた数式をHTMLエクスポートすると、分数の区切線や、平方根の上の線の位置がずれる。
わずかに下にずれて気持ち悪い。
どうもLANGUAGEを日本語(ja)にするとこうなるようだ。
英語(en)にしたときは発生しない。
またChromeでは発生しない。
確認したのはFirefoxのみ。

数式を描画するために、org-modeはデフォルトではMathJaxを使う。
そして、問題の線はCSSのborder-topでやっている模様。
日本語でのみ発生するということは、フォントの高さの計算の際に日本語フォントが関係してずれてしまっているということだろう。

いくつかMathJaxのレンダリングの選択肢があって、デフォルトではHTML-CSSによるレンダリングになっている。
レンダラをCommon HTMLを使うようにすればとりあえずは解決する。

もっと簡単な解決策があった。
MathJaxの使用するフォントを設定するオプションがあった。

#+HTML_MATHJAX: font:Neo-Euler

これで解決した。
参考

フォントは他にも以下が選択できる。

• MathJax TeX (default)
  
• STIX General
  
• Asana Math
  
• Neo Euler
  
• Gyre Pagella
  
• Gyre Termes
  
• Latin Modern
  

参考

BMIの計算。
めっちゃ苦痛になってきた。
BMIだけだと簡単すぎると思って二次方程式の解を求めるというのもやるつもりだったけど、パスした。
やっぱり長くなりすぎた。

だいぶ前のブロック崩し3では数式にMathMLを使っていた。
Firefoxではちゃんと表示されるのだけど、Chromeでは表示されてなかった。
なぜかChromemでもローカルでファイルとして開くと表示される。
どっちみちMathMLは読むのも書くのも大変なんで使いたくない。
書き換えておいた。

久々に朝からゲーム。
スターオーシャン5の続き。
たまってるクエストを消化していった。
まとめて一気に報告するのが気持いい。
ストーリーも結構進んだ。
プレイ時間20時間くらい。
雰囲気からはまだ中盤に入ったどうかというところ。

なんか500円でプレイしてるのが申し訳なってくる。
というくらい普通に遊べている。

昨日夜で結構積った。
まだ降っている。
建物の構造がおかしいため、車庫の周りが大変なことになっている。
どかさないと危ない。
遅刻してでもやっていった。
今日を乗り越えればもう大丈夫だろう。

新しく一箇所発見したのでそこも治療してもらった。
薬がでた。
漢方薬。
どれも小さなものだったので、そろそろ完治していても良いのではないだろうか。
治療痕を見ても自分では判断がつかない。
やはりまだ残っているのだろうか。

FF5は古代図書館までいった。
青魔法を色々ラーニングできる場所だ。
で、一時中断。

スターオーシャン5を再開した。
プレイ時間はまだ4時間くらい。
だいぶ前に500円で購入したもので、始めはそれほど期待していなかった。
実際やってみると全然遊べる。
たぶんクリアまではやるだろう。

C++の本3冊と"40 Algorithms Every Programmers Should Know"というのをチョイスした。
普通にカードで支払えた。
"40 Algorithms…"の方は今年の6月に第2版がでるようだ。
買った直後に知った。
とりあえず今年はこんなものでいいか。
割りと満足した。

3年契約で9900円とかなり安い。
ただ、用途が限られているように思える。
PHPとMySQLが使えるのは、ほとんどWordPressのためだけのように思える。
例えば、Laravelで作ったアプリケーションを配置したりするとかいった用途に使えるんだろうか。

Vプリカ2000円分を今日中に使ってしまおう。
残して置いても使い道がない。
しかし、サブスクリプション入ったから、絶対欲しいというのがなかなか見つからない。

やっと3冊選んでチェックアウトしようと思ったら、Vプリカは受け付けてくれなかった。
VISAのカードとして認識してくれない。
無念。

何故か唐突に始めた。
初代PSのFFコレクションに入っているやつ。
PS版はかなり問題があって、メニューに入るときは、エンカウント時にちょっとしたラグが入る。
ラグというかロードといったほうが正しいのだろうか。
購入して始めてプレイしようとしたとき、耐え切れずに諦めた。
今日ちょっとやってみたら5は何とかプレイ可能かもと思えた。
しかし、今ピクセルリマスターが出たところなのに、敢えてPS版をやるのはいかがなものだろう。
まだ序盤で、火のクリスタルの船に乗り込むところだ。
ピクセルリマスターで最初からやり直すのならまだぎり間に合う。

やっと終わった。
だんだん苦痛になってきた。
Luaの経験が乏しいため、思うように書けない。
このまま続けることが出来るのか不安になってきた。
それに最近はずっとこの記事のことばっかやってて、他のことが何もできていない。
時間を決めて、その時間内にできることに制限してしまった方がいい。
クオリティはこの際考えないようにした方がいい。

チャンクという単語が正確に何を指すのかはリファレンスマニュアルに書かれていた。
しかし、まだよく分からない。
文法的にはブロックと同じようだ。

Chunkのところをよく見ると、Luaがどのようにコードを実行するのかが書かれている。
まず、チャンクをロードして、チャンクのコードはVMの命令にコンパイルされる。
そして、VMのインタープリタでコンパイルされたコードを実行する。
と書かれている。

入門その1ではかなり適当なことを書いてしまった。
直さないといけない。

もう一つ興味深いことに、Luaでは式は文になれないというのがある。
次のような内容のファイルを実行しようとするとエラーになる。

1234

関数呼び出しだけは特別で、式だけど文にもなれる。

基本は式なので、代入文の右辺にもなれるし、算術演算や関係演算のオペランドになることもできる。

local x = add(1, 2) -- OK
local y = 3 + add(1, 2) -- OK
if add(1, 2) == 3 then print("OK") end -- OK

しかし、次のような内容のファイルを実行しても問題は起きない。

print("OK")

もし、関数呼び出しが式としてしか機能しないのなら、これはLuaのルールではエラーになってしまう。
それではあまりに不便すぎるので、特別に文のように振る舞うようになっている。
と理解した。

式と文に関するその他の興味深いトピック

• http://lua-users.org/wiki/ExpressionsAsStatements
  
• http://lua-users.org/wiki/StatementsInExpressions
  

夜のうちに結構積もってた。
朝出れなくて、昼から出勤した。

去年末に借りた「エレクトロニクスをはじめよう」というオライリーの本を返しに行った。
というか、まだ読んでなかったので再度貸出にしてもらいに行った。
ついでに何冊か借りてきた。
普段絶対読まないようなビジネス関係の本だ。

以前書いた、起動時のエラー

Error (use-package): multi-line/:catch: Symbol’s value as variable is void: multi-line-candidate

さっきパッケージをアップデートしたらmulti-lineというパッケージの更新も含まれていた。
起動し直すとエラーは出なくなっていた。

https://github.com/syl20bnr/spacemacs/issues/15255

今採用しているのは、次のようなもの。

• クラス名は MyClassName のような単語の区切りで大文字小文字切り替える。
  
• 関数名は my_function_name のように、単語の区切りをアンダーバーで繋ぐ。
  
• 変数名も my_variable_name のように、単語の区切をアンダーバーで繋ぐ。
  ただし、メンバ変数名は my_member_variable_name_ のように、名前の最後に余分なアンダーバーを付ける。
  

一見問題なさそうだけど、微妙にぎこちない。
クラス名は大文字小文字が入り乱れ、関数名と変数名は小文字のみになる点で、一貫性に欠ける。

関数名を myFunctionName 変数名を myVariableName のようにすれば一貫性は保てる。
メンバ変数名は mMyMemberVariableName のようにする。
だけど、あんまり好きじゃない。
単語の区切りが認識しづらい。
それに、なぜ頭だけ小文字にするのか、日常的な感覚からは理解し難い。

Googleのスタイルだと、関数名を MyFunctionName のようにクラス名と同じ、大文字から始めている。
そして、変数名はアンダーバーで繋いでいる。

もうひとつ考えられるのは、クラス名も、関数名や変数名と同様、全部小文字で区切りをアンダーバーにしてしまうというスタイル。
標準ライブラリやBoostがそうなっている。
このスタイルは一貫性という点においては最強だ。
しかし、アプリケーションのコードではあまり見かけないように思う。

最初に挙げた今採用しているスタイルは、Rustのものとだいたい同じで、そう考えると悪くないのかなとも思える。

Luaの記事では、まず問題を提示して、それを解決する過程でLuaの文法や仕組みを解説していくというやり方にしようと思ってる。
必要になるまでやらない、という、ちょっと大げさな言い方をすると遅延評価みたいなやり方。
それはいいとして、「問題1」「問題2」みたいにやってくのだけど、この「問題」ってのは英語ではどうかくのか、しっくりくるのがなかった。
例えば、

• exercise
  
• question
  
• lesson
  
• task
  
• mission
  
• duty
  
• problem
  

といったのが思いついた。
この中で、problemというのは、「問題」に対応する英語としては一番よく使われるものだと思う。
のだけど、何かやっかいなこと、トラブル、障害のような含みが感じられて微妙に違う感じがしていた。
実際に出版されている本ではどうなっているのだろうと思って、Modern C++ Challengeという本を見てみた。
ちょうどPacktのサブスクリプションに入ったところなので、すぐ原著を確認できた。
和訳版では問題1のようになっているのが、そのままProblem 1となっている。
全部Problemだった。
どうもproblemにも課題のような含みがあるみたいだ。
まだ違和感あるけどこれで統一していこう。

pkgの出力を省略せずに貼り付けていったからだいぶ長くなった。
文章はそんなに多くないはず、たぶん。
これで次からやっとプログラミングを始めることができる。
長かった。
最初のページを書いてから18日かかった。

すっごいつまらない回になった。
それもそうだ、ここはadduserをそのまま解説するだけのところなんだから仕方ない。
さくっと終わらせてしまうのが良い。
しかし、すべての項目にいちいち解説を書いていったので、相変わらず長い。
もっと割り切って、操作手順と結果だけというのでも良かった。

朝8時に町内の作業に出て、帰ってから寝てしまった。
何度か起きては記事を進めようとしていたけど、集中できず。
結局、ちゃんと起きたのは深夜になってからだった。
休みを一日無駄にしてしまった。

簡単に手順を示すだけの簡単なページになった。
書きたいことをちゃんと書けていない。
コンパイルに関するちゃんとした知識がないので思うように書けなかった。
一区切ついた感じだ。
とはいっても、まだviのページとか書いてないのでやり終えた訳ではない。
あまり達成感はない。
こんなとこで止まっていても仕方ないので先に進もう。

さっきパッケージをアップデートしたら、evilが含まれていたのでちょっと期待した。
再起動するとやはりエラーは出る。
これいつからなんだろうな。

これで3回目。
もう完治しているような気がするのだけど、次回も予約が入った。

パッケージをアップデートしたら起動にエラーが出るようになった。

Error (use-package): multi-line/:catch: Symbol’s value as variable is void: multi-line-candidate

helmに関係するもののようだ。

もう一つ、以前からだけどorgがロードされるときの(警告？)メッセージが気になる。
こっちは以前からだ。

Auto-evilification could not remap these functions in map ‘org-agenda-mode-map’:
  - ‘org-agenda-next-line’ originally mapped on ‘C-n’
Auto-evilification could not remap these functions in map ‘org-agenda-mode-map’:
  - ‘org-agenda-toggle-time-grid’ originally mapped on ‘G’
Auto-evilification could not remap these functions in map ‘org-agenda-mode-map’:
  - ‘org-agenda-filter-remove-all’ originally mapped on ‘|’
Auto-evilification could not remap these functions in map ‘org-agenda-mode-map’:
  - ‘org-agenda-filter-by-tag’ originally mapped on ‘\’

検索すると2017年頃のかなり古い情報が見つかる。
放置してアップデートで修復されることは期待できない。

良かった。

アクセスすると「Secure Connection Failed」ってなる。
いつからだろう。
不安になるので早く復旧して欲しい。

viとeeの具体的な使い方は別ページにした。
eeだけ書いたらあまりに長くなり過ぎて、同じページに収めると読みにくすぎる。
別ページに分けたので、テキストエディタのページは、だいぶあっさりしたものになった。
まだviが書けていない。
eeでさえこれだけの分量になったので、viをまともにやると大変なことになりそうだ。
必要なものに絞って長くなり過ぎないように気をつかないといけない。
でも、もう先にHello Worldを動かすページの方を書いてしまおうかと思っている。

突然web-modeで「SKK」から「かな」に移行するためのC-jが効かなくなった。
emmet-expand-lineにskk-kakuteiが取られているようだった。
検索してみるとこちらのブログ記事が参考になった。
~/.skkにSKK固有の設定を書けるようだ。
サンプルを見ると、C-j以外にskk-kakuteiを割り当てることが簡単にできる。
サンプルでは変換キー(<henkan>)に割り当てている。
試しにそれでやってみるとかなり良い。
emmet-expand-lineは便利な関数だし、その他のモードでもC-jが使えないのは不便に感じていた。
これらの問題もまとめて解決してくれた。
しかし、変換で確定というのに慣れるまでちょっと掛かりそうだ。
そうするとC-x C-jはもう使わずに変換キーでSKKの切り替えをするようにしたほうが記憶の負担が少ないだろうから、M-変換 (<M-henkan>)にskk-modeをバインドすることにした。

記事書いてるだけで6日間の休みが終ってしまった。
本とかゲームの消化もしたかった。

雨が降ったのできれいになった。
なんとか乗り切れて良かった。

完成していないけど、中途半端なままアップした。
eeとviの二つを1ページに積め込んだので、ごちゃごちゃしている。
別ページにしたほうが良かった。
全体的に1ページの量が多すぎる。
書くのも読むのも大変だ。
もちょっと細かく切っていったほうがいい。

Xの環境でmicroが使えるかどうか試してみた。
公式の仮想マシン用のディスクイメージは空き領域が300MB程度しかない。
xorgは1GB程度必要になる。
VirtualBoxからディスクイメージを追加して、FreeBSDで/usr/localや/varをそのディスクにマウントする、という作業が必要だった。
まずXのデフォルトのターミナルであるxtermを試した。
Ctrl+方向キーなどの組み
しかし、Altキーとの組み合わせがUnicode文字の挿入になっていて、使えない。
micoroではAltキーも多用するのであまり改善されたとは言えない。
rxvt-unicodeも試してみた。
今度はAltキーとの組み合わせは機能するが、Ctrl+方向キーが機能せず全然だめだ。
他にも片っ端からターミナルを試していった。
結果、軽量なターミナルは全滅で、GTKやQtベースのリッチなターミナルでしか完全に機能しなかった。
例えばLXTerminalやxfce4-terminal、Terminator、QTerminalといったものだ。
これをインストールするにはかなり容量を必要とする。
容量自体はそれほど問題ではない。
問題なのはシステムが複雑化してしまうことだ。
たかだかエディタを使うためだけにこの作業を要求するのは酷な気がする。

Xの環境でも軽量なターミナルではCtrlやAltキーの扱いに問題があるとが分かった。
ハードルが一気に上がるが最初から入っているviとeeを使うことにしよう。
nanoは方向キーでも操作できることが初めてでも使いやすいとされる理由でもある。
もしCtrl+方向キーでの単語移動やShift+方向キーでの選択が使えないならその利点はなくなっているように思える。
Ctrl+Xで終了のような奇妙なキーバインドに慣れないといけない。
Xをインストールするのとどっちがハードル低いだろう。
少くともGNOMEのような完全なデスクトップ環境を用意するよりは楽だろう。

まったく何もなかった。
雪かきしたくらい。
去年の元旦は雪積もってたんだろうか。
記憶にない。
1月終りから2月にかけて大雪にだったような。

おそらくこれまでで最も長文なものになった。
org-mode使うようになって段違いに書きやすくなった。
それでも丸2日かかった。
次こそはさくっと終らせたい。