猫じゃらしからラーメン作ってみた【ENG SUB】
https://youtube.com/watch?v=Qttwf5FBOyQ
Blender 4.3 released
このアカウントは、notestockで公開設定になっていません。
フライトシムをフライトムシに空目して「そりゃ飛ぶこともあるだろ虫なんだから……」と思った
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
> 米ソ首脳会談の際、ケネディとフルシチョフは余興として徒競走をした。
> それに関する両国の報道∶
> 米紙「両国首脳が徒競走しケネディが1位だった
> フルシチョフはビリだった」
> ソ紙「わが第一書記は栄光ある2位を獲得した
> ケネディはビリから二番目であった」
意識の7割くらいが「寒いな……」で占められてきて作業が著しく阻害されていることを自覚したのでストーブを出した (床上 90cm まで力業で持ち上げて移動しま)
昨年はストーブ不要だったのだが、これは
* クソうるさいサーバが稼動していてラックが常時500W〜700Wくらい使っていた
* 部屋のドアを閉められた
* 湿度 30%RH くらいだったので沸騰型加湿器で室温と湿度を上げられた
という条件が揃っていたためなのだが、今年の冬は (というか今日は)
* クソうるさいサーバや複数の NAS を休眠させ高発熱ネットワーク機器も減らしたため、ラックが400Wくらいしか使っていない
* 室内のエアフローを最適化したためラックの排熱がデスクに戻ってこない
* 湿度 52%RH なのに寒い
* 廊下のドアが閉められない
と条件が悪いので、着込んだうえで純粋な熱を発生させる他に手がない
* 昨年の冬 0.67 kW: https://mastodon.cardina1.red/@lo48576/111678716988820955
* 廊下のドアが閉められない: https://mastodon.cardina1.red/@lo48576/113512470333640671
まあドア閉めたら閉めたで明らかに眠気強くなったりして二酸化炭素濃度の上昇が疑われたりするので、善し悪しですね……
閉めたらといってもドアストッパーで必ず数 cm は開けるようにしているのだが (でないと本当に換気が悪くなりすぎる)
あとは加湿器を運用していてわかったのが、自動運転で最弱設定にしてもほぼ常時運転風味な感じになっており、加湿器だけではあまり湿度が高いまま維持できない環境らしかったので、その点でも沸騰型の加湿器はかなり電力の消費が激しくてつらかった
2週間ひきこもり生活で消費した食糧を一気に補充したところ ¥14k くらいになったので、月の食費が ¥30k くらいであることが察せられた
📣 Announcing the availability of:
- PHP 8.3.14
- PHP 8.2.26
- PHP 8.1.31
‼️ SECURITY fixes:
- Heap-Use-After-Free in sapi_read_post_data
- OOB access in ldap_escape
- Leak partial content of the heap
- Integer overflow in the dblib/firebird
- CRLF injection in URIs with proxy
- Single byte overread with convert.quoted-printable-decode filter
📝 Changelog: https://www.php.net/ChangeLog-8.php
🎁 Source: https://www.php.net/downloads Windows: https://windows.php.net/download/
エージェント的なものが idiomatic Rust で扱いづらいというよりも、「(振る舞いに共通部分があるものの) 本質的には異なる種類のオブジェクトを同質かのように混合して扱う」というのが合わないのだと思っている。静的にできなくて実行時に判定入れまくったりメタデータつけまくったりする必要があるから。
一応 dyn Trait とか自作 vtable とかでどうにかできるにはできるが動的だし、「同質扱いしたものをやっぱり別物だったことにして再度区別する」みたいなのはもっとダルい (dyn Trait と相性が良くない)
stratum 3 の NTP サーバを「ブロンズ帯」と呼ぶなど、活動は多岐にわたる
このアカウントは、notestockで公開設定になっていません。
そういう面はあるけど、実際 dyn Trait の利用は enum に置き換えようとすればできなくもない (ただ事前に列挙が必要だから crate を跨ぐのが相当ダルくなる場合が少なからずある) ので重大ではあるものの致命的な点はそこではなさそうと思った。
まあ idiomatic かどうかという話なら致命的でなくとも重大なだけで十分駄目なんだけど……
同一視は情報を消す方向なのでなんだかんだやりようはあって、本当に面倒なのは「消されたはずの情報を『やっぱ欲しい!』といって復元する」というところで、 Rust に限らず静的型付き言語はこれが苦手で動的型付き言語はこれが比較的得意な傾向がある。やろうとすれば不可能ではないのだか。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
まあ木構造とか書いてても親へのリンクの扱いは困るし、難しい…… (所有権モデルがそもそも向いてない)
単に実装するだけなら寿命を代表するオブジェクト (document なり arena なり) をひとつ持っておいてあとは全部所有権管理や生存保証を行わない dumb なポインタを使えばいいんだけど (そしてこれが C 時代の標準的手法だったはずだけど)、それは間違いなく idiomatic Rust ではないし error-prone すぎるのでつらい
Rust 用に書いた木構造ライブラリ dendron の内部構造の解説 - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2022/12/08/dendron/
本気のまともな木構造は昔ちょっと書いてみたことがあるけど、 unsafe を使わず言語の所有権システムに乗るための手間がかなり大きいし、そこまでやってもこの手の木構造は「すべてのノードが同質」というある意味性質がかなり良い方の部類なので、非対称でリンクの伸び方も滅茶苦茶な乱雑なグラフなんかは手に負えそうにないという個人的な感想がある
このアカウントは、notestockで公開設定になっていません。
saschagrunert/indextree: Arena based tree 🌲 structure by using indices instead of reference counted pointers
https://github.com/saschagrunert/indextree
これとか
参照と実データ間での完全な寿命管理を放棄して arena に代表させて寿命を全部統一しましょうという発想。
一応不完全な寿命管理 (運が悪くなければ、実行時に、参照先の不存在を検出できるとか) は実現できたりするけど、実行時検出が主だし相応のオーバーヘッドや設計の複雑化はある
petgraph/petgraph: Graph data structure library for Rust.
https://github.com/petgraph/petgraph
こっちは木ではなくグラフだけど、これも arena にノードとエッジを突っ込んで edge はポインタではなくインデックスを持つみたいな設計だったはず
TL が混線した結果「IntoFree ってめっちゃ Rust のトレイトみたいな名前の会社だな」と思うなどした
arena 方式は mutability が (つまり書き込みのためのロックが) arena 全体でまとまってしまうことが多いのがね……
このアカウントは、notestockで公開設定になっていません。
Android のホーム画面に Google の検索バーが出て消せないのかなりカスだと思っているが、どうにかなる希望が出てきたか? (ホームアプリをデフォルトから変えろというのは無しで)
このアカウントは、notestockで公開設定になっていません。