ブッシュっぽさ＞＜
"(機械翻訳)トランプ大統領は英国が核保有国であることに気づいておらず、かつてフィンランドがロシアの一部であるかどうか上級補佐官に尋ねた"
John Bolton: White House makes last gasp bid to stop book's release - BBC News https://www.bbc.com/news/world-us-canada-53089614
ブッシュっぽさ＞＜
"(機械翻訳)トランプ大統領は英国が核保有国であることに気づいておらず、かつてフィンランドがロシアの一部であるかどうか上級補佐官に尋ねた"
John Bolton: White House makes last gasp bid to stop book's release - BBC News https://www.bbc.com/news/world-us-canada-53089614
elite dangerousやればわかるけど銀河系って超でかいよ＞＜
「地球が存在する銀河系には少なくとも36種類の知的生命体が存在する」という主張 - GIGAZINE https://gigazine.net/news/20200618-alien-civilization-36/
KISS原則の話少しやってた＞＜
https://mstdn.nere9.help/@orange_in_space/104365347309922511
みた＞＜
「はやぶさ2のライバル オシリス・レックス最新報告」 - コズミック フロント☆NEXT - NHK https://www.nhk.jp/p/cosmic/ts/KWRKNGPXZV/episode/te/WV5M1JWGR3/
This account is not set to public on notestock.
少なくとも函館駅はホームが曲がってて端頭式ホームの奥に停車させるせいで、出発時に最初の色灯式信号は見えないっぽい＞＜
函館の全面展望動画いくつか見てみたけど、歓呼聞こえなくてこの先が場内なのか出発なのかわからない＞＜；
これはどうなんだろ？＞＜
118 JR函館駅の「中継信号機(灯列式)」。: 北の鉄ちゃんの部屋 https://231108.at.webry.info/201401/article_33.html
出発信号の予告信号もしかしてこれ？＞＜
File:Hanshin Railway Repeating Signal.jpg - Wikimedia Commons https://commons.wikimedia.org/wiki/File:Hanshin_Railway_Repeating_Signal.jpg
？＞＜(？)
出発反応標識 - Wikipedia https://ja.wikipedia.org/wiki/%E5%87%BA%E7%99%BA%E5%8F%8D%E5%BF%9C%E6%A8%99%E8%AD%98
出発信号機を中継しないといけない状況、運転士が先頭にいない、運転士が下か上に固定でいて車両に乗っていないケーブルカーとか？
スマホアプリ版が多機能で、音声のみの専用ハードが活躍出来る隙がなさそう＞＜；
音声ガイドアプリ【多言語対応】美術館・博物館・観光地に│アコースティガイド・ジャパン https://www.acoustiguide.co.jp/app/
可視光で通信するやつあったね。（記事内の画像が全然でない）
水中レーザー無線LANの海洋試験成功。海洋調査、防衛にも活用 | Optinews
https://optinews.info/2017/10/31/water-laser-lan/
つまり美術館とかの照明をそれにして、展示物の前の天井にある照明がそれぞれデジタル可視光通信というか可視光放送？＞＜； で、展示物の解説音声を流してて、受信ヘッドホンして展示物見回るとその場ごとの説明が聴けるってシステム＞＜
可視光式にすればたとえば美術館の案内とかを聴けるシステムで部屋ごとに放送内容変えるとか簡単に出来る＞＜
(可視光じゃなくても出来るけど＞＜；)
赤外線FMワイヤレスヘッドホンって昔いっぱいあった(今も？)けど、可視光LED照明デジタルワイヤレスヘッドホンって無理なのかな？＞＜
電球の光を観察すれば、25メートル離れた場所の会話が盗聴できる。イスラエル | スラド ハードウェア https://hardware.srad.jp/story/20/06/17/1459218/
なんでないのかというとたぶん両方にするとGCが複雑になるのと、さっき書いた通り、みんな使い分けを理解できず即時実行デストラクタの方に終了処理全部書いちゃうだろうと思われてるからだと思う＞＜；
かなり前にツイッターでGC関連の話題が盛り上がった時に、
GCと、スコープが外れた瞬間に呼ばれるデストラクタの両方がある言語って無いの？＞＜
ってちょっと盛り上がったけどそういうの無いらしい＞＜
(遅延実行デストラクタと即時実行デストラクタの二段構えな環境＞＜)
オレンジはそう考えてて、スコープ外れた瞬間にデストラクタが呼ばれる特殊な参照カウンタインタフェース実装して欲しいって前から言ってる＞＜；
ただし、さっき書いたようにそうするとそればっかり使う馬鹿が現れて極端にパフォーマンスが落ちる事態も起きそうだし、たぶんそれを危惧してるのでDelphiにはあったのにC# には受け継がれなかったんだと思う＞＜；
GC が適用される型と適用されない型を分けるとか、 GC されるハンドル型とされないポインタ型を分けるとか、なんか他にやりようあるんじゃないの？ と思ってしまう (まあやった結果として駄目な API が完成したのかもしれないけど、それは単に失敗しただけでは)
そもそもいわゆる高度な GC が本質的に非決定性を抱えているものなので、その上に決定性のあるリソース破棄を実装しようというのが「？」という感じ (いや GC を最後の砦にしたい気持ちはわかるけど)
GUIのリソースはだいたい明示的なタイミングで解放するほうがパフォーマンスが良いもの＞＜(短く説明するの難しい＞＜)
「なんでもかんでも毎回リソース解放してたらパフォーマンス悪い」
↓
GCだ！
↓
「でも、少数派ながら長期間抱え込むと逆にパフォーマンスに悪影響があるリソースもある」
↓
IDisporsableだ！
↓
「でも、明示的に解放するの忘れたらどうしよう」
↓
GCがいつか呼ぶデストラクタで解放されるので一応ある程度安全(でもパフォーマンスは低下するのであくまでフールプルーフ)
それ GC まわりの設計の問題では (GC 詳しくないけど、 GC レスなマトモな言語でそういう問題起きないので)
「取っ付きやすさは後からどうにかできるが、デザインや哲学は簡単には変えられない (というかそこを弄るなら別物を作り直した方がいい)」という思想なので、何はともあれ一番重視するのは哲学です
逆に言うと、いつ解放してもほとんど問題がないであろうリソースにはIDisporsableは使わない＞＜ 明示的に解放しなければ問題があるので問題がある場面で使われている＞＜
C# がスコープによる参照カウントの仕組みを用意しなかったのは、そうするとたぶん不適切な場面でも参照カウンタによるデストラクタ呼び出しを多用されまくられて、GCの遅延実行がほとんど機能しなくなって(しかもC# の方式では参照カウンタは処理が余計に必要だろうし)パフォーマンスが極端に落ちることを危惧したんだと思う＞＜
https://homoo.social/@204504bySE/104364240471817593
の通り、いつかはデストラクタが実行されて解放される＞＜
ただしいつ実行されるかはGCのお気持ち次第で、それまでは無駄にリソースを食い続ける＞＜
そして、IDisporsableは、ある時点で明示的にリソースが解放されるべきものに使う仕組みで、つまりそれは明示的にリソースがされるべきもの＞＜(たとえばグラフィック関連のものであればもうこれは描画に使用しないとするタイミング(や一通りの処理が終わったタイミング)で解放されるべきもの＞＜)
@orange_in_space IDisposableを実装するクラスは、デストラクタ内でもDisposeを呼ぶことが求められている(コンパイルエラーは出ないが) つまり自分でusingしなくてもそのオブジェクトがGCされるときにアンマネージドリソースも開放される。
それはそうだけど、(たぶん)パフォーマンスを考えてあえてそうなってて、その上で、
「忘れてた」ときに問題が起きるデザイン自体が error-prone であると形容される人間に優しくないデザインそのものなのではという感想しかないです……
ていうか、C# のお勉強の課題でIDisposableなものをDisporse忘れ(using忘れ)してたら減点対象にするのが普通だと思うけど違うの？＞＜；
あとJavaも含めてfinallyを使うべき場面で使ってないとか＞＜
自信なくなってきた＞＜
多重化して多層にするの大事だし、ぶっ壊れた！→全停止 ってするのが安全な分野は限られてる＞＜
危険な部分だけきれいに止まれるようにも多重化＞＜
実際の飛行機に限った話というか、毎度お馴染みエアバスA320＞＜； の話で言うと、
オートパイロットが壊れたらオートパイロットが無効になるはその通り＞＜
一方でA320系は多重フライバイワイヤな飛行機で、高レベルの操縦システムが壊れたら1段下に落ちるようになってる＞＜
一番下まで落ちると非常用の直接操縦するモードになって、直接舵を操作することになる＞＜
このモードはプロテクションもフィードバックもなくとても操縦が難しいらしく危険で、ほんとのほんとにダメもとになってる＞＜
一番上の通常の操縦システムが壊れても、もちろんAPが壊れた程度でも、いきなり一番下の危険なモードには落っこちない＞＜
This account is not set to public on notestock.
This account is not set to public on notestock.
C++にはちゃんとスコープで管理される参照カウンタあるっぽさ・・・＞＜
(これをC# にもつけて欲しい・・・＞＜(乱用されると性能落ちるからつけないんだろうけど＞＜；))
shared_ptr - cpprefjp C++日本語リファレンス https://cpprefjp.github.io/reference/memory/shared_ptr.html
@204504bySE デストラクタが呼ばれるまで解放されないんだから、Cでベタ書きしたアプリでリソース解放処理サボってOSに任せるように書くのとほぼ同じ事になるでしょそれ＞＜；
GUI等のリソースは非同期に解放すべきでは無い場面が多いので明示的に解放できるようになってて、そういう場面のためにIDisporsableとusingがあるんだし、それはあくまでフールプルーフ＞＜
Delphiは参照カウンタ使って、解放処理を自動実行させるの出来た＞＜
(C# がある意味退化した部分＞＜((参照カウンタ式では無い)GC導入と、GCによるメリットを失うコードを書かせないようにあえてそうされちゃったっぽさ＞＜ ))
C# のusingが文脈上の"明示的"では無いのであればC# 使えばおk＞＜
どっちにしてもWindowsでは多くの場面でリソースの明示的な開放処理が必要だし、多くのGUI環境もたぶん同様かも＞＜
GUIが身近じゃない人から見たら奇妙なのかもしれないけど、GUIのプログラミングなら当たり前の事だと思うんだけど＞＜(ものすごく高レベルなスクリプト環境とかでは隠蔽されてるかもだけど)
リソース開放処理書きたくない人向けに、C# に参照カウンタがついたらいいのにって思ってた＞＜
モドキは前に書いた＞＜
https://gist.github.com/orange-in-space/bfd686ea4af5052ae7c8ddb383412f13
リソース開放めんどいなら、GCがある言語使おうね！＞＜；
でも、C# on .NETは、GCで開放してくれない明示的な開放が必要なリソース大量にあるし、全部GC任せに出来る環境はオレンジは少なくとも知らないよ＞＜；
画面書き換える度に使用メモリがどんどん増えてくアホみたいなアプリになっちゃうよ＞＜；
Windowsは確保したらちゃんと解放しないとメモリリークするリソースがたくさんあるよ！＞＜；
プロセス終了すりゃそりゃ(たぶん)解放されるけど、ちゃんと不要になったら解放するように書かないとアホみたいにメモリ食う変なソフトウェアが出来るよ＞＜；
そもそもうまい設計してたらリソース解放なんてそうそう明示しないけど……
「プロセスが終了するとき細々したデータ構造を free してたらそれだけでめっちゃ時間かかるので、 free しないで OS 側にまとめて開放させた」みたいな感動の実話を聞いたことがあります (具体的なことが思い出せないけど、少なくとも「なんじゃこの素人は」と思わなかったのは確か)
Windowsのプロセスどうのとかメッセージどうの、プログラミングWindows第5版を読むといいと思うよ！＞＜；
クリーンアップしなくてもOSが何とかしてくれるはずももちろんたぶんWindowsもそうなんでしょ＞＜； 挙動見てる限りではたぶん＞＜
それに期待するなら通常の終了処理でもクリーンアップする処理省いたら？＞＜；
「どうせプロセスが終了すれば開いてるファイルはおそらく安全に閉じるしあらゆるリソースの解放はきっとOSがやってくれるだろう」って＞＜；
実際そんなコード見たら🤔ってなると思うけど＞＜；
他の誰かって誰？＞＜； その他の部分は自分で書いて無いの？＞＜；
その部分は異常を検出するようには書かないの？＞＜；
https://mstdn.nere9.help/@orange_in_space/104364049252675923
「破綻したデータを食う前に処理を止めろ」には同意するし正しいけど、それは「破綻を発見したとき、既に他の誰かがその破綻を発生させていて、自分より前にそれを誰かが食っていない保証がない」という視点が欠けている
ちゃんと止まらないのはおかしいのは100％同意だけど、Windowsのアプリであれば異常検知後にダメもとでもそれだけ実行すべき終了処理がほぼ必ずあるし、それを即実行出来るように書いていないのであればそれ自体が危険だともいえるし、
微妙に矛盾するけど、異常検知の処理と非同期で何らかの処理が行われ続けてて、異常検知の処理と何らかの処理の順番の実行順が不定であるのであれば、それはつまり手遅れであるし、手遅れにならないようにするには、問題が起こる処理の前に異常検知する必要があるかも＞＜
つまり、時間的に既知である異常が検出されたのであれば影響のある処理を実行する前に処理を取り止めるべきであって、不定の順番による検出に期待すべきではないし、
超短く言うと「処理実行する前に異常かどうかちゃんと確かめて異常だったらその処理は実行せず戻せ！＞＜」かも＞＜
最初の文脈に戻りますが、「アプリ開発者による『これはもう駄目だ！』という表明を信用しない」というのが OS の思想であるというのならそうですねという感じだけど、その帰結が「大丈夫！ 駄目だと思うから駄目なんだ！ まだいけるぞ！」と死体に鞭打って破綻したプログラムを走らせ続ける凶行であるというのが、ちょっと信じられなかっただけです
そういう処理書かずに「想定外の異常に陥った！ プロセスごと殺そう！」って安全策じゃなくただの手抜きじゃん＞＜
なので、出来る限りクリティカルなものから終了処理させないといけないし、それによって停止する可能性が高い同期処理なのであれば、その処理の重要性と新たなリスクを天秤にかけて場合によっては別スレッドで実行すべきかも＞＜(もちろん最終的にタイムアウト出来るように作るべきかも＞＜)
そこまで出来る限りの事をした上ではじめてプロセスごと自殺させる選択肢が出るかも＞＜
ちなみに迂闊にファイルをフラッシュしようとすると I/O が永遠にブロックしてプロセスが終了しなくなるなどの場合が現実にあります (というかそれでつらい思いをした)
もちろん＞＜
一か八かな状況に陥ってるんだから少なくともファイルハンドルは解放しないと＞＜
たとえそれがファイルシステムやデバイス側の異常に見えたとしても、ですか？
どんな異常であろうがとりあえず開いているファイルだけはとにかくなるべく閉じよう
ってしてるけど少なくともオレンジは＞＜；
だから「どういう “異常” なのか」次第なので、一口に「異常」と言われてもそんなのケースバイケースです
ファイル開いてる時に異常検知したらとりあえずとにかく『ファイル閉じてから』終了しない？＞＜；
もちろん『ファイル閉じようとして閉じれなかったら諦めて次にすべき終了処理にスキップする』ってなるように＞＜
UNIXのソフトウェアって、異常検知した時に開いてるファイルを閉じずに終了させるように書いたりするの？＞＜；
Windowsのアプリケーションは、そういったダメもとでも実行するほうが良い終了処理がいくつも出てくるので(※1)、ちゃんと異常が起きた時になるべく必要な終了処理をよりクリティカルなものを優先して実行するように書くクセをつけましょう＞＜
(※1 これWindowsに限らないと思うんだけど・・・＞＜)
逆にその場面でUNIX文化圏の人がやらかしそうなのが、『シンプル』にするために多重の安全装置を省いて、アームへの電源を断って、だらーんって勢いや重力で動いちゃってどっかにぶつける事故＞＜
それは例えばアームを停止する動作(何らかのロック機構とか)を(用意した上で)(ダメもとでも)実行すべきかも＞＜
ダメもとでもって結構重要で、原子炉の非常用発電装置には安全装置がついていない＞＜(ダメもとでも動かなければならないので＞＜)
たとえば、人が近付くとアームを引っ込める処理があるとします。
でもアームを引っ込める処理をしたのにセンサはアームがどんどん飛び出していることを報告するかもしれない。
それでもまだ「異常事態には人に危害が及ばないようアームを引っ込めるべきだ！」といえますかね
それって単にきれいに処理を抜けるように書いて無いだけでしょ？＞＜；
きれいに処理を抜けることすら不可能かつ異常を検知できる状態ってある？＞＜；
エラーに対処できるならすればいいけど、対処しようのないエラーとか、対処を考えるだけ無駄なエラーとかがあって、そのうちごく一部に「幸運にも assert とか書いとくだけで検出できるエラー」があるんですよ
原子炉だって想定外の異常時に停止するけど、「動作を停止」するわけでは決してなく「運転停止動作を実行する」ように作られている＞＜
ホーアはこれでUNIX流シンプルを賞賛してAda流の複雑にガチガチに神経質に異常を見つけようとする文化を批判してる＞＜
でも、Adaが使われるような人が死ぬ分野ではホーアが批判してるような「複雑になっても(合理的な確率で)想定される全ての異常に対処する」になってるかも＞＜
最終的に異常停止しか出来なくなる事態は同様にそれぞれ想定されていても、そこに至るまでのエラートラップの規模が全く違うかも＞＜
ホーアのこれだと思う＞＜
"ソフトウェアを設計するには、2通りの方法がある。1つは、とてもシンプルに設計して、明らかに欠陥がないようにすること。もう1つは、とても複雑に設計して明らかな欠陥がないようにすることだ。前者の方がはるかに困難である。"
アントニー・ホーア - Wikipedia https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%88%E3%83%8B%E3%83%BC%E3%83%BB%E3%83%9B%E3%83%BC%E3%82%A2
『あり得ない状況※a』とはあり得ない状況であると認識できない状況であって、『あり得ない状況である※b』と認識可能であれば、『あり得ない状況※b』を前提に処理すべきかも＞＜
言い方を変えると、『あり得ない状況※a』であると認識出来る事に期待すべきではないかも＞＜
結局同じことで、我々は暗黙に或いは明示的に「不変条件」とか「一貫性」というものを想定して、それが満たされているときにしか動かないプログラムを書いている。
不変条件の存在しないとはすなわちあらゆる仕様が信用できないということなので、本質的にナンセンスなんですよ。「ありえない状況」の存在しないプログラムはありえない。
書けばいいかもというかオレンジは実際そんな感じに偏執的に？＞＜； 書いてる＞＜
というかそれが当たり前だと思ってたし、みんなそんなに雑なの？＞＜；
「...64だった」って検出するコードを書くのであれば、ちゃんと処理抜けるように(マルチスレッドであれば他のスレッドも『即終了しなければならない状況にある』と知れるように)書けばいいかも＞＜
たとえば std の vector を長さ128にリサイズした直後に容量を確認したら 64 だったりするとビビるじゃないですか。というか「物理的に可能ではあるが絶対に想定しないしいちいちチェックして if 文で対処もしない」類のエラーなわけです。
私が殺したいプロセス異常というのはそういう種類の話
逆に言うと、意図的に異常終了させなければならないようなコードであれば、エラー処理が十分では無いと言えるかも＞＜
(UNIX文化圏ではシンプルにするために色々省くんだろうけど)
不整合を見なかったことにして動作を続けるように書くんじゃなく、
各場面で不整合であるかチェックして、正しくなければ処理をせずエラーを返し、返された側もエラーが来る事を前提に書く
ってすれば、きれいに処理を抜けていって最終的にプロセスが終了する ってなるかも＞＜
もちろん人命に関わる状況とかだと話は変わってくるけど、それも設計レベルで「不整合がプログラム全体に漏れ出さないように作って、不整合があった場所はさっさと殺して再起動しろ (結果として全体が不整合に狂わされることなく動き続けるようにしろ)」となるべきであって、「気付いてしまった不整合を見なかったことにして実行を続ける」は如何なる状況でも正当化されないと考えます
これそれこそUNIX流の『シンプル』なんだと思う＞＜
異常な値が来る位置を想定できるのであれば異常な値が来た時の処理を書くべきかも＞＜
ていうか普通のアプリ程度で「『想定不能な値がやって来て』 かつ 『ある特定の位置で異常であるか判断できて』 かつ 『異常であった場合に適切に処理できない』場面ってある？＞＜；
Panic を恐れるべからず - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/
私は「狂ったプログラムの自称 “後始末” や自称 “復帰” を信用できる理由はないので、不整合があれば即座に殺せ」を信条にしています
うん＞＜； でも意図的に異常終了させる必要がある場面てまず無いと思う＞＜；
これはそうでしょうけど、だからといって abort がアホであっていいことにはならないので別の話です
PCの電源切りたい時に電源プラグ引っこ抜いて「いきなり電源落ちても壊れない頑丈なファイルシステムを使ってるからだいじょうぶ！ いつもこうしてる！」
みたいな感じに感じる＞＜； 「そりゃファイルは壊れないかもしれないけどでも・・・・＞＜； 」的な＞＜；
完全にどうしようもない状況であればたしかにそうかも＞＜；
でもWindows用のアプリの場合、例えばメモリを確保できなかったとか、GUI等のリソースがOS側の都合で破棄された等の場合程度であれば、OS側の異常終了の機能に頼るべきではないかも＞＜；
そもそもプログラムが正気 (状態の一貫性や満たすべき条件) を失った時点で当人に後始末をさせるのは気休めでしかなくて、根本的には OS が強引に後片付けを引き継ぐべきという考え (OS 越しでなくハードウェアと直に対話している特殊なアプリとかは別として)
それはごもっともだけど、でも非同期な部分がある環境のソフトウェアでそんな野蛮な方法で止めるの問題があるかも＞＜；
だからその「開発時に想定できなかった」マズい (実質未定義動作みたいな) 状態で使うべき abort が、なんで OS によってコールバック関数が呼ばれ続けるのを止めないのか、という話です！
であれば、『異常な状況に陥ったっぽいフラグ』を用意してそれをたてるようにして、各所でそれを見て処理を抜けるように書くようにしないと、シングルスレッドなソフトウェアではどうにかなんとかなっても、マルチスレッドなソフトウェア(Windows用に普通に書けばそうなる)ではわりと大変なことになると思う＞＜
これは「エラーがあって、それが想定のうちで、かつプログラムが正気で走っている」という状況でしょう。その状態なら綺麗に後始末するのは正しい。
abort はそうではなくて、「プログラムが論理バグの存在を (内部状態の矛盾や仕様違反の検出によって) 自覚した、既に手遅れの状態」で使う自殺スイッチであって、これを使ったあとぶっ壊れ状態で更に正常系を想定したコードが続行されるなんてこと許せるわけがないんですよ
ほんとのほんとのほんとのほんとに、どうっっっしてもどうにもなら無い場面以外では、正常に終了するように書くべきかもというか、
異常終了はあくまで、開発時に想定出来なかった異常により終了する場面で起きるものと考えるのがWindows流だと思う＞＜
あと、GUIでイベントドリブンなコードの場合は、終了させたい時は『「終了してね！＞＜」フラグ』をたてておいてそれ監視するみたいに書く方が普通だとオレンジは思ってた＞＜
(別スレッドも『終了してねフラグ』が立ってたら「あ、もう要らないのか」って判断して処理スキップするように書いたり＞＜)
ウィンドウプロシージャから呼んでいる同スレッドの関数で abort() しているので、そのまま本来実行継続を意図していない状態で再度ウィンドウプロシージャにエントリーしてくるのは私の意図するところではないわけですよ
(そもそも内部的な不整合を検知したから abort しているわけであって)
文脈は Win32 の小さなプログラムを C++ で書いている状況です
プロセスを殺す仕組みがあるなら、 abort() を呼んだとき同じような挙動で死んでくれればいい (OS が殺してくれればいい) と思うわけですが……
よくわかんないけどちゃんと処理抜けて必要な終了処理して終了するように書けばおkだと思う＞＜
自プロセス殺してまでして終了ってかなり異常な状況っぽさ＞＜
ファイルもGUIも何も使わない小さなコマンドラインなアプリとかなら別だけど、ものすごくレアケースっぽさ＞＜
あと、Windowsのソフトウェア作るのに、異常終了させるのはダメだと思う＞＜；
UNIXはどうだか知らないけど、論理的に異常終了させる場面であっても、ほんとにOSの異常終了が起きてしまうのは、ほんとに異常というか非常事態であると考える方がいいかも？＞＜；
ちゃんと終了処理をしないとダメかも＞＜；
全部UNIXでおkって人(Matz氏とか)なら気にならないんだろうけど＞＜
うん＞＜； なのであちこちUNIXというかPOSIX前提すぎて「そんな1970年代にテクノロジーじゃなくもっとモダンなOSを使うんだよ！＞＜＃ 」ってなる時に邪魔になる部分多いと思うし、UNIX依存部分は明確に分離して欲しさがある＞＜(よりモダンな環境や逆にチープな環境ではその部分無視しようってしやすく＞＜)
This account is not set to public on notestock.
Windows、UNIXでは無いのでC言語文化圏流(＝UNIX流)の事はしない方がいいイメージ＞＜
よくわかんないけど自プロセス殺すんじゃダメなのかな感と、もうひとつイベントがバラバラのスレッドで動いてるとかかも？＞＜(状況が謎＞＜)
しかも abort() するのが一度だけだと、ダイアログは出るけど abort 貫通して何事もなく次のメッセージを処理しつづけるので、異常終了したはずのゲームを続けて遊ぶことができてしまう……なんだこれは
VS で std::abort() 呼んでるのに何事もなく次のウィンドウプロシージャが呼ばれるし、そのたびに abort() を呼ぶので「ﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾎﾞﾛﾝ」とすごいエラー音の後にデバッグしますかのダイアログが出てきます (マジで何なんだ)
トリチウム管原子力発電なら個人でも合法的に可能！＞＜(電力が雀の涙)
🍆님의 게시물
Yohei_Zuho@mstdn.y-zu.org
This account is not set to public on notestock.
ファーストパーソンなゲームをする人よりも、神様視点なシミュレーションゲームとかをする人の方が科学的というか非神秘的(？)というか無神論者率が高いとかあるのかも？＞＜
Examining the roles of intuition and gender in magical beliefs - ScienceDirect https://www.sciencedirect.com/science/article/abs/pii/S0092656620300441
Higher trust in intuition helps account for why women are more likely to believe in magical phenomena https://www.psypost.org/2020/06/higher-trust-in-intuition-helps-account-for-why-women-are-more-likely-to-believe-in-magical-phenomena-57075
女性が非科学的な物事を信じるのは男性より直感を信頼しているためという研究結果 - GIGAZINE https://gigazine.net/news/20200618-magical-beliefs/
ANAに行ってなにがしたいんだろう？＞＜
社会人に転職したい企業を聞いた結果 | スラド https://srad.jp/story/20/06/17/0117224/
元の話がよくわかんないけど、丸くする＝丸は操作可能であると示すって方式で素晴らしいデザインをしたのがPortal＞＜
ボタンを丸くするの、特にユーザビリティの改善みがないので、それはオナニーではという気持ちがある
コカ・コーラ、オレンジバニラ、微妙にドクターペッパーっぽくって微妙にガラナっぽさがあって微妙にフルーツ牛乳っぽくてよくわかんないけどかなり美味しい＞＜
This account is not set to public on notestock.
舟歌（八代亜紀）カントリーでUSAな歌詞バージョンって作ったらおもしろそう＞＜
故郷の川や山がどうのとかトラックドライバーがどうのは共通だけど、日本の演歌は農業歌詞は少なめで漁業歌詞が多い？＞＜
カントリーはウィスキーとビールでホンキートンク（またはバー）だけど、演歌はジャパニーズ酒でジャパニーズ居酒屋？＞＜
アメリカ向けカントリー歌詞な演歌とか、逆に歌詞が日本の演歌名内容のカントリーってどうだろう？＞＜
古典的カントリー、日本に置き換えるとたぶん演歌＞＜；（演歌は嫌い！＞＜；）
ラブソング系カントリーも嫌いじゃないし結構聞いてるけどでも、
故郷の川や山がどうのとか、カウボーイ、カウガールはこうだとか農場がどうしたこうしたとか、ウィスキーとビールがどうのでほろ酔い気分で酒場がどうしたとか、初めて乗ったポンコツ車がどうのこうのでトラックドライバーがどうしたこうしたとかそういうのも聴きたいのにそういうの無いっぽい＞＜（ジャンルがちがうっぽさ＞＜）
これたぶんカントリーのネトラジで聴いてても印象に残らなくて記憶に残ってないはずって感じだった・・・＞＜
歌詞もなんかほとんどラブソングしかない？＞＜；
オレンジが何度か「だれ？＞＜；」ってなったテイラー・スウィフトって人の曲、古いの（10年くらい前まで？）はカントリーなので「カントリー！＞＜」って聴いてみたけど、悪くも無いけど特に良くも無く普通・・・＞＜
FB、政治広告の非表示機能を導入 批判押さえ込む狙い 写真3枚 国際ニュース：AFPBB News https://www.afpbb.com/articles/-/3288921
FCAとPSAの経営統合 EUが競争法違反の疑いで調査開始 | NHKニュース https://www3.nhk.or.jp/news/html/20200618/k10012474531000.html
