IEEE754自体に依存してると言うより、プラットフォームがNaNをサポートしてないとPython側で吸収しないといけないのがつらいという話っぽい https://github.com/python/cpython/commit/1b2611eb0283055835e5df632a7a735db8c894b8

構造体をnewしてコンストラクタで初期化するみたいな気持ちは理解するのに結構時間がかかった記憶がある

thisはレシーバが渡される暗黙の変数ですって言えば済むことなのに、2000年頃の教本は（今もかもしれんが）そういう説明がまったくなかった

最近の若者はPythonとかRustとか書いてるから自然にまあそういうもんでしょってなるのかな

たぬきち起きとんのかワレ

ふぇのまーさんにmikutter Discordの管理者権限付与してから寝て

寝込んでたんか　お大事にワレ

@toshi_a rootロール付いてるよ

<script>window.alert("てお")</script>

Mastodonのポストってどのレベルでサニタイズされてるんだろ

<font size=1000>Mastodonのポストが投稿時点でサニタイズされてるのか、それとも表示時点なのかいまいち分かってない</font>

Mastodon API叩いてる限りはエンドユーザはsanitizedなHTMLしか見ないと思ってよさそう https://docs.joinmastodon.org/api/guidelines/#formatting

Mastodonから普通にポストすると<br>とか書いても<br>って見えるからまずここでエスケープが走っていそう（つまりMastodonからはHTMLを通常の手段では配信できない）

やっぱり自分でAP実装作ってertona.netに危険HTMLをぶちこまないと……

トゥルーエンド見てないの

とはいえトゥルー覚えてないな……

アオイチャン4mってマジ？

フィリスが立派な錬金術士になってエルトナに帰ってきただけでもうトゥルーエンドだよ

このアカウントは、notestockで公開設定になっていません。

エルトナ（意味深）ってなんやねん

エルトナは鉱山の村かしばふのサーバの2択しかない

まいにゅーぎあ

どこか行きたいけど宛てがない

@choro3 行きたい

労働もカスだよ

そろそろ労働について真面目に考えないといけない

人生もな

週3労働よりも週5で3ヶ月働いて1ヶ月休みみたいなパターンの方がいいのでは？と思ってきた

importしたものをprefixなしで使われるとIDEの支援なしに追うのがかなり困難になるのでやめてほしい

そういう点でGoのimportはかなり偉いんだよな。必ずnamespace付きじゃないと参照できないし、importしただけでコードが走って副作用を及ぼすこともない。Rustも後者が微妙だけどそこそこ良い

Goはgo fmtがカラム揃えを強制してくることといい、コードは書く時間より読まれる時間の方が圧倒的に長いんだから読みやすさに振るのが正義という強い思想を感じる

大抵型はトップレベルに展開されるので、import自体に型推論含めてなんの副作用もない言語の方が珍しいとは思う。JS / TSはnamespace強制なのは素晴らしいのに副作用のせいでimportの順序すら自動で並び替えできないのが……

実際importの順序シャッフルしたら壊れるコードがどれくらいあるんだろうという話ではあるが

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に置き換えるような最適化が起きてもおかしくない気がする）

unsafeがどれくらいunsafeなのか知りたいんだけどそういうことを書いてあるドキュメントが見つからない

unsoundなのはいいとしてその帰結がどうなるのか分からん。unsoundなコードはどう壊れても文句を言えない？

というかコード全体で&mutは1つしか存在してないと思うんだけど

あと&mutを2つ以上生やすだけでおかしくなるならThe bookの例もダメということになりそう https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#creating-a-safe-abstraction-over-unsafe-code

「コードが満たすべき性質」がなんなのかが分からん。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

split_at_mutの第一引数は&mut [i32]だけどこれでr食われるの？

あーーーーなるほど

@qnighy なるほど一理ある……。時間があったら読んでみます。とはいえ本当にやりたいのはView typesがないことによるエラーの迂回なのでそっちが一段落してからにします

こういうのがコンパイル通らないの本当に困ってるんだけど、Gameをimmutableな部分とmutableな部分に分割して常にバラバラに持ち運ぶしかないのかな……
struct Game {
players: Vec<i32>,
score: i32
}

fn add_score(game: &mut Game, player: i32) {
game.score += player;
}

fn play_turn(game: &mut Game) {
for player in game.players.iter() {
add_score(game, *player)
}
}

関連があるデータの意味でstructに入れた瞬間にmutabilityに関しても運命共同体になるのがとても厳しい

タプルにすらできない強く関連した2つの変数をあちこちに引き回さないといけないの、かなり気持ち悪くない？

皮膚日光浴

東京脱出しな

ECS is 何

こういうのか https://zenn.dev/suuta/articles/0aa567690ec52a

ナイーブにやるとComponent poolがさっきのGameになって同種の競合が発生しそうな気がするけど大丈夫なんかな

結局状態更新の時にimmutableに触られるものとmutableに触られるものをComponentで切り分けることにはなるが、Entityを通した間接参照の形でグループ化できるからちょっとはマシくらいか

これって要するにメモリアロケータを作ってるのでは？まあガチのゲーム開発なら必要だけど……

特にゲームとして考えると、インクリメンタルに状態を更新するよりも「現在の状態」をimmutableに固定したままで「次の状態」を別のバッファに書き出すようにしたほうが、処理順の違いで結果が変わるみたいな現象が発生しづらくていいという面があるのでmutableな状態を特に分離して持っておく設計は妥当な気もしてきた

アトリエやったことない人におすすめするなら今はライザ一択なんだよな

ライザ1は良くも悪くも王道RPGの作りなのでかなりとっつきやすいし面白いですよ

ライザは分岐ないよ

フルート攻撃

アニメのクラウディアが弓使いになってたの許してないよ

ライザと冒険に出たい！ってなってから弓の練習し始めておいお前……まさか……ってなった

やっぱりフルートで戦うのはどうあがいても狂人だからな

盗賊を殴り殺すロロナ
銃弾を握り締めて殴るくーちゃん
フルートを投げるクラウディア

生産緑茶とは

クソコラ生産マシンと化したとしぁ

smhnユーザは弾いてなかったっけ

今日なんもできてない

チケットあるんですか

なんか回線が不安定でsshが安定しない

ていうか今ちゃんとmikutterが動く環境が……

@teobot Rustでn要素の0からなるVecを作る方法を教えて