Notices by きゅーけー (tojoqk@mastodon.tojo.tokyo), page 266

なんかダッシュボードとか見れていい感じ

Nextcloud を 20 系のバージョンにアップグレードした。

Time Requiem の CD を買ってしまった。

過去のトゥートがブーストされるとまだ media がオブジェクトストレージにアップロードしきっていないことを実感する。

Vikalpa の develop ブランチのやつはどうせ force push されて消えるコミットなのでいいか……。

あー、過去に unverified になっちゃったやつは登録しても駄目なのかな。

あれ、なってない。なんで。

これで全て Verified になったはず

署名用の副鍵を作ったときに GitLab の公開鍵を設定し直すの忘れてた。

Common Lisper は外部から送られてきた S 式を安易に read してはならないのだ……。*READ-EVAL* に nil を設定しない限りは……。

Guile ならどうせあるだろうという推論が当たってしまった。正直 read-eval はこの世になくていいと思ってるけど……。まあ、デフォルトがオフで本当によかった。

read-eval? がデフォルト off で存在していてくれていてむしろ良かった。機能として存在していなかったら、この存在がないことを確認する必要があったので逆に辛かった可能性もある。https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/boot-9.scm#n2220

read-eval? あったし！でもデフォルトは off っぽい。

ドキュメントを見る限り、たぶんそんな機能はないと思っていて大丈夫だと思うんだけど……。https://www.gnu.org/software/guile/manual/html_node/Scheme-Read.html

機能が存在していないことを確認するの難しいのでは

Common Lisp には *read-eval* が真のとき read 時に任意の式を評価できる(デフォルトは真)という恐怖の仕様があって、これが guile の read に無いことをどうやって確認すればいいのか分からない。

Variable *READ-EVAL*http://www.lispworks.com/documentation/HyperSpec/Body/v_rd_eva.htm#STread-evalST

Vultr のオブジェクトストレージはさすがに監視した方が良い気がする。

いや、ただじゃない。Vultr のオブジェクトストレージは 250 GB 以下だと常に月額 $5 かかるので 250 GB 以下だと常に損するという話です。

250 GB までは実質ただなので一旦これは上げよう。

うへー、16 GB あるのかー。