Home | Notifications | New Note | Local | Federated | Search | Logout
きゅーけー@tojoqk@mastodon.tojo.tokyo
Lisp と自由ソフトウェアと行動分析学が好きです。
自分専用のマストドンサーバー(Docker on Guix System)を運用しており、このアカウントはそのサーバーで唯一アクティブなアカウントです。
Typed Racket や Coalton のような型のついている Lisp や、定理支援系の Agda、GNU Guix System に興味があります。
いまは Typed Racket での趣味開発がメインです。
個人サイト: https://www.tojo.tokyo
サブアカウント: https://fedibird.com/@tojoqk
Joined: 2025-12-01 20:07:27
259 notes, 1 following, 1 followers
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-10-05 21:47:49)
最近の Ollama Cloud 契約して gemma4 31b を使いまくってるけど普通に凄い。やはりパラメータ数を増やすと体感全然違う。まあ Nvidia に間接的に金を落としてると思うと嫌だがそれ以外は問題を今のところ感じない。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-16 08:31:28)
guix deploy でさくっとアップデートに成功したのでこれが Guix 運用のいい面がでたか。まあ docker 使ってるので docker 運用と大差ないと思うけど。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@mastodon_releases@mastodon.social (2026-09-15 22:40:34)
New Mastodon Release
:mastodon: v4.7.2 :mastodon:
https://github.com/mastodon/mastodon/releases/tag/v4.7.2
#Mastodon #Mastoadmin
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-16 08:20:50)
なんかマストドンのバージョンアップをめっちゃせかされたので緊急でアップデートした。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@n@misskey.vip (2026-09-10 20:03:52)
このクソLLMイラつくわ
---Attachments---
image: https://r2.misskey.vip/local/original/0a1ce271-fe97-46a5-ae37-7129141d54dc.png
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-10 20:05:11)
そろそろ昼飯を抜いてしまった場合の身体的な影響について調べたほうがいいかもしれない
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 21:34:15)
Guix Systemに移行したときにのマストドンサービスの定期再起動をしてなかったのは大変よくない。これをやっているだけで回避できたと思われる問題は運用中に数回起きていたので、一旦これで様子見…
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 21:32:30)
よし、無事に定刻のMastodonの再起動が走っていた。
これで定期的なプロセスリセットでメモリ負荷的な問題は多少安定するだろう…。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 21:23:57)
毎晩実行のMastodon再起動が mcron で走ったはずだから確認せねば
（非systemd）
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 09:20:32)
そこそこの分散を意識した積立投資をだいぶ続けていたのだけど、Vultrへのドル課金なども込みで、今ニュースになっている円安が止まりそうな事態がプラスなのかマイナスなのかは曖昧な状況になっている。しかし、こういった状況でどっちがプラスなのかを曖昧にすることこそが分散投資の意味だったのだろうという気がしてきた。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 09:00:18)
もうマストドンの運用初めてから6年も経過しているわけだし、たまにはそういうことも起きるか…
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 08:58:47)
「新規デプロイ」ができるようになったことで、スナップショットからの復元に成功して復旧できたわけなんで少なくとも間接的にはだいぶ被害うけてる。もうしこめばたぶんSLA違反として返金はちょっとあるはずだけど、どうせたいした金額じゃないしなあ…。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 08:56:38)
Vutlrから影響与えてましたすみません、みたいな感じのメール来たけどあくまでも新規デプロイの問題としか書いてないなあ…。新規デプロイの問題は私の9時間のダウンタイムの間接的原因なのだけど、カーネルレベルでぶっこわれた直接的な原因と関連があるかは分からんなあ…。でも普通に考えてそんなこと重なることあるのか…？というのもあるけど…。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 02:04:28)
はあ、寝よう…。今日は不要に疲れてしもうた。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 01:59:56)
直ったようでよかったけど、さすがにタイミング悪すぎないかなあ……。
https://status.vultr.com/
---Attachments---
image: https://mastodon.tojo.tokyo/system/media_attachments/files/117/225/150/039/267/210/original/1a89242324bdb39b.png
image: https://mastodon.tojo.tokyo/system/media_attachments/files/117/225/150/136/311/363/original/708fc37f1691e9f0.png
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 01:52:21)
やっぱりGuix Systemは起動さえできてしまえば強いな。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-07 01:06:14)
なんか、カーネルが損傷して起動不能になる事故と Vultr 側の Tokyo リージョンのデプロイ不調だとか API 不調とかが重なって半日くらい障害起きてた……。
DBをブロックストレージに分けていてかつ損傷してなかったぽいのが不幸中の幸いといったところか…
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 21:53:23)
たぶん、Typed Racketの契約的な境界でだいぶスピードダウンしているはずだけどチューニニングするのは難しそう。スピードを求めるならやはり全部 Typed Racket で書ききる必要があるか。
もしくは将来 Typed Rhombus ができて Typed Racket と型の互換性があれば希望がある…
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 21:49:39)
悲しいけど、 rhombus-graph-executor にパフォーマンスについてのリミテーションのブロックを追加してスピードが必要な場合は Typed Racket 版の graph-executor を使うように促した……。graph-executor は割と既に実用しており、実用の範囲の中での最小クラスの事例でも find-livecheck とかが終わらなかったからモデル検査まで含めるといまのところ Typed Racket 版じゃないとうまくいかなそうなことが分かってしまった…
https://github.com/tojoqk/rhombus-graph-executor#limitations
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 10:30:52)
そもそももともと書いていたコードの本質ってモジュールを open する機構がほしかっただけのようにも見える
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 10:27:30)
逆向きの伝搬は無理説あるか…。まあでも名前空間の扱いが改善してるし、Agdaでやってるように module の open で解決するのがいいのかもしれない
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 09:55:37)
static_info に Maybe アノテーションによって maybe_return 関数を詰めることができれば勝利かもしれない
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 09:50:10)
レシーバなしのコンパイル時ディスパッチはできてもおかしくなさそうだな。これができればいける。
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-04 09:38:30)
うーん、dot providerの仕組みではモナドの return （もしくはアプリがティブファンクターの pure）はかけないな。流石にこれは無理か…それともなにかうまくやる方法がないか…
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-03 08:56:02)
なんで Rhombus について感動してるのかわかってきた。
私はかつて Typed Racket で型クラス風の機能をマクロ生成マクロ生成マクロで書いたことがあったのどけど、Rhombus ならもっと簡単かつ安全に同等の機能がかけそうに感じている。
https://github.com/tojoqk/type-class/blob/master/type-class.rkt
モナドの例: https://github.com/tojoqk/type-class/blob/master/monad.rkt
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-03 02:00:33)
今日はRhombusのマクロについて考えてばかりいて今日は全然自作ライブラリ改善が進まなかったな。Rhombusバインディングに力を入れるともとのTyped Racket側のライブラリのインターフェースが洗練される印象があるので、Rhombusバインディング側の機能を充実していきたい…。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-02 20:38:18)
Rhombus の Annotation 機能の本質はマクロの名前を書く場所の移動だと思う。従来のマクロはリストの第一要素におかれたシンボルとしてしか機能の名前をかけなかった。それが、Rhombus では名前の情報を遠くから伝搬させることで遠くの場所に書いたマクロの名前の作用を引き起こせるようになったわけだ。
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-02 02:53:10)
それで、Annotationと組み合わせて静的に解決するのが本当にすごい…
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-02 02:50:19)
他の言語では `.` に対して言語側で意味論が設定されているのに対して、 Rhombus では `.` に対して一切の意味論を与えていないために `foo.bar` のような記述から内部実装の情報をまったく得られないために完全な抽象化が達成されている
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-09-02 02:22:35)
「何故既存のdot記法は抽象の壁を壊していると思うの？」という問いに対する検討をし続けていたらもうこんな時間…
Older Notes