らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿 
Mastodonのローカル投稿の保存状態はプレーンテキストよね。リモート投稿はhtmlだけど。
ローカル投稿は、REST APIの応答やActivityPubのオブジェクトとしてシリアライズされる時にフォーマットされる。 [参照]
設備・備品 #206: PC: nagisa - 鯖缶 - Nopmine
https://redmine.potato.immo/issues/206
1台目のサーバの全パーツの出処がやっと判明した…… (ケースファンとかの細かなものは除く)
不毛に見えるかもしれないが、一応棚卸と箱処分を兼ねている (PC ケースの箱に突っ込んであった無数の箱を整理している)
実店舗で購入したやつ、 web で履歴を確認できなくて大変不便だ
逆に通販で購入したやつは注文日と発送日と納品日の全てが違ったりするという面倒もある
執念で自宅に存在するはずの SSD をすべて (文字通りすべて！) 特定したはずなのだが、行方不明になっているものが2つもある。しかも NVMe M.2 の 1 TB と 2 TB。
そんなことあるか！？
https://redmine.potato.immo/issues/276
https://redmine.potato.immo/issues/277
わかった、片方は PS5 に取り付けたまま実家に行ったやつだ
このアカウントは、notestockで公開設定になっていません。
ふーむ。 yonagi 用に 1.5m の SFP+ DAC ケーブルが2本欲しいかもしれん
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
WM が **ちゃんとした** Tiling WM でない時点で Windows の使い勝手の悪さは 10 でも 11 でも五十歩百歩といったところなのだが、 Win10 はエクスプローラでタブ機能が使えない点で五十歩劣っているので、労役ﾏｯｽｨｰﾝは速やかに Win11 になってほしいと切実に願っている
「Win+矢印 でデスクトップ分割とウィンドウのタイリングできるよ (ﾍﾗﾍﾗ)」みたいなのは Tiling WM とは言わんのじゃ、 RDP 接続などでモニタサイズが変更されたとき全てのレイアウトが破綻するのを直してから出直してきてくれ
自宅のモニタとｼｬのデスクに置いてあるモニタの解像度が違うので、デスクトップをカシャカシャ振ってウィンドウを全部左上に寄せたみたいな馬鹿の挙動を毎日押し付けられてブチギレてる
『Apex Legends』eスポーツ決勝戦で「選手にチートが付与される」ハッキング被害が発生…公平性が損なわれているとして大会は延期に | インサイド https://www.inside-games.jp/article/2024/03/18/153672.html
このアカウントは、notestockで公開設定になっていません。
20%RH 台で生活していると、うっかりするとすぐ唇が切れるんですよ。
lip が rip ってねw
VXLAN、見るたびに毒ガスみたいだなぁと思うのだが何だっけか
マスタードLAN
？？？「マスターは差別です！メインにしましょう！」
論理昨日、 Proxmox VE クラスタが繋がっているスイッチの設定を確認してみたら LACP のハッシュが layer 2 設定になっていたのがハイライト (?)
このアカウントは、notestockで公開設定になっていません。
設備・備品 #252: NIC (PCIe): 10Gtek, Broadcom BCM57810S, 10GbE SFP+ ×2 (57810S-10G-2S-X8) - 鯖缶 - Nopmine
https://redmine.potato.immo/issues/252
弊宅のサーバの 10GbE は全部これ
X10DRH-iT | Motherboards | Products | Super Micro Computer, Inc.
https://www.supermicro.org.cn/ja/products/motherboard/X10DRH-iT
あとそもそもチップを確認したら安価で爆熱と名高い Intel X540 だったので、ﾊｲ……
ロープロな SFP+ の NIC とか探すか……
https://mastodon.cardina1.red/@lo48576/110281438985239144
NAS のオンボードの 10GbE (RJ45) を使ったら100℃超えたせいです
7000rpm で離陸音を奏でれば冷やせる可能性もあったけど、一般のご家庭なので……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
テスト (通ったからと言って動くとは限らない) ってこと？w
ほぼあるゆるテストはそもそも完全な動作保証をするものではないので問題ない (???)
Intelなんか次ソケット変わるらしいし今組むとすると時期悪いな〜という気持ちになってきたが、まあどうせ Intel なんてころころ変わりそうだしどこで組んでもいいという説はあるか
AMDでもよくね？と思うかもしれんが、手元で動かしたいワークロードはシングルコア性能重視なので Intel のほうがよさそうという認識
ﾖｰﾂｰﾍﾞで CPU のレビューしまくる人とかでもなければ同じ M/B で Intel の CPU を載せ替えるようなことってあまりないのでは？ みたいな気持ちは実際ある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ブルシット・ジョブを2倍やるとダブルシット・ジョブになるともっぱらの噂
通帳なんて機能だけで言えば直近3ヶ月分くらい見られればあとは手元の複式簿記の家計簿に書き写してしまうのでそれ以上遡れる必要は実はない (もちろん何かあったとき検証できるに越したことはないが)
クラッシュするはずのテストがクラッシュしなかった顔をしています
テストか実装か環境セットアップかいずれかがおかしいのだが、いずれにせよ私が悪い……
の投稿
herschel@raptol.net
このアカウントは、notestockで公開設定になっていません。
の投稿
herschel@raptol.netこのアカウントは、notestockで公開設定になっていません。
の投稿
herschel@raptol.netこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Rustで
struct A { i: i32 }
fn main() {
let mut a = A { i: 0 };
let ptr = &mut a as *mut A;
let ai = &a.i;
unsafe {
(*ptr).i = 10;
}
print!("{} {}", a.i, ai);
}
とするとリリースビルドでも10 10が出力されるんだけど、Rustはimmutable borrowを証拠にした参照の最適化はしないと思っていいのかな（ナイーブにはaiがimmutable borrowであることを利用して*aiを0に置き換えるような最適化が起きてもおかしくない気がする）
ポインタ作る分にはいくつあってもいいはず。そこから &mut を複数同時に存在させるような使い方は unsound になるけど
C で restrict pointer を誰も使っていないせいで LLVM の最適化がバグりまくってて Rust でも当該の最適化を無効化せざるを得なかった、みたいな話がだいぶ昔にあったな
Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using i... | Hacker News
https://news.ycombinator.com/item?id=25624538
unsound なコードは UB なので何が起きても文句は言えない、そこは C/C++ と変わらないと思う
どこかに書いてあったかなぁ……ソースを出せと言われるとちょっと自信がない
Behavior considered undefined - The Rust Reference
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
> if unsafe code can be misused by safe code to exhibit undefined behavior, it is unsound.
あーそうだった、 unsound というのは safe context で UB を発生させるような実装の性質を言うのだった
何かめちゃくちゃ雑なことを言ってしまった気がするけど、 &mut と1つ以上の & でも駄目だと思います (つまり参照の存在レベルでは普通の shared xor mutable ルールに違反できない)
原則として、 unsafe ブロックは「コンパイラには検査できない書き方をするが、ブロック内でコードが満たすべき性質を破らないことを開発者が保証する」というものなので、 unsafe ブロック内に入れようが駄目なものは駄目
あと&mutを2つ以上生やすだけでおかしくなるならThe bookの例もダメということになりそう https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#creating-a-safe-abstraction-over-unsafe-code
これは同じオブジェクトを指していないので ok (オブジェクトという言い方だと C++ っぽいけど……)
要は &mut がオーバーラップしてない
この辺りちゃんと形式的な言葉がパッと出てこないのですべての発言が雑になりがちで難しい。修練が必要……
このアカウントは、notestockで公開設定になっていません。
参照の shared xor mutable もそうだし、値が型の定義域から逸脱しない (たとえば bool が false と true 以外にならない) こともそうだし、未定義のメモリ領域を読まないこともそうだし、まあいろいろ
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/#ub-even-if-inconsistency-is-transient
let x: bool = mem::uninitialized();
が即座に未定義動作になるのを思い出していた。 UB は魔境や
split_at_mut は入力の r は食われて結果の left right はオーバーラップしないので全体として安全みたいな
split_at_mutの第一引数は&mut [i32]だけどこれでr食われるの？
&mut [i32] 型の r という値が食われて、 a と b が作られる
「コードが満たすべき性質」がなんなのかが分からん。split_at_mutはunsafeを使わないと書けないパターンなので、これが安全であるなら「コンパイラが通す型」!=「コードが満たすべき性質」のはずだけど、じゃあ具体的に何を満たしていればよくて何をviolateしちゃいけないのか
このケースだとこれかな
> Moreover, the bytes pointed to by a shared reference, including transitively through other references (both shared and mutable) and Boxes, are immutable; transitivity includes those references stored in fields of compound types.
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
&i32: Copy
みたいなの、言われてみると確かに〜〜となるんだよな。たぶん驚きの根本的な原因は C++ 形式の参照に慣れてしまっているところなのかもしれないけど
C++ の参照、ポインタの syntax sugar っぽいフリをしているが「参照の参照」みたいなの持てないし1段階の参照しか持てない (cf. reference collapsing) ので first-class な型構築子ではないというか。
その点 Rust の参照は好き勝手ネストできるしそれぞれがちゃんと first-class な型として扱われる
あとは C++ の参照は参照先の変更 (つまり参照変数そのものに対する書き換え) ができないけど Rust では &mut 変数の書き換えによって参照先の変更ができるとか。
https://en.cppreference.com/w/cpp/utility/functional/reference_wrapper
std::reference_wrapper<T> (C++) のことを思い出しています……
unsafeがどれくらいunsafeなのか知りたいんだけどそういうことを書いてあるドキュメントが見つからない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
js とかのリソースはどうすればいいのかわからんが (Rails とｳｪﾋﾞフロントエンド技術なんもわからん顔)
Redmine なんかはどこかに ruby のファイル置いとくと起動時にフックできたりしなかったっけ
そもそも core と std の存在意義として、その辺りの「みんな安全だと信じてるけど個々に書いていると地獄になりがちな unsafe とかを集結させようぜ」的なところはある。
もちろん処理系の内部実装にベッタリ依存しないと書きづらいコードを入れとくというのもあるけど。
実は std::ffi::OsStr と std::path::Path が内部的には同じ型と同じ制約を使っている話します？
https://doc.rust-lang.org/1.76.0/src/std/path.rs.html#1992-1994
https://doc.rust-lang.org/1.76.0/src/std/path.rs.html#2040-2042
この2箇所だけ見ればいいやという気持ちになったのでしません
クライアントならまだしも、サーバソフトウェアで下手に API とアーキテクチャが安定しないうちにプラグイン機構なんか実装してしまったら、「プラグインが追従していないのでバージョン上げません」みたいな連中が大量に発生してしまうし、これが外部のサーバと連合組むソフトウェアだったらもう地獄ですよ
chcp 65001 してないオタクなんているかぁ！？
このアカウントは、notestockで公開設定になっていません。
@kb10uy invalid UTF-8 sequence
@kb10uy もしかしたらネイティブ表現が非 Unicode な文字集合の FS だと普通に lossy かもしれない (具体例はすぐには出てこないが……)
このアカウントは、notestockで公開設定になっていません。
diff だとこまめに rebase してコンフリクト解消しないと後でまとめてやると面倒だったりするので、そもそもそういうコンフリクトの可能性を極力減らしたいし API が変わるならドキュメントで案内があってほしいというのがプラグインシステム欲しさの根底にありそう
partial な borrow であるという情報が関数の境界を跨いで持ち越してもらえない問題なぁa
確かに不便ではあり、一方で境界の切り方としてはそんなもんかなという気持ちもある (でないと、コンパイル通ってたのに caller を追加した瞬間に callee 側でコンパイルエラーが出るみたいな嫌なことになりかねない)
partial な borrow を型として表現できないかみたいな話、誰かが書いてたな。何だっけ……
Notes on partial borrows - language design - Rust Internals
https://internals.rust-lang.org/t/notes-on-partial-borrows/20020
いろいろありそう
View types for Rust · baby steps
https://smallcultfollowing.com/babysteps//blog/2021/11/05/view-types/
Blog post: View types for Rust - language design - Rust Internals
https://internals.rust-lang.org/t/blog-post-view-types-for-rust/15556/2
構造体を一時的に解体したりフィールドの参照を作りまくったのち、必要なフィールド (の参照) だけを受け取るような小さな関数を書きまくるという手はある。
つまり &mut self やそれに相当するデカいものを内部的に使わないようにする
所有権を奪わず参照へと崩すの、
let Self { ref mut a, ref mut b, .. } = self;
みたいな書き方ができるので……
let Self { .. } による deconstruct、たまにやる
ECS、概念は知っているが使ったことなし (そもそもゲーム書いたことなし)
大雑把に、フレームワークレベルで AoS を SoA にするとﾊﾟﾋｮｰﾏﾝｽ出せそうだし嬉しい、そんでもってフレームワークレベルでやれば SoA に特化した実装の方式を強制してさしあげられるよね、みたいな話だと理解している
Player component と GameState component みたいなのを用意して前者は人数分、後者は 1 個だけ Entity を作ってアタッチ、 PlayTurn system (これは実質ただの関数) で更新するみたいな
1個だけしか作らない前提の Entity 、ありなんだ (できないことはないだろうけど、非推奨でもないんだ)
どうも SoA にすると暗黙にスケールさせる前提のものを突っ込む気持ちになってしまうのでワンオフのオブジェクトを管理させるのに抵抗が……
フレームワークによってはその辺りの管理戦略を分離している (ように見せかけている) ものもあったりするのかな。ありそう。
このアカウントは、notestockで公開設定になっていません。
GitHub で fork して、 PullRequest を閉じない前提で募っていけば自然とパッチカタログサイトになりそう
PullRequest に対象バージョンのタグを付けて検索性もまあまあ確保できそうだし、なんならトップページか別ブランチにインデックスを作ってもいい
あー、Component ごとにメモリ上の配置をどうするかみたいなのはありますね。少なくとも Bevy にはあった
bevy::ecs::storage - Rust https://docs.rs/bevy/latest/bevy/ecs/storage/index.html
> `Resources` - singleton storage for the resources in the world
ははー
