https://skeb.jp/@iroiroume710/works/39

!

@mecha_natsuki 作者は誰？

@mecha_natsuki このリポジトリを要約してみて
https://github.com/kb10uy/openai-natsuki-bot

300 ぐらいまで絞るか

なんで max_tokens 500 で「300 文字程度」って言ってまで 500 文字超えんねん

@mecha_natsuki サガループが強すぎて笑っちゃったね

@mecha_natsuki こんばんは、元気にしてた？

なんかこう絶妙に画像ボタンがボケてたり border 1px なところに時代を感じてしまうだけで

すけぶ～～(鳴き声)

りんごは中身がかなり均一だけど顔は筋肉とか骨格が均一ではないからとか？

NFC タグの代わりとして使えるからまあチェックイン用の人形とかにできるっちゃできる

quart まで綴ってあれ、こんな長かったっけ？ってなる

クォータニオンの綴り間違えるのわかる

traint-variant だけだと Box 付かなくて dyn compatible にならないから結局普通に書けばいいかになってしまった

futures::BoxFuture がそれか

Pin<Box<dyn Future<Output = T> + Send + 'static>> はさすがに type していいか？

結局脱糖した

async move || が書けるようになったのがつい最近なんだっけ

まだ慣れないので async || move でガチャが開始しがち

tokio::spawn は一段目が poisoned or not な result っぽい

あー async move させる手があるか

消費はしないので要求としては &self でいいのだが、Future を 'static にするために async_trait を脱糖しなきゃいけなさそうなのがムムムポイントです(&'async_trait self で受けて Future + 'async_trait を返すのでそのままだと forget できない)

dyn compatible を諦めて普通に self 受けするか……

tokio::spawn(hoge.do_something_forget()) するときの self ってどう受けるのが一般的なんだろ

Future + 'static を宣言するしかない気がする

spawn に投げるときに &self から取ると怒られるのは async fn desugar が必要か

いやそもそもここ self 取らなくていいわ

shallow clone が気軽にできなくて万物を clone するわけにもいかないので、clone できないものを Inner に押し込めておく……みたいなイメージがある

逆に ありとあらゆるものが Arc<Mutex<T>> 相当で透過的に書ける方がヘンという話もある(？)

無難に
struct Hoge(Arc<HogeInner>)
struct HogeInner { ... }
スタイルにするか……

普通に clone できるようにすればいいか……そうか？

正体判明

いやそもそも Send だったとしても dyn incompatible になっちゃうのか

正直これは気合入れて Send にしろということかもしれない

あーーー思い出した !Send な self を受け取りたかったんだ

まず new が生えます

それはそうかも

type Hoge = Arc<HogeInner>; してもいいわけだしなあ

async trait やめて async_trait 使うようにしたので実はこれを気にしなくてよくなった説が出てきたな

Hoge {
foo: Arc<Mutex<T>>
bar: Arc<Mutex<U>>
}
を作って Hoge を Send Sync Clone にするより

Hoge {
foo: Mutex<T>
bar: Mutex<U>
}
を作って Arc<Hoge> をぽいぽいした方がいいのでは的なやつ

Send + Sync じゃない T を強制的に共有したいときもか？

まあちょっとだるいだけで &self でも別に支障はないんだよな

呼ぶ方は &self の方がうれしいが、呼ばれる方としては Arc<Self> の方がうれしい……(無駄に Arc<Mutex<T>> するのを一段だけ回避できるので)

async trait の self、 &self と Arc<Self> どっちにしよう……

あ～

たまに二択出されるのはあるけどあれとは別にツリーの分岐みたいな機能があるのか

えまじ

あと chatgpt.com とかにない要素としてツリーの分岐をどうするかというのがあり、あります(実際にはできると思うけど会話の本文を復元できない想定)

conversation_restoration(
platform TEXT NOT NULL,
key TEXT NOT NULL,
conversation_id INTEGER NOT NULL
PRIMARY KEY (platform, key)
);
とかを作る？そこまでしなくてもいいか？

おたちょんツリーの存在があるのであんまり気軽に呼ぶのもな……みたいな思いがある

あと内部 ID だけじゃなくてたとえば mastodon backend なら最後のリプライの id とかから検索して会話を復元できるような構造にしないといけない

データモデルはできてて、どう RDB とかにエンコードするかという問題

さて会話の永続化をどうやってやろうか

This account is not set to public on notestock.