㌦ｲｸｿﾞｰ!

Wordle 255 5/6*

⬛⬛🟨⬛⬛
⬛⬛🟨⬛⬛
⬛🟩🟨⬛🟩
⬛🟩⬛🟨🟩
🟩🟩🟩🟩🟩

アホやらかした #Wordle

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

どうでもいいけど画面の半ばでフレームが変わってしまう方の tearing はテアリングやで。
テアの tear (動詞) は「裂ける」、ティアの tear (名詞) は「涙」で、別の単語。

“フューチャリング” (featuring のつもり) に近い何かがある

ちょっと不思議なんだけど、存在しない日付の前日というのは valid な概念なんだろうか。
「2022年2月29日の前日は2022年2月28日」が認められるなら、同じ理屈で「2022年13月1日の前日は2022年12月31日」が言えそうだけど。
2022-02-29 も 2022-13-01 も構文的にそれっぽいけど存在しない日付だし。

文脈:
https://twitter.com/girlmeetsNG/status/1498061116722851841
https://twitter.com/girlmeetsNG/status/1498063872116277249

存在しない日付の「前日」を認めると、「『前日の翌日』は必ずしも当日とは限らない」ということになるはずなんだけど、それって法文の他の部分や常識と整合する妥当な定義になっているのだろうか

「日付」が年を含まない month/date だけの概念とすれば……うーんギリギリいけるのか？

でも「日付」に年を含まないとして、その場合「3月1日の前日」は未定義になってしまうよね。だから「前日」をすべての valid な日付に定義するには、 年-aware でないといけないはず。

month/day の typo

もちろん 02-29 誕生日をうまいこと扱うロジックは作れるはずなんだけど、それって “ちゃんと定義” したら現状説明されているような理屈ではなく、もっと条件分岐を活用した何かになるはずだと思う

https://twitter.com/__pandaman64__/status/1498440402902216708

日付という集合の外側で演算して日付に戻してやるならうまくいく

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

それだとたとえば 2020-03-01 の前日が 2020-02-29 なやつとかに引っかかりません？

このアカウントは、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日だ

太陽暦はクソ
太陽を滅ぼせ

太陰暦がいいとは言ってねえ

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

思い出すシリーズだ

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

夏時間はクソ

というか「社会的」 CW で隠すのではなくハッシュタグを使うべきだったんだよな (今更)

まあ検索避けだと思って引き続きタグなしでいくか (最悪) (ミュートしづらい)

検索しづらさはそのままミュートしづらさでもある

(大嘘だったし、その次のﾂｲｯﾄも素朴な英単語のスペルミスってるし、そもそも他人の著作物を URI もなしに画像だけ転載してるしで、いろいろアカン雰囲気があったのでブロックした)

親、 †テレビで紹介† された †家庭の医学† とか †健康な食品† とかを真に受けがち (かつ自分では十分疑っているつもり) な感じなので、割と陰謀論とか嫌韓方面は警戒している

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

郵便や配送が信用できないタイプの国か……

try_reserve による fallible allocation が入ったのがつい最近 (1.57) というのはありそう

まあ std:🇮🇴:Read が固定長バッファに読むのが原則なのと近いものを感じるし、基礎的な API を panic-free にしたい的な意図は感じられる

イギリス領インド洋地域ではない

thread と io 、事故って flag になりやすいモジュールのツートップ

std:🧵:spawn
std:🇮🇴:Read

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

実は違って、 peek は与えたバッファサイズ分しか埋めてくれない

たぶん正しい戦略としては「自分で目標サイズを予想してバッファを resize し、拡張された領域に追加で recv をかける、これを満足するまで繰り返す」となりそう

まあ下手に Vec::extend とかの汎用的なバッファ拡張戦略を使うよりはアプリケーションやプロトコル固有の知識を活用してくれという話になるのはわかる

提案する価値はありそう。既にあるかもわからんが

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 の話だけど)

それならそれで fn size_hint() -> (usize, Option<usize>) みたいに無知 or 曖昧なサイズをヒントとして返す手はある

それならそれで Iterator::size_hint() -> (usize, Option<usize>) みたいに無知 or 曖昧なサイズをヒントとして返す手はある

実際これはあり

https://github.com/rust-lang/rust/blob/1.59.0/library/std/src/sys_common/io.rs#L1-L3

ちなみに BufReader のデフォルトのバッファサイズは 8 KiB

だったらクソデカバッファよりもバッファ拡張戦略を実装するほうが正しそう

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 パケット……

あーそうか、ペイロードが固定長なら順序を入れ替えた結合があってもちゃんと解釈できるし、固定長でないなら先頭とかでサイズを与えるか諦めてパースしろという話になるのか

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

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

骨に発熱してほしい人、ほのかにあたたかい放射性物質を骨に組み込みそうで危うい (???)

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

「メット」を「ヘルメット」として扱うの、無敵の再帰だ。 (λx.xxx)(λx.xxx) を感じる (?)

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

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

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

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

国内だと個人運営のアーカイブサービスになりそうだし、日本はフェアユースないから著作権周り危ういし、まあ無理そう

国会図書館が何かやってくれたら面白いとは思うんだけど >オンライン報道/ニュースサイトアーカイブ

Content Addressing の普及は夢のまた夢

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

そういえば AppFlowy 面白そうと思いつつ放置してるな、 docker-compose とかでｽｯと立つと楽なんだけど、進展どうなんだっけ (関連 issue を追いかけていたが閉じられた気がしている)

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

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

結婚とは国家に貞操を誓うことなのか - ブーバチカの呟き
https://buu245.blog.fc2.com/blog-entry-148.html

尖ってんなぁ

Steamのゲイブはメタバースの現状と人々に懐疑的。「あいつらMMOもやったことないだろ」「まずはラノシアへ行け」と斬る - AUTOMATON
https://automaton-media.com/articles/newsjp/20220228-193651/

> Newell氏が語ったのは、そうした技術の価値や将来性は認めつつも、流行りに乗った“金儲け”にはNOを突きつける姿勢なのだろう。

常識的！

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

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

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

ウクライナ大統領、ＥＵ加盟を正式申請 | Reuters
https://jp.reuters.com/article/ukraine-crisis-zelenskiy-idJPKBN2KX28T

プーチン「NATO 許すまじ」
　　　　↓
プーチン「誰だ！」
西側「EUです」
プーチン「よし、通れ！」

？？？

いや面白いけどさ (不謹慎)、そううまくいくものなのかね……

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

食のセンスと欲求が弱いので、
「体積だ！」つってオイスターソース味の焼きそばを作り、
「肉だ！」つってベーコンと生卵を追加し、
「草だ！」つってキムチを投入した。

完全食。

戦争が誰も幸せにしないとは限らなくて、とりあえず独裁者が勝てばそいつは幸せにすると思う。
ただ我々がそれを受け入れられないだけで。

そもそもの話をすると、戦争が誰かを幸せにするかどうかは戦争に反対する理由とは関係がない

またおたくが重箱陰キャムーヴしてる

フカヒレの「レ」って何のこと？