㌦ｲｸｿﾞｰ!
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
#Wordle 254 (2022-02-28) hard mode 解答
先に形容詞形 (しかも y) を試したのマジで思考停止してた
This account is not set to public on notestock.
どうでもいいけど画面の半ばでフレームが変わってしまう方の tearing はテアリングやで。
テアの tear (動詞) は「裂ける」、ティアの tear (名詞) は「涙」で、別の単語。
“フューチャリング” (featuring のつもり) に近い何かがある
ちょっと不思議なんだけど、存在しない日付の前日というのは valid な概念なんだろうか。
「2022年2月29日の前日は2022年2月28日」が認められるなら、同じ理屈で「2022年13月1日の前日は2022年12月31日」が言えそうだけど。
2022-02-29 も 2022-13-01 も構文的にそれっぽいけど存在しない日付だし。
存在しない日付の「前日」を認めると、「『前日の翌日』は必ずしも当日とは限らない」ということになるはずなんだけど、それって法文の他の部分や常識と整合する妥当な定義になっているのだろうか
「日付」が年を含まない month/date だけの概念とすれば……うーんギリギリいけるのか？
でも「日付」に年を含まないとして、その場合「3月1日の前日」は未定義になってしまうよね。だから「前日」をすべての valid な日付に定義するには、 年-aware でないといけないはず。
month/day の typo
もちろん 02-29 誕生日をうまいこと扱うロジックは作れるはずなんだけど、それって “ちゃんと定義” したら現状説明されているような理屈ではなく、もっと条件分岐を活用した何かになるはずだと思う
https://twitter.com/__pandaman64__/status/1498440402902216708
日付という集合の外側で演算して日付に戻してやるならうまくいく
This account is not set to public on notestock.
それだとたとえば 2020-03-01 の前日が 2020-02-29 なやつとかに引っかかりません？
This account is not set to public on notestock.
「『2022-02-29の前日』は『2022-02-28』だから」なんて理屈はなくて、「該当する日が存在しないからその月の月末」みたいになってる
結論:
https://mastodon.cardina1.red/@lo48576/107878250311360857
民法第143条 - Wikibooks
https://ja.wikibooks.org/wiki/%E6%B0%91%E6%B3%95%E7%AC%AC143%E6%9D%A1
こういうしょーもないことにうるさいオタクだから孤独なんだよな
エンバグして時間を浪費するよりはマシ (ほんまか)
「1年後」を「365.2422日後」で定義する話は……
ミスった、これは修正ユリウス暦か。
グレゴリオ暦は365.2425日だ
This account is not set to public on notestock.
いっぽう1日以上の時間は未定義
> There is no definition for units of Day or larger to avoid confusion across daylight savings time zone transitions.
https://pkg.go.dev/time
というか「社会的」 CW で隠すのではなくハッシュタグを使うべきだったんだよな (今更)
まあ検索避けだと思って引き続きタグなしでいくか (最悪) (ミュートしづらい)
検索しづらさはそのままミュートしづらさでもある
(大嘘だったし、その次のﾂｲｯﾄも素朴な英単語のスペルミスってるし、そもそも他人の著作物を URI もなしに画像だけ転載してるしで、いろいろアカン雰囲気があったのでブロックした)
親、 †テレビで紹介† された †家庭の医学† とか †健康な食品† とかを真に受けがち (かつ自分では十分疑っているつもり) な感じなので、割と陰謀論とか嫌韓方面は警戒している
This account is not set to public on notestock.
郵便や配送が信用できないタイプの国か……
そうそう、 Python から C# に移ったということで気をつけたほうがいいのは、他の静的型付け言語のように配列や List<T> が homogenous ということです
結局 Rust の UdpSocket が Vec を拡張するように受け付ける関数がないのは規格上最大サイズの 64KiB のバッファを用意しろということなのかな
try_reserve による fallible allocation が入ったのがつい最近 (1.57) というのはありそう
まあ std:🇮🇴:Read が固定長バッファに読むのが原則なのと近いものを感じるし、基礎的な API を panic-free にしたい的な意図は感じられる
thread と io 、事故って flag になりやすいモジュールのツートップ
std:🧵:spawn
std:🇮🇴:Read
prime@mstdn.poyo.me
This account is not set to public on notestock.
実は違って、 peek は与えたバッファサイズ分しか埋めてくれない
たぶん正しい戦略としては「自分で目標サイズを予想してバッファを resize し、拡張された領域に追加で recv をかける、これを満足するまで繰り返す」となりそう
UDP header に入ってるサイズ情報とは別にアプリケーション層でサイズ情報を用意して、最初の数 byte にサイズを入れ、それだけ peek してそのあと改めて拡張して recv とかかな
まあ下手に Vec::extend とかの汎用的なバッファ拡張戦略を使うよりはアプリケーションやプロトコル固有の知識を活用してくれという話になるのはわかる
でもせっかく UDP header がサイズ情報を持ってるんだからこれを活用したい感はあるんだよねえ
提案する価値はありそう。既にあるかもわからんが
https://docs.rs/tokio/1.17.0/tokio/net/struct.UdpSocket.html#notes
> On Windows, if the data is larger than the buffer specified, the buffer is filled with the first part of the data, and peek_from returns the error WSAEMSGSIZE(10040). The excess data is lost. Make sure to always use a sufficiently large buffer to hold the maximum UDP packet size, which can be up to 65536 bytes in size.
Windows だと何か問題あるっぽいな…… (これは tokio の話だけど)
underlying implementation 的にヘッダに入ってるサイズを取るのが無理なことがあるとかそういう話なのかもしれない
peek_size() -> Result<usize> みたいなのを生やせるかという話よねえ
それならそれで fn size_hint() -> (usize, Option<usize>) みたいに無知 or 曖昧なサイズをヒントとして返す手はある
それならそれで Iterator::size_hint() -> (usize, Option<usize>) みたいに無知 or 曖昧なサイズをヒントとして返す手はある
でもそこまでするぐらいだったら初動の受信だけは 64KiB 固定で確保して capacity 指定した上でコピーしたほうがマシではという気もしてくるわね
https://github.com/rust-lang/rust/blob/1.59.0/library/std/src/sys_common/io.rs#L1-L3
ちなみに BufReader のデフォルトのバッファサイズは 8 KiB
元々は OSC の送受信で UDP を使うという文脈で、1 メッセージあたり数十 byte しかないので規格上最大までバッファ確保するのはややムダではないかという思いがあったんだよな
だったらクソデカバッファよりもバッファ拡張戦略を実装するほうが正しそう
あそうか、Ok(read_length) に対して buffer_length >= read_length になる地点で停めればまあ最小限の拡張で済むのか
Vec とかは汎用なので「足りなければ r 倍に増やす (r は1.5 とか 2 とか)」みたいな実装になりがちだけど、プロトコルの知識があればそこをもう少しうまくやれない？ という
もちろん場合によりけりだけど。まあ無理なら無理で素直に同じような戦略を再実装すればいい
あとこれは単純に私の UDP 知識不足なんですが、 UDP のソケットでパケット境界を利用したデータ受け取りってできるんですか (単なる非同期ストリームとして抽象化されると思ってた)
たとえば小さなパケットを2つ連続で受信したら、こちらからのサイズ指定なしにわざわざ1つ目のパケットだけ分割して受け取るってできるのか？
いやしかしまてよ、順序の制御がないなら勝手に結合されると困るのか
わからんな…… std::net::UdpSocket は packet-aware な API に見えないんだが
User Datagram Protocol - Wikipedia
https://ja.wikipedia.org/wiki/User_Datagram_Protocol
> IPv6のジャンボグラム機能では、65,535バイトを越えるサイズのUDPパケットを扱える[5]。この場合、IPv6のオプションヘッダでサイズを指定し、最大4,294,967,295バイト（232 - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。
4GB の UDP パケット……
あーそうか、ペイロードが固定長なら順序を入れ替えた結合があってもちゃんと解釈できるし、固定長でないなら先頭とかでサイズを与えるか諦めてパースしろという話になるのか
UDP 自体がセグメントで分かれるみたいな仕様ではないけど IP レベルでのフラグメンテーションは OS 側で勝手に再結合されるみたいな感じっぽいですね
This account is not set to public on notestock.
骨に発熱してほしい人、ほのかにあたたかい放射性物質を骨に組み込みそうで危うい (???)
「メット」を「ヘルメット」として扱うの、無敵の再帰だ。 (λx.xxx)(λx.xxx) を感じる (?)
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
国内だと個人運営のアーカイブサービスになりそうだし、日本はフェアユースないから著作権周り危ういし、まあ無理そう
国会図書館が何かやってくれたら面白いとは思うんだけど >オンライン報道/ニュースサイトアーカイブ
Content Addressing の普及は夢のまた夢
そういえば AppFlowy 面白そうと思いつつ放置してるな、 docker-compose とかでｽｯと立つと楽なんだけど、進展どうなんだっけ (関連 issue を追いかけていたが閉じられた気がしている)
prime@mstdn.poyo.meThis account is not set to public on notestock.
This account is not set to public on notestock.
Steamのゲイブはメタバースの現状と人々に懐疑的。「あいつらMMOもやったことないだろ」「まずはラノシアへ行け」と斬る - AUTOMATON
https://automaton-media.com/articles/newsjp/20220228-193651/
> Newell氏が語ったのは、そうした技術の価値や将来性は認めつつも、流行りに乗った“金儲け”にはNOを突きつける姿勢なのだろう。
常識的！
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
ウクライナ大統領、ＥＵ加盟を正式申請 | Reuters
https://jp.reuters.com/article/ukraine-crisis-zelenskiy-idJPKBN2KX28T
プーチン「NATO 許すまじ」
↓
プーチン「誰だ！」
西側「EUです」
プーチン「よし、通れ！」
？？？
いや面白いけどさ (不謹慎)、そううまくいくものなのかね……
This account is not set to public on notestock.
食のセンスと欲求が弱いので、
「体積だ！」つってオイスターソース味の焼きそばを作り、
「肉だ！」つってベーコンと生卵を追加し、
「草だ！」つってキムチを投入した。
戦争が誰も幸せにしないとは限らなくて、とりあえず独裁者が勝てばそいつは幸せにすると思う。
ただ我々がそれを受け入れられないだけで。
そもそもの話をすると、戦争が誰かを幸せにするかどうかは戦争に反対する理由とは関係がない
またおたくが重箱陰キャムーヴしてる
