2022年4月の日記

13章の非同期プログラミングは素晴しい内容だった。
Promiseについて、順序を追ってなぜ必要なのか、どのような問題を解決するのかを、詳細かつ明確に解説してくれている。
この章だけでも値段分の価値はある。
今日はたくさん読んだ。
だんだん苦痛が快楽に変わってきた。
良い傾向だ。
あと残すは3章、なのだけど、15章のクライアントサイドと16章のNode.jsの章がやたら長い。
しかし、これまでの章の基礎的なところから一段上って、実際的な内容となるので、きっと面白い内容なのじゃないかと期待している。

やっと済ませた。
朝の晴れているうち終わらせた。

クラスとモジュールの章。
クラスの構文が追加されたことは知っていた。
それは従来のプロトタイプを基礎としたもののシンタクッスシュガーであることも理解していた。
ちゃんとした、まとまった解説を読むのは初めてだった。
あやふやだったイメージが固まって、少し定着したような気がする。
モジュールの章は短かかった。
ほとんど初めて耳にする情報だった。
Node.jsのexportは触ったことがあったが、理解はしていなかった。
Node.jsにはES6で追加されたimport/exportと、従来のrequire/exportが混在するという厄介な状況になっている。
Webでは <script type="module>...</script> というタグを書くようだ。
どういう効果になるのか、書かれてはいるのだが、試してないので身に付いていない。

コントロールパネルに「Inodes Used」という情報がある。
これが「100% (32041/30000)」となっていた。
ファイルとディクレトリの数に制限があって、30000を越えるとそれ以上ファイルとディレクトリを作成できなくなるらしい。
なんでこんなに増えてしまったかというと、昨日インストールした4つのWikiが原因なのは間違いない。
4つのWikiをインストールしただけで超過してしまうというのはなかなか厳しい制限だ。
インストーラーでアンインストールしようとすると、inode数の超過が原因で起動しない。
仕方なくファイルマネージャーから手動でディレクトリを削除した。
しかし、コントロールパネルに反映されない。
inodeのカウンターは1日1回しか走らないようだ。
数時間で走るという情報もあったが、待ってみても更新されてなかった。

更新された。
「19% (5819/30019)」となっていた。
上限が30019と19増えているのは謎。
せっかく色んなアプリがインストールできるようになっているのに、この制限のせいで気軽には試せないのは残念。

明日から5月6日金曜日まで。
欲を言えば、5月6日も休みにして10連休にして欲しかった。
特に予定はないのだが、やっておきたいことはある。

• 掃除、整頓
  
• 本を少くとも2冊読み終えたい: Learning Boost、JavaScript 7th
  
• 記事のマリオを完了させる
  

ゲームもやりたい。

electric-pair-modeが悪さをしていることが多いようだ。
Odinのときもそうだった。
今回はJavaScript。
無効にしておいた。

(add-hook 'js2-mode-hook (lambda() electric-pair-mode -1))

これで直った。

• 参考 (Stack Overflow)
  

関数の章。
ここはなかなか面白かった。
関数型プログラミングのスタイルの例が挙げられていた。
「このスタイルを奨めているわではない」と注意書きが2回あった。
JavaScriptの関数はこういう面白いことができるということを示すためだけに書いた、ということだ。
この方針には完全に同意する。
以前「JavaScriptで学ぶ関数型プログラミング」という本を読んだ。
Underscoreというライブラリを使ったもので、確かに面白いのだけど、実用的かというとそうでもないように感じた。
楽しみや頭の体操のためにやる程度に止めておくのが得策だろう。

Heroku以外にもいくつあるようだ。
特に無料で利用できるのでは、Glitchというのが一番手軽そうだ。
ビジネス向けには厳しそうな感じなのだが、トレーニングや楽しみが目的なら良さそう。
AWSやAzureやGoogle Cloud Platformは大掛りすぎる。
ただ何となくやるには向いていない。
必要に迫られてからやったほうがいい。
他にも「node.js hosting」とか「node.js hosting free」で検索すれば良さそうなの見つかる。

今利用している InfinityFree では大量のアプリケーションが簡単インストールできるようになっている。
そのうちWikiは4つあった。

• DokuWiki
  
• MediaWiki
  
• PmWiki
  
• WikkaWiki
  

全部PHPで書かれているものだ。
DokuWikiが良さそうだけど、試してみたくて4つともインストールしてみた。
以前使っていたのはMoinMoninというので、PythonでWSGIを使用するためか用意されていない。
加えて、Wiki用にサブドメインを作った。
SSLもセットアップした。
サブドメインごとにセットアップしないといけないっぽいのは面倒だ。
サブドメインは他にもブログ用のものも用意しておいた。
InfinityFreeは、速度が遅いのといくつか厳しい制限があるものの、機能は無料とは思えないくらい豊富だ。
サブドメイン、SSL、MySQLデータベースは無制限だし、一つのアカウントで3つまでホストを作成できる。

codepenからvscodeにシフトしている。
さらにNode.jsのアプリケーションになっている。
Node.jsは、作成したものを費用をかけずに気軽に公開する方法にはどうすればいいかということがよく分かっていない。
PHPが使える無料ホスティングサービスは結構あるのだが、Node.jsはほとんど見かけない。
一応はHerokuのFreeプランが使えそうだ。
Herokuは単なるホスティングサービスではなく、何やら高度な仕組みになっていてよく分からない。
特に料金の仕組みが分からない。
とりあえずFreeでやってみて、理解していくという方がいいだろう。

VSCodeといえばちょっとした問題を抱えている。
Ctrl+Oとか、あるいは新規ファイルでCtrl+Sとかしたときに表示されるダイアログが前面にこない。
どうなるのかというと、エディタ本体の後ろに隠れているので、表示されたことが分からない。
Alt+TABでいちいち切り替えないといけない。
非常に煩わしい。
どうなおせばいいのか検討がつかない。

インライン入力されなくなっていた。
設定のアドオン「Fcitx XIM Frontend」を設定し直しても直らない。
ディレクトリ ~/.config/fcitx を削除して再起動すると直るという情報があったので、やってみた。
結果、直った。
辞書とかキーバインドとか全部消去されるだろうが大したことしてないので、気にしないでおく。

配列の章だった。
かなり衝撃的なことが書かれていた。
それにしても、JavaScriptの学習は苦痛だ。
ばらばらにちらばった情報をかき集めて詰め込んでいるだけのような感じだ。
JavaScript自体はそんなに退屈な言語だとは思わない(奇妙な言語だとは思うが)。
今の時代においてJavaScriptを知らないというのはまずい。
Cを知らないのと同じくらいまずい。
そんな認識なので苦痛に耐えて学習している。
「Vue.js Quick Start Guide」は2章まで読んだ。
なんかBootstrapも覚えないといけなそうな雰囲気が漂っている。

なかなかの苦痛を伴う。
このまま続けるのは苦痛過ぎるので、別のことを交えながら進めることにした。
以前から気になっている、フロントエンドと呼ばれる領域のフレームワークを鎮痛剤として服用することにした。
React、Angular、Vue.jsがその代表格だ。
まずはVue.jsをやってみることにた。
Packtから初心者向けのを探してみた。
「Vue.js 3 By Example」というのを開いてみた。
ちょっと難しかったので別のにした。
「Vue.js Quick Start Guide」が分かりやすいので、これで進めることにした。
Vue3じゃなくて、Vue2なのが惜しいけど、気にしないでおく。

公式のドキュメントOverviewを読んでいた。
結構長かった。
やっぱりGoをやってるのに近い感触だった。
deferや型の宣言やスライスやマップなどはGoに酷似している。
いくつかGoや他の言語にはない注目すべき特徴も備えている。

• 基本型にcomplex、matrix、quaternionがある。
  組み込みの演算もある。
  
• Array Programmingが可能。
  
• Cの関数をインポートするための手段が扱い易い。
  
• 型のパラメータ化によるジェネリックプログラミングのようなことも可能。
  
• コンテキスト
  
• SDLやRayLibといったサードーパーティーのライブラリのバインディングが付属している(Batteries Included)。
  

特に目立ったのはこのくらいだろうか。
逆にGoにあってOdinにないものもある。

• goroutine
  
• メソッド
  
• インターフェイス
  
• GC
  

際立っているのはこのくらい。
あまり不便はないようにも見えるが、この差はなかなかでかい。
言語そのものではないものの違いは、ドキュメントやコミュニティがGoほど充実していないという点も挙げられる。
それは当然で最初から分かっていることなので不満なわけではない。
ドキュメントがないのはソースコードを読んで補うことになる。

Odinのコンパイラはodinというコマンドが担当している。
このodinというツールは、ただコンパイルするだけでなく、ビルドやテストも受け持っている。
Goのgoツールのような感じだ。
それならMakeのようなのを使わなくてもいいかなと思って、Spacemacsのprojectileのみで完結できないか模索してみた。
しかし、思っていたより万能ではなく、やはりMakeを使うことにした。
Makeを使うと、projectileの設定はほぼ不要になった。
Makefileは次のように落ち着いた。

コピペする場合、インデントは空白をTAB文字に置き換えないといけない

PROJECT_NAME = overview
ODIN = odin
ODINFLAGS =
BINDIR = bin
BINPKGS = example1 example2 example3
TARGETS = $(addprefix ${BINDIR}/,${BINPKGS})
LIBPKGS = foolib
TESTDIR = tests
TESTS = $(wildcard ${TESTDIR}/test_*.odin)

define MAKE_PACKAGE
$1: $(wildcard $2/*.odin)
    ${ODIN} build $2 ${ODINFLAGS} -out:$1
endef

.PHONY: all
all: ${TARGETS}

.PHONY: clean
clean:
    ${RM} ${BINDIR}/*

$(foreach t,${TARGETS},$(eval $(call MAKE_PACKAGE,${t},$(t:${BINDIR}/%=%))))

.PHONY: unittest
unittest:
    @cd ${TESTDIR}; ${ODIN} test .

もちろん毎回こんなの書いてられないので、スクリプトにしておいた。
プロジェクトに複数の実行ファイルを含めることができるようにした。
BINPKGというのに手動で名前をセットして、同名のディレクトリ以下にそのソースを置くようにすると、自動でビルドされる。
ライブラリは、あまりよく分かってないのだけど、Odinではビルドせずに、そのままソースをimportするようになっているようだ。
一応テストは走らせられるようにしておいた。
core:testingというライブラリがあるので、それを使ってテストコードを書けば良い。
原始的な感じだがこれでいってみようと思う。

Makefileの参考にしたページ

• wildcardを利用したシンプルな汎用Makefile
  
• Makefile の関数一覧
  

初めて自分のレイヤーを書いた。
といっても大したことはしてなくて、odin-mode.elをロードするようにして、いくつかしょぼい関数を書いただけだ。
何かレイヤーを書くの敷居高いなあ、と思ってたけど全然そんなことはなかった。
もちろん広く使われるものを書くのは、かなり大変そうだし、労力がいると思う。
プライベートなレイヤーの書き方は、この辺り(Spacemacs)を読めば良い。
あるいは SPC h SPC layers RET でも読める。

水が止まらなくなった。
元栓を止めた。
明日直しに来てもらえる。

FFみたいって前書いたけど、興味が沸いてきたので触ってみることにした。
Elixirは、Dave Thomasの「プログラミングElixir」という本で知名度を一気に上げた。
去年第2版を購入してある。
分類としては関数型の言語になると思うのだが、実践的な言語ではないのかと想像している。
Crystalは、Rubyに似た構文を持ち、型付けのある言語だ。
過去に何度か検索結果に上ってきたことがある。
妙に日本語のドキュメントが充実している。
プロジェクトあるいはパッケージ管理のためのツールshardsというのが用意されていて、開発環境は構築しやすい。
以前ちょっとだけ触って気になったのは、コンパイルが遅すぎる、とうことだ。
ありえないくらい遅い。
ここ(公式)のHTTPサーバーのサンプルをビルドすると、5秒近くかかる。
PCのスペックが低いせいだろうか。
今使用しているのは、最新のハードではないが、普通にLinuxのデスクトップ環境として使う分には不満がない程度のもの。
しかし、要求を満たしていないのかもしれない。
そろそアップグレードしたくなってきた。
Odinはあまり知られていないのではないかと思う。
Goに似た構文や特徴を持っている。
この言語を知ったのは、RayLibのバインディングの一覧を見ていて目に止まったからだ。
RayLibやSDLといったものは添付されていて、一緒に付いてくる。
割りとゲームと相性良いかもしれない。
見た目はかなり普通のコードで、さほど目新しさは覚えなかった。

原因はまずEmacsのバージョンが27.2から28.1に上ったためと考えて良いだろう。
メッセージは次のようなものだ。

Error (use-package): helm/:config: Symbol’s value as variable is void: \213 Disable showing Disable logging

何をすればいいのか検討がつかない。
おそらく早い内に修正されるのではないかと期待している。

あとorgをロードするときに、*.el.gzを展開する処理が入り、数秒待たされるようになった。
メッセージには次のような出力がある。

uncompressing gnus-group.el.gz…done
uncompressing gnus-start.el.gz…done
uncompressing gnus-int.el.gz…done
uncompressing nnselect.el.gz…done
uncompressing eieio-opt.el.gz…done

メッセージ自体は問題ないのだろうが、待たされるのが困る。

ArchのGTKベースのアプリケーション、例えばGeanyなどのツールバーのアイコンが表示されない問題。
GTKはデフォルトではAdwaitaというアイコンテーマを使用する。
/usr/share/icons/Adwaita というのは存在している。
しかし、その中に肝心のアイコンイメージファイルがない。
もちろんAdwaitaのパッケージである adwaita-icon-theme はインストールしてある。
ちょうどGTK3からGTK4に切り替わる時期で、そのため何かおかしなことが起きていると推測する。
てっとり早い対策は、別のアイコンテーマを使用するようにすることだ。
ただ、GNOMEやXfceを入れていないので、設定ツールがない。
手動で設定ファイルを書く必要がある。
まず、適当なアイコンテーマをインストールする。
pacman -Ss -- -theme あたりで検索するといくつかヒットするので適当に一つ選ぶ。
今回は、deepin-gtk-themeとdeepin-icon-themeをインストールした。
設定は、ここ (ArchWiki)を参考にして、次のように書いた。

[Settings]
gtk-icon-theme-name = ePapirus
gtk-theme-name = deepin

ePapirusって何なの、というと、deepin-icon-themeでこれも一緒に入ってきた。
GTK2に対してはまた別の設定が必要になるけど、特に問題は発生していないのでやらなかった。
一応これでGeanyやBluefishやRistrettoといったアプリケーションのツールバーのアイコンが表示されるようになった。

rebaseの章。
rebaseはコミットの履歴、特にマージコミットを省くことで、履歴をきれいにするために、使うというのが主目的だと書かれている。
絶対にやってはいけないことがある。
公開リポジトリにプッシュしたコミットをリベースしてはいけない
これさえ守れば極度に恐れる必要はない。
あとはamendとcherry-pickについて書かれていた。
amendは、特に慣れないうちは間違ってコミットすることも多そうなので、使う機会も多そうだ。
cherry-pickは、あまり使わないかもしれない。

といっても、第8章と第9章は流しただけになった。
hocのコードは第2段階までは書いていた。
しかし、yaccの記法がいまいち分からなくて、意味不明なまま残りの全部を打ち込む気になれなかった。
また、練習問題も最初からすべてスキップしていった。
そのせいで全体的にあまり実りがあったという感触がない。
あと2週回すつもりでいる。
次は練習問題もやっていく。
良い本なのは間違いないので、きっちり理解しておきたい。

Git for Programmer という本を読んでいて、GitHubが使えないとどうにもならないので使えるようにした。
いつの間にかプライベートなリポジトリも作れるようになっている。
訓練用のリポジトリを公開するのは無駄でしかないので、これは都合が良い。
ブランチの扱い方、マージのときのコンフリクトの解決方法と、Pull Requestのやり方までを学習した。

7章のspnameというやつに苦戦した。
記述が古く、openとreadでディレクトリを読んでいたりする。
この手法は使えない。
opendirとreaddirを使うべきだ。
あと static FILE *tty = fopen("/dev/tty", "r"); というのようなのがあって、staticが原因で、Bad file descriptorのエラーが発生していた。
見つけるのに時間かかった。
この本ではせっかくなのでテキストエディタにedを使っている。
だいぶ自由に、思うように編集できるようになってきた。
この本でしか使うつもりはないので、あまり意味はないのだけど、色々やってみるのも楽しい。

久しぶりに見た。
めっちゃ明るい。

式と演算子。
知らないことが多く書かれている。
知っていることは言わばCとの共通部分であるからというただそれだけだ。
本気でJavaScriptを使うなら、全てが身に付いていないとだめなのだろう。
細かいことは知らなくて大丈夫というわけにはいかない。
ただ、まだ本気でWebプログラミングをやるかどうかは迷っている。

疣の治療。
何回目か忘れた。
塗り薬を使ってみませんかと言われたけど、やめておいた。
通い始めてもう4ヶ月経つ。
まだ直ってないのだろうか。
見た目にはもう大丈夫そうなのだが。

思ってた通りめっちゃ基礎的な内容だった。
けど思ってたより読み易く、退屈なものではなかった。
十分に通して読めるものだ。
それにしても、あちこち本に手を広げすぎかなと思う。
本当なら一冊ずつ消化していった方が効率が良いのだろう。

色々試している。
SciTEから乗り換え。
HowlもLuaで拡張できるのだが、さらにMoonScriptも使える。
LuaもMoonScriptも大好きなので、使わざるを得ない。
GUIはかなり限定的だ。
メニューバーがないし、マウスのメニューもない。
一見コンソールのテキストエディタではないかと見間違うほどだ。
コマンドモードやファイル名の補完の機能が強力で心地良い。
あとひとつ気に入った機能が、プロジェクトのファイルを開くというやつで、.gitのあるディレクトリをプロジェクトのルートして認識してくれる。
Ctrl+Pでそのディレクトリ以下にあるファイルからファイルを素早く開ける。
これも快適で心地良い。
今ひとつなのが、新しいファイルというかバッファを作成して保存しようとしたときの挙動だ。
カレントディクレトリが現在のバッファのディレクトリとなるのだが、新しいバッファには当然そのようなディレクトリはなく、ホームディレクトリから指定してやらないといけなくなる。
そうではなく、直前のバッファのディレクトリから、あるいはプロジェクトのディレクトリからにして欲しいものだ。

EasyOSっていうのはLinuxのディストリビューションで、変なロゴが気になって使ってみたくなった。
イメージはimgフォーマットで配布されているので、VirtualBoxで使えるようにするには、変換する必要がある。
変換はVirtualBoxのツールで簡単にできる。

VBoxManage convertdd easy-3.4-amd64.img easy-3.4-amd64.vdi

このイメージは、単なるインストーラーとかLive CDのような位置づけではなく、USBメモリからそのまま利用することが想定されている。
なので、インストールせずとも(することもできる)そのまま使えるようになっている。
これがVirtualBoxで使う場合には逆に足枷になる。
起動すると空容量が数MBしかなくて、ファイルを作ることができない。
echo hello >hell.txt のようにしても失敗する。
ディスクのサイズを変更してやる必要がある。
VirtualBoxマネージャーから簡単にできる。
EasyOSからは、GPartedが最初から用意されているので、それを使えば簡単に既存パーティションを拡張できる。
EasyOSの使用感は、かなり意味不明だ。
ドキュメントをちゃんと読んで理解しないと快適に使うのは難しいだろう。
「Easy」というのは使い方が簡単という意味ではない。
熟練者にとって遊び感覚で構えずにいじくり回せるという意味合いだろう。
初心者には結構難しい。
扱いは難しそうなのだけど、デスクトップの垢抜けない、洗練されていないデザインとかが大好きなので、インストールして使ってみたい。

グラフィカルログインから入ろうとすると「失敗しました。もう一度試してください。」となる。
Ctrl+Alt+1などの仮想端末からログインしようとしても失敗する。
別ユーザーで試してみる。
Solusは、デフォルトでrootではログインできないようになっている。
いつも使っているユーザーとは別に、全く使用していないユーザーアカウントが作成してあったので、それで試す。
グラフィカルログインはできないが、テキストログインはできる。
そこからsuでいつものユーザーに切り替えようとすると、失敗する。
しかし、メッセージが表示されてヒントになった。
「libncursesw.so.5が見つからない・ロードできない」といったようなメッセージだった。
/usr/lib64辺りを探してみると、libncursesw.so.6はあるのだが、確かに5はない。
ここで一旦中断。
帰ってから、ncursesでパッケージを検索すると「ncurses5」というのが提供されていて、インストールされてなかった。
これをインストールしてみたいのだが、臨時で使っているユーザーはsudoの権限を与えていなかった。
何か手はないかを考えて、このPCにはLinux OSが3つ入っている。
別のOSからこのOSのディスクをマウントして、そこで/etc/sudoersを書き換えてしまうことにした。
うまくいった。
臨時ユーザーでsudoできるようになった。
そして sudo eopkg install nucrses5 を実行した。
うまくいったようで、いつものユーザーでグラフィカルログインもテキストログインもできるようになった。
今回はたまたま作成しておいたユーザーでテキストログインできたから助かった。
もしだめだったら詰んできた。
もちろん、Linuxに詳しい人なら別の解決策が取れるのだろうけど、初心者の自分には無理だったかもしれない。

ところどころ意味不明な箇所があるものの、技術的にはさほど高度なことはやっていない。
この本は技術を学ぶというよりも、考え方を学ぶ本だといえる。
一回読んだだけでは身に付かないだろう。
何度か繰り返す必要がある。
練習問題は全部スキップしている。
真剣にこの本の内容をマスターしたいなら、全部やらないとだめだろう。
しかし、一周目でそれをやっていたら、時間が掛かり過ぎて、確実に中断放置に入るだろう。
まずは読破することを優先する。

IceWM以外にもウィンドウマネージャーを色々試していた。

• ctwm
  
• herbstluftwm
  
• blackbox
  
• fluxbox
  
• openbox
  
• jwm
  
• pekwm
  
• windowmaker (AUR)
  

Windows 95風のウィンドウマネージャが欲しい、という目線だとIceWMが一番近い。
jwmはIceWMよりさらに軽量で、機能も削られている。
使い方は直感的で良い感じだ。
多くを求めないなら、選択しても良い。
box系はどれもちゃんと設定しないと、素のままだとデスクトップの右クリックメニュー以外ほぼ何もない。
ctwmはtwmの改良版といったところだろう。
herbstluftwmという覚え難い名前のも、twm系なのだが、使い方が意味不明だ。
チュートリアル man herbstluftwm-tutorial が付いているので必読となる。
pwkwm、WindowMakerはこの中ではより個性が強く多機能で実用的だ。

InfinityFreeっていうのは、今使っている無料のWebホスティングサービスのこと。
3月くらいまでは、日本のStarServer Freeというのを使っていた。
InfinityFreeは、無料プランでもSSLが使えるので、移動することにした。
使ってみて最初に戸惑ったのは、ページを更新してアップロードした後、アセクスしても古い内容のままになっていたことだ。
Webブラウザでリロードすれば、新しい内容が表示される。
キャッシュが関係している疑いが大だった。
StarServerの方ではこんなことはなかったので、残念な気持ちでいた。
フォーラムを検索してみると、同じことに引掛っている人を発見した。
対策も書かかれていた。
.htaccessでキャッシュをしないようにしてしまうことだ。
無理やり感があるが、試してみるとうまくいったので、これで良しとしよう。

新しくインストールした。
といってもVirtualBoxだけど。
インストールは、基本的にはインストールガイドの通りやった。
いくつか嵌ったことがある。

• dhcpcd をインストールしておくこと。
  デフォルトではインストールされない。
  インストールしておかないと、面倒になる。
  起動後にインターネットにアクセスできなくなってパッケージの取得もできなくなる。
  
• grubを使う場合、grub-installだけでなく、grub-mkconfigもやっておくこと。
  
• GuestAdditionはISOからインストールする必要はない。
  pacmanで virtualbox-guest-utils (もしくは、nox版) をインストールすれば良い。
  vboxservice.service を有効にしておく。
  そうしないと、フォルダ共有やファイルマネージャーが使えない。
  

色々あるけど主にこのくらい。

デスクトップは、最初awesomeというウィンドウマネージャーを試した。
VirtualBoxを使っていることが原因だろうけど、何かちょくちょくフリーズして強制電源OFFにするしかできなくなる現象が発生したので諦めた。
次は、IceWMを使ってみた。
テーマをいじったりしていたら1日過ぎてしまった。
まだまだ遊べそうだ。

一つ厄介な問題があって、ゲストを起動したままサスペンドから復帰すると、固まって強制電源OFF行きになる。
毎回ではなく、どうも放置して自動サスペンドになった後に発生しやすいようだ。
FreeBSDでは発生しないので、VirtualBox固有の問題というわけではなさそうだ。

さくっと終わらせてきた。
前回8月のときは、次の日熱がでた。
何もなければ良いのだが。

2台分やった。
いつもは4台やらないといけないので、それに比べれば楽なもんだった。

Shortwaveとは、インターネットラジオのアプリケーションで、使い方がめっちゃ簡単で、検索が便利で気に入っている。
なのだけど、なんか頻繁に切断される。
スタンバイから復帰したときなどは確実に切断される。
それだけならまだ許容できるけど、普通に再生しているだけでも切断されることがある。
一旦切断されると、Shortwaveを起動し直さないといけない。
とりあえず代用として、Clementineというのを使っている。
Clementineは音楽プレイヤーで、ラジオが専門という訳ではない。
そこそこチャンネルが用意されていて、ラジオプレイヤーとしてもまずまず使える。

CでGTK+をぽつぽつ書いていてどうにもGObjectを理解していないと厳しい感じがしてきた。
ここで少し時間をとってちゃんとやってみることにした。
検索してみると、ここ(GitHub)が見つかった。
サンプルを交えながらの解説で、素晴しく分かりやすかった。
GObjectの理解は少し進んだけど、最終的にはGTK+はCではやらないだろうなと思う。
Valaが一番良さそうだ。
JavaScriptも興味深い。

やっぱりGUIのプログラングは楽しい。
Webにサンプルが色々見つかるので、かたっぱしから試している。
1ファイルで完結するプログラム用にCMakeを書いた。

cmake_minimum_required(VERSION 3.14)

project(HelloGTK)

set(CMAKE_BUILD_TYPE Debug)
set(CMAKE_C_FLAGS "-Wall")
set(CMAKE_C_FLAGS_DEBUG "-g -Wall")

find_package(PkgConfig REQUIRED)
pkg_check_modules(GTK REQUIRED gtk+-3.0)

file(GLOB srcs "*.c")
list(FILTER srcs EXCLUDE REGEX ".*-nolink\\.c$")

foreach(s ${srcs})
  get_filename_component(program ${s} NAME_WE)
  add_executable(${program} ${s})
  target_include_directories(${program} PRIVATE ${GTK_INCLUDE_DIRS})
  target_link_libraries(${program} PRIVATE ${GTK_LIBRARIES})
endforeach()

ポイントはfind_packageでPkgConfigをロードして、さらにpkg_check_modulesでGTK3を拾っているところ。
GTK2まではfind_packageが使えるようだけど、3からはなくなっている。
pkg-configのGTK3が使えるので、それを利用している。
サンプル実行のためにGeanyを久しぶりに使っている。
適当なプログラムを実行するには、やっぱり使いやすい。
不満はソースを一つ追加するたびにCMakeを走らせないといけないことくらい。

パッケージマネージャー(Solusの場合eopkg)でwxWidgets(wxwidgets-devel)をインストールした場合、ヘッダは /usr/include/wx-3 以下に配置される。
ここだけならまだ良いが、内部で利用するsetup.hというヘッダもまた別にある。
リンクするべきライブラリの数も多い。
こういうライブラリを利用するときの便利な手段として、pkg-configがある。
wxWidgetsはpkg-configの設定を提供していない。
代わりにwx-configというのを使う。
bashなら次のコマンドでビルドできる。

$ g++ -o HelloWx HelloWx.cpp `wx-config --cxxflags --libs std`

fishの場合evalを使って次のようにしないといけない。

$ eval g++ HelloWx HelloWx.cpp (wx-config --cxxflags --libs std)

これでコンパイル・リンクと通って、実行可能ファイルが手に入るのだが、問題が発生した。
HelloWxを実行すると、次のような警告が表示される。

$ ./HelloWx
17:52:18: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1016,wx containers,compatible with 2.8).

システムにインストールされたライブラリのビルドに使われたABIのバージョン1014と、今ビルドしたHelloWxのABIのバージョン1016が異なることを警告している。
これが本当に問題になるのかどうかは知らない。
警告が出ないようにするには、HelloWxをコンパイルするときにABIのバージョンを指定してやる必要がある。

$ g++ -o HelloWx HelloWx.cpp -fabi-version=14 `wx-config --cxxflags --libs std`

今、1014にしたいので -fabi-version=14 というオプションを付けてやった。
これでHelloWxを実行すると警告は消える。
しかし、こんな環境依存なオプションを付けないといけないのは好ましくない。
良い方法はないのだろうか。

CMakeの場合、find_packageが使える。
ABIのバージョンを指定するには add_definitions(-fabi-version=14) のようにする。
参考 (stack overflow)

最近調子が良くない。
気晴らしに、GUIライブラリで遊んでみることにした。
まともに使ったことのあるのはQtくらいしかない。
まずFLTKとwxWidgetsをインストールした。
FLTKは簡単に使える。
Qtのような巨大なものではないので、気軽にインストールできる。
wxWidgetsも、Qtよりは軽量だが、アプリケーションのビルドはちょっと面倒そうだ。
今日はやらないでおいた。
もうひとつ気になっているのはU++といういうやつ。
あまり有名ではなさそうだけど、名前が面白いので使ってみたい。
と、そこそこ遊んでから、生のXをやってみることにした。
適当にサンプルを動かしてみた。
コードはあまり楽しそうなものではない。
あとGTK+も使えるようになっておきたい。

典型的な使い方は、std::pairやstd::tupleを返す関数の戻り値を、変数にバインドすることだろう(unpack)。
C++17では構造化バインディングがあるので、その用途での出番は少くなったかもしれない。
今日知ったのは、比較演算子と合わせて使う方法。

bool operator<(Person const &p1, Person const &p2) {
  return std::tie(p1.a, p1.b, p2.c) < std::tie(p2.a, p2.b, p2c);
}

このようにすると、

• aが等しい場合はbでの比較へ、そうでない場合はaの比較の結果
  
• bが等しい場合はcでの比較へ、そうでない場合はbの比較の結果
  
• cが等しい場合はfase、そうでない場合はcの比較の結果
  

となる。

参考 (cppreference.com)

コンテナの章。
かなり良かった。

Boost.Assignは手軽に使えそうだ。
list_ofやmap_insertなどを使うときにちょっと困ることがある。
clang-formatで良い感じにならない。
例えば、次のようなのがあったとする。

auto map_init = boost::assign::map_list_of
                (0, boost::rational<int>{1})
                (1, boost::rational<int>{1, 2})
                (2, boost::rational<int>{1, 6})
                (3, boost::rational<int>{0})
                (4, boost::rational<int>{-1, 30})
                (5, boost::rational<int>{0})
                (6, boost::rational<int>{1, 42})
                (7, boost::rational<int>{0});

clang-formatは、これを次のように整形する (googleスタイル)

auto map_init = boost::assign::map_list_of(0, boost::rational<int>{1})(
    1, boost::rational<int>{1, 2})(2, boost::rational<int>{1, 6})(
    3, boost::rational<int>{0})(4, boost::rational<int>{-1, 30})(
    5, boost::rational<int>{0})(6, boost::rational<int>{1, 42})(
    7, boost::rational<int>{0});

コメントで / clang-format off/on を使ってその部分だけ無効にすることはできる。
しかし、注意力が削がれるし、見苦しいのでやりたくない。
ここ (stack overflow)にちょっとした技が紹介されていた。
改行を挟んで欲しい位置にコメント / を置けば良い。

auto map_init = boost::assign::map_list_of  //
    (0, boost::rational<int>{1})            //
    (1, boost::rational<int>{1, 2})         //
    (2, boost::rational<int>{1, 6})         //
    (3, boost::rational<int>{0})            //
    (4, boost::rational<int>{-1, 30})       //
    (5, boost::rational<int>{0})            //
    (6, boost::rational<int>{1, 42})        //
    (7, boost::rational<int>{0});

これならまだ許容できる。

コンテナでは、特にptr_containerに注目したい。
以前書いたブロック崩しでは生ポインタでやっていた。
知っていたら使っていただろう。
練習のため書き直してみるのもいいかもしれない。

Escで遅延が発生する。
コマンドモードやシェルモードをキャンセルするためにEscを押しても、すぐ抜け出ない。
0.5秒くらい。
体感できるくらいの間隔だ。
tmux上ではなく、通常のターミナルではすぐに反応する。
また、vimなどは普通にEscは普通に即反応するので、microだけ発生するようだ。
この現象抜きにしても、tmuxとmicroは微妙に相性が良くない気がする。
操作に統一感がなさ過ぎて違和感を感じる。
vi系統の方がtmuxとは相性が良いように思える。

microの代わりになるのがないか探している。
Kakouneというのが面白い。
Vimを基本としつつも、独特な操作になっている。
ただ、もうこれ以上真剣にキーバインドを覚える気になれない。

コンソール用じゃないけど、liteというのが面白い。
GUIのアプリケーションだけど、メニューなどが一切ない。
コマンドから機能にアクセスするようになっている。
Luaで書かれているそうだ。
liteはあまり活発に開発されていなく、lite-xlというのにシフトしているようだ。

どうもibusとの関係が悪いらしい。
日本語入力にはfcitxを使っていて、ibusは全く使用していない、はず。
ibusのパッケージをアンインストールしようとすると、多くの依存パッケージが削除されてしまう。
例えば、Budgieのようなデスクトップ環境まで削除されてしまう。
全然だめだ。
検索して見つかった対策をいくつか試した。
ibusのプロセスをkillするというのは効果があった。
他はだめだった。
いちいちログインするたびにkillするのは面倒だ。
修正されるまで、しばらくTerminatorは使わないでおくことにする。
別のターミナルを探してみる。
あるいはtmuxの使い方を覚えるか。

ターミナルはとりあえず今インストールされているAlacrittyを使うことにした。
Alacrittyには画面の分割やタブといった機能は一切ない。
tmuxを使うことは必須になる。
早速tmuxを使ってみることにした。
基本的な使い方は難しくない。
キーバインドがEmacs風で覚えやすい。
ひとつ困ったことがあって、microでCtrl+方向キーやShift+方向キーが使えない。
いくつか対策を試した。
一つ目は次のようなものを ~/.tmux.conf に書いてみた。

set -g default-terminal "xterm-256color"
set-window-option -g xterm-keys on

参考

xterm-256colorの設定がないとうまくいかなかった。
tmuxを起動したとき、TERMはscreenに設定される。
それを強制的にxtermに変えないと、xterm-keysにパスしない。
tmuxを使っているのに、xtermにするのは気持ち良くない。
そこで ~/.tmux.conf に次のを書いて試してみた。

set -g default-terminal "tmux-256color"

参考

これもうまくいく。
さらにxterm-keysをセットしなくてもいいので、気持ち良い。

良さそうだったのだけど2点小さなことが気になったのでやめておいた。

• 例えば、Luaのディレクトリに入ったときにstarshipで表示される 🌙 のフォントがいい感じにならない。
  

• microで編集中に、マウスカーソルがShiftを押すたびに矢印からキャレットに変化して気が散る。
  

  解決策が見つからなかった。
  gnome-terminalを使うことにする。
  tmuxを使うなら特に不便なことはない。
  

MoonScriptとLÖVEでpongを作ってみた。
何かボールが動き回るときにかくかくしているというか、ちらつくのが目立ったので調べていた。
原因はディスプレイのリフレッシュレートにあった。
2枚ディスプレイが繋げてあって、メインの方は75Hz、サブの方は60Hzとなっていた。
75Hzの方を60Hzに変更したら期待通りになった。

LÖVEはデフォルトではvsyncがONになっている。
この場合75FPSで更新されるようになる。
love.updateやlove.drawが大体0.01333..秒間隔で実行される。
60FPSなら0.01666..秒間隔となる。
しかし、これはLÖVEの問題ではなく、単純にディスプレイの問題のようだった。
メインを75Hzの状態にして、75FPSでプログラムを走らせたウィンドウを、60Hzの方のディスプレイに持っていく。
すると、なぜかちらつきはなくなる。
vsyncをOFFにしてやっても、75Hzのディスプレイではやはりちらついて、60Hzの方はちらつかない。
よく分からない。

raylibのfpcバインディングを試していた。
fpcにはfpというコンソールのIDEが含まれる。
ひとついまいちなことがある。
エディタの背景に青が使われるのだが、ターミナルのカラーパレットを変更しているとすこぶる違和感のある配色になる。
青は多くのデフォルト設定でlsのディレクトリの色などに使われるようになっていて、濃過ぎて黒背景だと見難い。
だから、だいたい青は変更している。
あるいはプリセットから変更されたものを選択している。
そんなどうでもいいようなことに気を取られていて、特に成果はなかった。

Stack Overflow のデザインがレトロになっている。
4月1日だけなのだろうか。

フィルタの章。
基本に忠実。
目玉はsedとawkのイントロダクション。
フィルタとしての利用を重視したもので、本格的なプログラミングを行うものではなかった。

Vulkanの続きなのだけど、あまり読む気がしない。
前章までで少しコードを書いたが、かなり時間をかけてトレーニングをしないと使えるようになる気がしない。
難解すぎて意欲が薄れてしまったので、今じっくり読んでもあまり身に付かないだろうと思い、流しておいた。
のこり2章あるが同じように流しておくことになるだろう。