Home | Notifications | New Note | Local | Federated | Search | Logout
Federated Timeline
コシヌケ1040@ksnk@pawoo.net (2026-01-05 23:10:58)
ふしぎなひびき、センバキッチョー。
🦉@aaa (2026-01-05 23:08:33)
これで一通り作り終えた
修正がでなくなったらそれを1.0にしよう
たかし@tak4 (2026-01-05 22:46:31)
改めて哲学カフェをフォローしようかと思ったらフォローできてゐた。
有難う御座います。
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 22:15:48)
ACL2は一見一回論理に限定されている分簡単そうに見えて、実際のところはバリバリ古典AIの究極成果みたいな感じで、ヒューリスティック探索のコツを掴んでいくことこそが大切だったりすることが難しい。
あと、ガードの話は書かないと静的型付け全盛期の今の時代いけない気がするものの、ガードがACL2のロジックに影響しせず、ガードはほかのガードとのみ影響し合うといったところは明らかに簡単に説明できるものではなく公式ドキュメントを読もうとなってしまうあたり大変…
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 22:12:04)
ACL2の記事執筆、あまりにも難産すぎて苦しくなってきたので一旦置いておくことにした。。。
そもそもむずすぎるし、書いていると無限に改善点が見つかる。。。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@qnighy@qnmd.info (2026-01-05 22:00:32)
もしイベントを外部のアクターに処理させたければ、まず変更と同じトランザクションで(同じデータベースに)キュー要素を積み、それをワーカーが取り出して外部用のメッセージキューに投げ直すといった方法は考えられる
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@qnighy@qnmd.info (2026-01-05 22:06:17)
非同期処理のキューの場合結果整合性で済ますが前提なので絶対にトランザクショナルじゃないといけないわけではないが、メッセージ喪失の対策だけでも意外と大変なので最初からトランザクショナルにすればいいのに……という意図
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 22:07:13)
トランザクションの処理はRDBの中で完結させないとおかしくなるんだよな…
Masaki Hara@qnighy@qnmd.info (2026-01-05 22:06:17)
非同期処理のキューの場合結果整合性で済ますが前提なので絶対にトランザクショナルじゃないといけないわけではないが、メッセージ喪失の対策だけでも意外と大変なので最初からトランザクショナルにすればいいのに……という意図
Masaki Hara@qnighy@qnmd.info (2026-01-05 22:00:32)
もしイベントを外部のアクターに処理させたければ、まず変更と同じトランザクションで(同じデータベースに)キュー要素を積み、それをワーカーが取り出して外部用のメッセージキューに投げ直すといった方法は考えられる
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 22:00:18)
たしかに…、RDBでエンキューまで全て済ませるのはだいぶ正解感があるな…
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@qnighy@qnmd.info (2026-01-05 21:56:38)
@anqou ぼくの投稿は「同じデータベース内に」と書きました
Reply to @anqou@mstdn.anqou.net
Masaki Hara@qnighy@qnmd.info (2026-01-05 21:56:38)
@anqou ぼくの投稿は「同じデータベース内に」と書きました
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 21:48:29)
まさかスマホとここまで密結合したデバイスだとは…
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 21:47:08)
そもそもスマートウォッチの実態をよく知らずに買っちゃったところから始まってるからなあ
Reply to @tojoqk@mastodon.tojo.tokyo
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 21:46:20)
GadgetBridgeのおかげでプライベートな生活情報をクラウド管理されることなく便利機能を享受できるようになっているので、GadgetBridgeがなかったらと思うと困る…
きゅーけー@tojoqk@mastodon.tojo.tokyo (2026-01-05 21:42:51)
GadgetBridgeはとてもいいものではあるが、デバイスを購入した時点で、プロプライエタリなソフトウェアを前提とする販売元に利益供与しちゃう問題はあるよなあ…。Windowsの入ったノートパソコンを買ってその後にWindowsを消しているものの買ったときにWindowsに貢献してしまうとの同じ問題がある。。。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@boronology@social.penguinability.net (2026-01-05 21:31:33)
私は自分の理想が全体にとって最適な自信なんてこれっぽっちも持ってないので「自分向き」という表現をしていますが、信じる正義のある人は「良いもの」に読み替えていただければと思います
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@boronology@social.penguinability.net (2026-01-05 21:26:20)
ない、んだが。それはともかくとして人々はもう少し自分の行住坐臥に政治的な意味合いをも持たせうるのだということを知ってほしいとは思う。ものを買うときにはある種のものを選ばないだとか、道具を選ぶときにある種の属性に価値を見出すとか、そういう判断の一つ一つが将来の状態をより自分向きにしていくための一助となるということ。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@boronology@social.penguinability.net (2026-01-05 21:16:16)
私は常にプロプラなものの提供者を脅迫し続けるつもりでいるけど、そこまでの先鋭さを全員に求めは（あまり）しない
Reply to @boronology@social.penguinability.net
イリオモテペンギン@boronology@social.penguinability.net (2026-01-05 21:31:33)
私は自分の理想が全体にとって最適な自信なんてこれっぽっちも持ってないので「自分向き」という表現をしていますが、信じる正義のある人は「良いもの」に読み替えていただければと思います
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@boronology@social.penguinability.net (2026-01-05 21:11:23)
これ私の方向性と割と近い。プロプラなものがあることと、そのメリットの存在を認めながらも常に代替の存在を確保し続けること自体が将来的な価値を増加させると思っている
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@anqou@mstdn.anqou.net (2026-01-05 21:26:32)
多分単純な解は無いので問題に応じてうまくやる必要があるんだと思っている
Reply to @anqou@mstdn.anqou.net
Ushitora Anqou@anqou@mstdn.anqou.net (2026-01-05 21:26:32)
多分単純な解は無いので問題に応じてうまくやる必要があるんだと思っている
Reply to @boronology@social.penguinability.net
イリオモテペンギン@boronology@social.penguinability.net (2026-01-05 21:26:20)
ない、んだが。それはともかくとして人々はもう少し自分の行住坐臥に政治的な意味合いをも持たせうるのだということを知ってほしいとは思う。ものを買うときにはある種のものを選ばないだとか、道具を選ぶときにある種の属性に価値を見出すとか、そういう判断の一つ一つが将来の状態をより自分向きにしていくための一助となるということ。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@anqou@mstdn.anqou.net (2026-01-05 21:25:05)
これむずくて、エンキューしたあとにコミットしようとしたら DB との接続が切れて死亡する可能性があると思っている。正解を知りたい。
きゅーけー@tojoqk@mastodon.tojo.tokyo boosted:
@qnighy@qnmd.info (2026-01-05 20:40:52)
「非同期ジョブのエンキューはコミット後にやりましょう」というやつ、コミット直後にアプリケーションプロセスがハングして状態が宙ぶらりんになるケースを考慮してないからあんまり好きじゃない。非同期ジョブのエンキューはトランザクション中に同じデータベースに入れるべき(?)
Ushitora Anqou@anqou@mstdn.anqou.net (2026-01-05 21:25:05)
これむずくて、エンキューしたあとにコミットしようとしたら DB との接続が切れて死亡する可能性があると思っている。正解を知りたい。
Reply to @boronology@social.penguinability.net
イリオモテペンギン@boronology@social.penguinability.net (2026-01-05 21:16:16)
私は常にプロプラなものの提供者を脅迫し続けるつもりでいるけど、そこまでの先鋭さを全員に求めは（あまり）しない
イリオモテペンギン@boronology@social.penguinability.net (2026-01-05 21:11:23)
これ私の方向性と割と近い。プロプラなものがあることと、そのメリットの存在を認めながらも常に代替の存在を確保し続けること自体が将来的な価値を増加させると思っている
Older Notes