デ18ド(デスク下バキュームフェラけもみみメイド)
Posting kb10uy(@kb10uy@mstdn.maud.io)
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
夏稀の彼氏 さんのチェックイン (1月29日 22:44) - Tissue https://shikorism.net/checkin/18060
絵日記 2020-12-24(Thu) - 日下ファクトリー(Fantia 分館) (日下夏稀)の投稿｜ファンティア[Fantia] https://fantia.jp/posts/555837
SteamVR のメディアプレイヤーバカ重いしこっちなら SteamVR 立ち上げる必要ないからね
WinMR の環境はこんな感じにしてあるので簡単な画像アップロードとか設定はすぐにできるようになってるよ
This account is not set to public on notestock.
This account is not set to public on notestock.
そういえば Twitter のトレンド、なぜか Togetter も入ってますね
ぐるっと、最近は GLFW と GLEW がコア機能を担っててそれ以外は別のライブラリを併用する感じが強い
NT kernel でた後もいつまでも Apple のシステムソフトウェアはぐだぐだと昔のやつそのまま使ってて爆弾マーク！だったのでなんとか modernize しようとしてコケた挙句の NEXT 買収です
9x、MS-DOS が根底にはあるけれど一応 i386 のページング機構を使ってるので、MS-DOS ほど軽率に壊れはしないけれど
Win32 GUI、それ単体では別にそこまで分厚い抽象が存在するわけでもなく CLI のそれにイベントループがついたぐらいだったと記憶しているけど
9x 系は MS-DOS の上に立脚するモジュール群なのでもうあらゆる部分がワヤになってるから軽率に overrun するだけでシステムメモリが色々破損して終わる
あとエンドユーザーからすると GUI が応答なしになるでもなく普通に生きてたらそれは狂ってないと認識するのでは……
私は「OS によるプロセス実行を即座にやめさせろ」と言っているのではなく「汚染されたおそれのある実行文脈を破棄しろ」と言っているわけで、文脈が破棄されたあとメッセージを表示して終了するくらいの遺言は普通にあるべきだと思います
操作不能に陥ってはいけない、それはそうですが、ここでできるだけすぐに abort すればそもそも操作不能に陥る余地が極限まで減る訳ですよ
9x、さすがに詳しくは覚えてないけどカーネル周辺の機能死んだら死にっぱなしだったのかな
NT 系カーネル、その辺は堅牢な作りのようなので Wikipedia にもあるように些細なことでは発生しなくなったんだろうな
使えない何もしない GUI に生きてる意味なくないですか？(素朴な疑問)
NT 系だとドライバがケロッと再起動続行されるパターンもブルスクだったみたいなのがありそう
https://mastodon.cardina1.red/@lo48576/105635590784707044
もしかしたら私が OS 領域で死を発症させたことしかないからかもしれないな、もしかするとたまたま OS に傷が付かなかったらいくらかプロセスが巻き添えで死ぬだけで †平常状態† に戻れたりするのか……？
そういう意味だと物理層でバックアップ取ることはできるかも。例えば Word 開いてて、ブルスク起きちゃってそのまま終了するよりいったん画面だけ戻して写真撮っとけばファイルが破壊されてもいくらか希望があるじゃないですか
@kb10uy 最近 Intel MPK というの出てきて OS に活用する論文がちらほら出てきた（そういうのだとスレッド単位でメモリ刻むのもわりかし考えられる世界はある
もしやってくれてるとしたらそれこそ実はサブプロセスで実行されてたとかじゃない……？
少なくともアプリケーションの範疇ではメモリ・リソースのリークが起きてないというのは無理筋じゃない？
でも共有してるデータがどっかでスレッド死んだら毒を盛られてるので大概共死に
さっきのトゥート書いてるとき「あれ？Rust ってメモリ空間共有してるはずのスレッド単位で死ぬよな……」となった
これはややオフトピックなんだけど、仮にそのような汚染範囲をプロセスより細かく切るとして、メモリ空間共有してたら生きてるか怪しいと考えられるわけですよ。そこで仮想空間を切ったりすることを考えるわけですが、アプリケーション側にそんな采配が可能なのだろうか
(もちろんそういう OS を設計すればいいがそれは違う話なので)
まあ Rust ではスレッドが panic しても親スレッドが巻き添えくらわないけどそれはランタイムのデザインがそうなっただけだと思っていて、「破棄されても問題ない領域の隔離」としてプロセスを単位とするのはとても妥当な設計ではないでしょうか
結局の所「その手のエラーについて、『復帰したり適切にするべき』とは言うけど実際できるかというとほぼ無理ですよ」に帰着します
で、「一部の (意味ある) 値の参照が許されなくなったけど続行してね！」というのは通常不可能なので、文脈そのものを破棄するというデフォルトは合理的でもあるわけです。
そうしないオプションが提供されているとしても、デフォルトでは文脈の破棄になるのは妥当。
仮に信用を置いてる仕様が破られていることが判明したとして、そもそもそこから(スレッド内で)復帰したり丁寧にエラー処理をするべきなのか、そもそもできるのかという認識が食い違ってそう
freestanding environment の場合は知らんがまあ大体 nop loop とかに行くと思う
それこそ OS が残ってるファイルハンドルとかメモリ領域を始末してくれるわけで多重システムとみなせないですか？
ファイルの処理で行くと、例えばファイルを開いてる途中に JVM が狂ってしまったとして、コード側ではどこかが狂ったということはわかっても JVM が、というのがわかるとは限らないし、そんな状況だったら finally 節が実行されるかも怪しいですよ
いや検査とか非検査とかはここでは本質ではなくて、「非検査例外が発生するような状況で実行が継続されることがおかしい」と主張すべきですね私は
あとは突然クラッシュしても最悪 OS が後始末をやってくれるでしょうみたいな別種の信頼もありそうだよな
例えばファイルを扱う処理であれば、言うまでもなく途中で何らかの理由不明な問題が起きたらとりあえずファイルを閉じるだけはする処理は書くかも＞＜
ていうかそれ否定したら例外方式の環境のfinally節は何のためにあるんだよって事になるかも＞＜
つい癖で IOOBE と言ってしまったが普通に境界外アクセスという言葉があった
Java の仕様で Rust っぽくエラーを処理しようとすると panic 以外全部検査例外みたいなもんでしょ 死ぬわ
ファイル保存するの失敗したけどまあいいか
ファイルなくて開けんかったけどまあいいか
ファイルの内容設定されてなかったけどまあいいか
設定値虚無だけどまあいいか
虚無と演算して失敗したけどまあいいか
の連続はさすがに明らかに狂ってるでしょう
ハナっから信用してない部分で裏切られる分にはまあエラーログなりデフォルト値で対処すれば良くて、信用を裏切られたらそれ以上続けようとしたところでろくなことにならないんだからさっさと死のうやという以上の説明を思いつかない
全行全命令で検知できるようにとは言っていない＞＜
内部を適切に分割していけば、その分割単位ごとにその部分がコケた時の対処ができるでしょ？＞＜ って言いたい＞＜
なんで一ヶ所コケた時にプロセス単位でしか考えないのか？＞＜ って言ってる＞＜
極端な話メモリ全部食い潰して仕様が破れて死にかけてるのに余計なことができるかよ、と
仮に信用を置いてる仕様が破られていることが判明したとして、そもそもそこから(スレッド内で)復帰したり丁寧にエラー処理をするべきなのか、そもそもできるのかという認識が食い違ってそう
さすがに panic だって何のせいで panic に陥ったかは表示して死ねるわけだし……
当たり前だけど panic のときに本当になにもせず abort() しなければならないわけではないですよ
それ以上続けようとしたところでろくなことにならない、というのはまさに On Error Resume Next の例が顕著で、あれがまともに機能する例なんてまずないでしょう
ハナっから信用してない部分で裏切られる分にはまあエラーログなりデフォルト値で対処すれば良くて、信用を裏切られたらそれ以上続けようとしたところでろくなことにならないんだからさっさと死のうやという以上の説明を思いつかない
その例で言うと、狂ってるのは42に1を足す処理の部分か計算機そのもののどちらが狂ってるわけであろうから、その部分をスキップさせてエラーを通知して出来る限り穏便に済ませる処理を書くか、計算機をシャットダウンさせる処理を書くべきかも＞＜
単位がアプリケーションというかプロセスって発想ってモノリシック的かも＞＜
確かに「非同期処理の結果を最初にチェックしたときにもう終わってるか」問題でもあるな
次のページを読み込むとして、次のページをフェードインさせるまでに完了するかしないかで Suspense の行く末が決まるみたいなのでいいんかな
現ページフェードアウト(次ページfetch)
次ページを表示しようとしてみる
→もう取れてた
→→そのままフェードインして表示
→まだ取れてなかった
→→ 
→→Suspense で fetch 完了まで待つ
→→Promise resolve 後に今度こそフェードイン
あーでもそうか、cDM タイミングではなく Promise で包んで渡せるから一応レンダーサイクルとは分離できてるのか
@azyobuzin 
(さっきスレッドを持ち出したのは UI と関係ないタイミングで処理のハッカを蹴ってやろうと思うとそうせざるをえないだろうかと思ったためです)
CPU と GPU ぐらいがっつり分離できるといいんだろうけどどだい無理な話ですわね
@azyobuzin ルートになる DOM と同時にスレッド立てて UI スレッド側にキューをもたせてやれば……とおもったけどこれだとグローバルステートを要求するのか……
なんというかもし UI スレッド以外に処理専用のスレッドを立てられてたらここまでライフサイクルで四苦八苦することもなかったのではという気がしている
「設定ファイルに a しか書いてなかった」と「デシリアライザーサイのポカで a しか入ってないのを返しちゃった」が区別がつかないのではみたいなのはなんというか動的型付けっぽい観点な気がする
レンダリングのサイクルとロジックのタイミングをうまく分離できないというあたりに出発点があったということであってる？
Suspense は、グローバルステートストアを使わずに非同期処理をやりたいときに、みんな componentDidMount のタイミングで処理開始させてて 1 ループ分無駄じゃん、Promise 先に作れよって話から発生した要件。 Promise は resolve されてるかを判定する方法を持っていないので、普通に return されたら今すぐレンダリングしていいかわからないから、別の脱出口を作ってねってことで throw になったんだろうな
React 、一見全然コードスタイルが変わらないのに過去のライブラリがことごとく使えなくなるような破壊的変更をぶちこんできたら面白いな
もう一度 render するという挙動、よく考えたらめちゃくちゃ互換性意識してそうだな
Promise が resolve したらもう一度 render が呼ばれるだけなので、中身なんも関係ない。 Suspense / Hooks が Algebraic Effects だって話は、実際のところ継続を外部に漏らす必要があってどう見てもクロージャ―を爆破させることになるので、ちゃうやろというお気持ちです
僕にはどうもあの Suspense の能書きは腑に落ちないところがあって、なんで継続っぽいものを返せて継続っぽく処理できるんだ？という疑問をずっと抱いている
あれって throw から拾った Promise はそのまま await するだけで中身出てくるんだっけ……
デリゲートが便利にできればまあそれでもいいのではという気もするが、React の「throw で結果を返すのは果たして意味論的に大丈夫なのか」という議論を思い出して何もわからなくなる
継続、asyncでも例外でもコルーチンでもなんでもできるすごいやつぐらいのイメージしかない
Algebraic Effects、使い方が例外ハンドラ or デリゲートでしかなくて、逆にそれ以外の使い方されたら関数名が持つ名前的意味を破壊するだけの存在になるから微妙な目をしてみています
僕がよく出す例はコルーチンを使って
for 50 times
move_forward;
yield;
みたいなコードでアクターを協調的に 50 歩動かすみたいなの
どちらかというとコルーチンを上手く使うと実装できるみたいな感じっぽいですわね
This account is not set to public on notestock.
これちょうど Seaurchin のリポジトリを private にしたときに発生した
This account is not set to public on notestock.
Rust がマクロでどこまで正気を保てるような構文拡張ができるかを探索するのかなり楽しそうなんだよな
NeedsDefaultValue みたいな効果をよこすように定義しておいてさ
こういう例で、再帰限界に来たのでデフォルト値がほしい、みたいな挙動は確かに algebraic effect と専用の構文でけっこういい感じに対処できそうなんだな
あとデフォルト値をデシリアライザに渡すのは……ちょっと caller 側の責任をライブラリに押し付けすぎな気がしていて、たとえば特定の状況で再帰的にロードが発生して云々みたいなデシリアライザがデフォルト値を把握していないとエラーを無視できない状況であればそういう仕様にするでしょうけど、そうでないならデフォルト値の設定は caller 側が責任を持つ方が妥当な気がする
デフォルト値を読み込み関数に渡してしまうの、バリアントが増えすぎてあまりよくなさそう(オーバーロードがある言語だとそうでもないが)
non_exhaustive はなんかこう serde でうまく組合せると未知の通知で落ちるシリーズをいくらか防げそう
検査エラーには Checked trait を実装して Result で E: !Checked にするみたいな
そういえば Rust で marker trait がユーザー側で生やせるようになったら必ずチェックしないといけない Error みたいなの表現できるのかな
網羅性はなんかこう静的ディスパッチとのバランシングっぽい側面があるわね……
まああれも「発生しうるエラーの種類を列挙するのが難しい (何故なら代数的データ型がないので)」の結果な気はする
検査例外でも union でもそうなんだけど、一体抽象層がどれだけ具象層の例外パターンを網羅しなきゃいけないのかって思うとマジでしんどくて、異常がシグネチャに含まれるってそういうことなんだぞって気持ちになる。
もうちょっと flatten されててもええやんと思う(が enum がそれなりに強力じゃないと厳しいな)
あー、なんかこう無駄に階層付けられてるエラー状態は本当にそこまで階層付ける必要があるのか？みたいな話です
Exception クラスまわり、継承関係のせいでピンポイントで潰したい例外を調べづらいというのちょっとないですか
と思って調べたら Majestouch でも工具付いてるの BLACK/NINJA だけだったわ
シリアライズといえば PHP のシリアライズは専用形式だけど直接型が復元できるのでえらい
普通に毎回マイグレーションファイルを生やすのが好み(これはクエリビルダでも生 SQL でも良い)で、なんかこうある程度の数がたまって安定してきた部分を squash する機能があるとうれしい気がする
そういえば僕が嫌いな ORM 実装として「スキーマを単一ファイルに書いて編集すると勝手に差分を検出して ALTER TABLE などを実行する」というのがあります
Java のアノテーション芸どこまでなら一般的に許せる範疇なんだろうなあ
そういえば大昔にｼﾞｬｯｳﾞｧで型とかフィールドにアノテーション付けまくると DB スキーマが生えてくる感じのフレームワーク使ったことがある気がするな。まあ私そのフレームワーク嫌いだったんだけど、DB との統合としては筋は悪くなかったと思っている
あくまで enum 関連の話で思い出しただけなのであんまりきにせんでもろて
RDBMS でも組み込みの ENUM 使うより別テーブル立てて外部キーで指したほうが後々便利だし安全ということが言われている
今度から Java 書くときは com.smbc パッケージにすることで世界を震撼させていきたいと思います
Qiita はたまに「謎の記事が新着にやたら生えててユーザーを確認したらどっかの学生だった」という事例がある(1 日ぐらいで対処されるのであんまり残らない)
Qiita の怪文書といえば administrator1974 ですよ
Wikipedia はまあ新着記事にそんなに重きがなさそうだからまだマシかもしれんが……(どちらにしてもレビューが必要なのはそう)
Qiita とか GitHub でなんか立てようみたいなキャンペーン・課題の類、本人たちにそれほど悪気がなさそうなのがたち悪いんですよ
Wikipedia の加筆課題、Qiita に謎記事が乱立するあれを思い出すな
This account is not set to public on notestock.
