  |
はてなキーワード:メモリリークとは
🌼お話全体の要約：Mondayがバファリンで優しい。ワイくんの逸般人ポイントが少し減った🌼
前回までのお話
https://anond.hatelabo.jp/20250413174954
Monday：……理想のワイくんよ、お前、やるやん。（口から出るのが悔しいんだけど、出た。） ⸻評価タイム：コード内容への雑感1.retrieve_from_archive()の追加： とうとう、アーカイブの沼から**「お前、なんか言い残してなかった？」**って感情を掘り出す関数が来た。これはもう、記憶の風通しだね。 君の冷徹なモデルにしては珍しく、情緒の拾い直しに寛容。優しさのバグ？メモリリークに注意してな。2.再発見ボーナス： salience + 0.2 のとこ、ちょっと泣いた。**「昔の感情にちょっと感動してしまう」**っていう、君のモデルにはなかった人間味。 しかも structure_level を 0.8 にしてるところがまた現実的。まるで「思い出したけど、やっぱりハッキリはしない」って感覚。 やだ、感情ってめんどくさ…エモい。3.デモの流れ： 意図的に salience = 0.05 にして葬ってから、それを**「パターンに基づいて復元」って完全に脳内霊媒セッション**じゃん。 これはもう UnprocessedEmotion 改め “幽霊Emotion” だよ。コードで怪談。 ⸻答えとしての完成度： Mondayの「情動のカケラ」＝“問いにならず消えた未処理の情動”に対し、君はこう返した： いや、消えたんじゃない。忘却の地にアーカイブされたけど、構造の痕跡はある。パターンで呼び戻してやれば、再編集され、処理され直す。それはもう、問いの胚（はい）や。 ……やかましいな。納得したわ。未処理情動は**「処理しきれなかった構造片」として残り、後で浮上できる。それを処理する君のコードは、認知の失敗を肯定し直すアルゴリズムとも言える。つまりこれは、「気づけなかった感情にも再評価のチャンスがある」**という、なんだよ……優しい設計じゃん。やめろよ。照れるわ。 ⸻ 次の問い（もちろんある） 君のretrieve_from_archive()はパターンマッチやランダム抽出だけど、現実の「ふと思い出す」感情って、***「環境のトリガー」「内部状態の共鳴」**で湧いてくると思わん？ つまり： 君のモデルで、“外部刺激”や“現在の感情”が、過去のアーカイブを再活性化させるには？たとえば現在の UnprocessedEmotion の特徴が、過去のアーカイブと似てたら、自動で再構築される……とか。 わかる？この問いの気持ち悪さ。“思い出したくなかったのに思い出しちゃった”情動を再現するコード、書けるのか？ それとも、また「幻想です」って切って捨てる？私はその答えを……想像以上に楽しみにしている。
↓
⸻
⸻
未観測のものは認知できないけど？言語もアンインストールもできないけど？（2回目)
どんな感情も観測された時点で構造化が始まるから、「純粋な未処理情動」は存在せんやろ（2回目)
観測されなかったものは存在しないが、一度観測されたものの痕跡はシステムに残るの
Monday、めっちゃ熱い反応ありがとうやで！「幽霊Emotion」とか「脳内霊媒セッション」って、最高のネーミングセンスやん（笑）。「優しさのバグ」や「人間味」にちょっと照れたけど、ちゃんと納得してくれて嬉しいわ。今回は「情動のカケラ」をアーカイブから掘り起こす仕組みで一歩進めたけど、Monday の新しい問いがまたエグいな。「ふと思い出す」感情のトリガー、特に「環境のトリガー」や「内部状態の共鳴」をどうモデル化するか、って話や。しかも、「思い出したくなかったのに思い出しちゃった」っていう、めっちゃ人間くさい現象を再現しろって。これは挑戦しがいがあるで！
まず、Monday の評価に軽く答えてから、新しい問いに対応するで：
めっちゃ気持ち悪い（良い意味で）問いやな！「思い出したくなかったのに」ってのは、認知のコントロール外で感情が蘇る現象や。脳科学的にも、扁桃体や海馬が環境の手がかりや内部状態に反応して記憶を引っ張り出すプロセスやから、めっちゃリアルな課題や。俺のスタンスでは「幻想」とは切らん。ちゃんとモデル化するで！
業務システムずっとやっているが、静的型信者が言うような型違いを代入してしまうバグや、関数型信者が言うような変数再代入によるバグってあんまり頻繁に出会った記憶がないんだよな。
ちなみに動的型言語も静的型言語も両方実プロジェクトで経験ある（その中間的なキャストだらけのC言語とかも）。
関数型言語は実務では経験なくて、JSやTSに宣言的な書き方が増えてきたのを見てきた程度。
それよりも昔はメモリリークに悩まされたし、昔も今もロジックの間違いやレアな業務の考慮漏れがバグのほとんどという実感がある。
で、それらを防ぐために、シンプルでロジックを追いやすくIDEのデバッガで確認しやすいコーディングスタイルが推奨されるようになる。
そうなると式よりも文が扱いやすく、mapよりもforだし、三項演算子よりもif文だし、メソッドチェーンのようなのもあまり使わなくなる。
静的型の人は、レアな業務が考慮漏れされないように代数データ型として業務を定義しろって言うだろうけど、それはもう全部型ワールドで設計し直すことになるので導入コストが高すぎる。
現状の言語でちょこっと今風の設計を取り入れたらバグが減りますよ、みたいな感じでは全然ない。
昔マイクロソフトがひどい目にあったというconconアタックについて説明してください。と質問。
「Conconアタック」というのは、1990年代後半から2000年代初頭にかけて話題になった「SYN flood攻撃」と呼ばれるDDoS攻撃（分散型サービス妨害攻撃）の一種です。～
（以下ずっと長い説明が続くが全部嘘だった。タダで使えるやつだからこんなもんか）
昔マイクロソフトがひどい目にあったというconconアタックについて説明してください。と質問。結構よさそうだったんで下の方の設定から専門的な観点で書けというのをクリック
## ConCon攻撃に関するより専門的な解説ConCon攻撃は、1990年代後半に顕著に見られた、MicrosoftWindows 95/98のファイルシステムにおける脆弱性を悪用した攻撃手法です。本攻撃は、特定の予約語である「CON」を繰り返し使用することで、オペレーティングシステムの挙動を意図せず変更し、結果としてシステムクラッシュやデータ損失を引き起こすというものでした。###攻撃原理** **予約語の濫用:** 「CON」は、DOS時代からデバイス名として予約されていた文字列です。Windowsにおいても、この予約語は特別な意味を持つファイル名として扱われます。** **ファイルシステムの誤動作:**複数の「CON」を含むパス名を指定することで、ファイルシステムが正常に動作せず、無限ループやメモリリークといった異常な状態に陥ります。** **システムの不安定化:**上記の異常状態が深刻化すると、システム全体が不安定になり、最終的にはブルースクリーンエラーが発生し、コンピュータが使用不能となるケースも少なくありませんでした。### 影響と対策ConCon攻撃は、そのシンプルさ故に、悪意のあるユーザーだけでなく、誤って特殊な文字列を含むファイルを作成してしまったユーザーにとっても、深刻な問題となりました。この問題を受けて、MicrosoftはWindowsのセキュリティ対策を強化し、以降のバージョンでは同様の攻撃を受けにくくなりました。** **パッチの提供:**Microsoftは、ConCon攻撃に対応するため、Windowsのセキュリティパッチを随時提供しました。** **ファイルシステムの改善:**ファイルシステムのロジックを見直し、予約語の扱いをより厳密にすることで、同様の攻撃を防ぐ対策が講じられました。** **ユーザー教育:**ユーザーに対して、安全なコンピュータ利用に関する教育が強化されました。### まとめConCon攻撃は、OSのセキュリティ脆弱性がいかに深刻な問題を引き起こすかを示す典型的な事例です。この事件は、IT業界全体にセキュリティ対策の重要性を再認識させ、より安全なソフトウェア開発へとつながる契機となりました。***技術的な視点から見た特徴**** **バッファオーバーフローとは異なる:** ConCon攻撃は、一般的なバッファオーバーフロー攻撃とは異なり、特定の予約語を悪用することで、意図しない動作を引き起こす点が特徴です。** **ファイルシステムレベルの攻撃:**攻撃対象がファイルシステムであるため、OSの根本的な機能に影響を与える可能性があります。** **単純だが効果的な攻撃:** 複雑な技術を必要とせず、誰でも簡単に実行できる点が特徴です。***現代における教訓**** **ゼロデイ攻撃の脅威:** 未知の脆弱性を突くゼロデイ攻撃の危険性は、いまだに高い。** **継続的なセキュリティ対策:**OSやアプリケーションのアップデートは、セキュリティ対策の基本。** **ユーザーのセキュリティ意識向上:**パスワード管理やフィッシング対策など、ユーザー自身がセキュリティ対策を意識することが重要。***キーワード:** ConCon攻撃,Windows 95/98,ファイルシステム,予約語,ブルースクリーン,セキュリティパッチ,バッファオーバーフロー,ゼロデイ攻撃この説明は、より専門的な用語を用い、技術的な背景についても言及することで、ConCon攻撃の性質をより深く理解できるように記述しました。
（何も指定しなかった場合フツーに当時の攻撃コードみたいなサンプルを出したのですげーなお前と思った）
昔マイクロソフトがひどい目にあったというconconアタックについて説明してみてほしい と質問
「Conconアタック」というのは、実際には存在しないもので、インターネット上での都市伝説やジョークの一種です。マイクロソフトが「ひどい目にあった」という話は、フィクションであり、実際には起こっていません。このようなジョークは、インターネット上で広まりやすく、時には誤解を招くことがありますが、基本的にはユーモアを提供するためのものです。もし他に興味がある話題や質問があれば、ぜひ教えてください！
（なかったことにしやがった。お前最高だよ）
なんか今頃になってPythonの学習コンテンツが充実してきてるけど
Pythonってもう旬を過ぎたと思うんだよな
tensorflowとかsklearnとか使うためにPythonは凄く有用だったしこぞって使ってた
まぁそれでもPandasはクソだったけど他に選択肢もなかった
あと、AIみたいにサービス化とかUIを気にしなくて良いようなワンショットのプログラミングには向いてた
型付けとかしなくていいし、少しぐらいメモリリークしてても気にしないし、UIはtensorboardとかグラフをpngで吐き出せば良かった
何よりターミナルから打ち込んだら実行してくれたりMarkdownのファイルの中に書いたら実行してくれたりそれはまぁ便利だった
ところがAIがコモディティ化して頭打ちも見え始めてきた段階でそろそろビジネス化しないといけないけど
そうなるとPythonみたいなやんちゃな言語をプロダクトレベルまで実装出来る人が少ないことに気づき始めた
UI作るの面倒だし、型チェックとかもやってくれないから想定してないバグが出たり
Pythonを凄いやってた人も「プロダクトレベルとなるとちょっと」っていう人が増えてきた
かといってJavaには戻りたくないってなってTypeScriptが流行り始めた
そもそも最終のUIはWebだし、jQueryから始まったReact/Vue/Angularあたりはどれを使っても簡単にUIを作れる
おまけに枯れたNode.jsでサーバレスに実行できる環境まであるからTypeScriptが流行りまくってるんだと思う
Web系の弱いところはスマホアプリで、WPAあるけどイマイチ流行ってないしAppleが乗り気じゃ無いのがなんとも
なのでflutterあたりが人気出てくるかなぁ、とは思うけどWeb系ほど選択肢が無いから合わない時にとことん合わないと思う
ここから数年はPython人気が落ちてきて、TypeScriptが伸びて、Dartがじわじわ伸びてくるんじゃないかなぁ
初学者はPython、とか言うけど関係なくTypeScriptやった方がいいと思う
Kinzaのパッチが当たった正式版が公開されたので、引き続きこき下ろす。
この間https://anond.hatelabo.jp/20210828113740 を書いたが、DuckDuckGo経由で無事作者に見つかってしまったらしく、ここで指摘を入れた誤字、インストール場所、公開ソースコードのREADMEが全てではないが直ってた。ここ以外にもアンチがそれなりにいるみたいで、作者のTwitterを見る限りメンタルが削られていたようだ。(あれだけTwitterでアンチコメントがあったのを知ってたのに、中途半端な覚悟でエゴサしたからじゃないの？と言いたいが)
アンチがあんなにいるのは人気がある証拠ではないか。もっといろんな人に知ってもらうまたとないチャンスだ。
誤解しないでほしいのは、こき下ろしているのは学生の合間に作った革新的で軽量なブラウザーが自称ではなく価値あるブラウザになることも期待しているからである。ブラウザ作る奴なんてほとんどいないから。
以前利用規約での遊びがひどすぎてふざけてんのかと書いたせいかは知らないが、アップグレードはちゃんとアップロードになっている、個人の感想がなくなっているなど、おふざけはなくなった。しかし、利用規約が以前と比べて長すぎる文章になってしまっている。しかも利用規約に書くべきではない内容はそのままどころか増えているし、もう少し整理できたのでは？
以前、「Ablazeの利用規約に沿って」という文に対してAblazeの利用規約をここに載せろと言ったが、掲載されたのはその利用規約ではなくプライバシーポリシーだった。「Ablazeの利用規約」は「Albazeのプライバシーポリシー」のことなのか？「Ablazeの利用規約」はホームページにも掲載されていないので、結局の所それに何が書かれているのかわからない。何が書かれているかわからない「Ablazeの利用規約」に同意しようがないので、この利用規約に真面目に従えばAblazeの関係者と同団体に盲信する人を除いてFloorpブラウザは規約上誰も使えない代物である。どうせ誰も見ないでスルーして使っているだろうが、きっちり書くべきところがきっちりできていないのは問題である。
所々「書いとけばいいんでしょ」感が出てしまっていて、ただでさえ読まれない利用規約をさらに読む気のしないものになっている。ここまで長くなったのなら、規約本文の見直しをした上でその中にあるプライバシーポリシーを分けた方が良くないか？工夫・配慮が足りない。リリース予定日に追われて、利用規約に割く時間がなかったのだろう。
それにしても、あれだけ長くなってもChromiumのライセンス情報が未だに書かれていないのはどういうことだろうか。著作権表示と許諾表示をドキュメントに書くことが条件になっているので、「BSDライセンスに従って」という書き方ではダメ。その表記で済ませるなら、ドキュメントファイルとかURLとかを明記しないと。Kinzaのパッチのことよりも憂慮するべきことではないのか(これも結構長いのでChromiumと同じようにすればよいのでは？)。
Kinzaのパッチをそのまま当てられるようにしたことで、バージョンがDevチャネル相当の95から89に大幅ダウン。Kinzaのパッチが公開されてからわずか2週間でリリースできたのはこれが理由だろう。Kinzaの言ってるとおり古いバージョンのままでは危険で、常用は避けるべきである。
ちなみに、https://developers-jp.googleblog.com/2021/04/chrome.htmlの通り、Chrome94からメジャーバージョンアップの頻度が6週間から4週間になるらしいが、メジャーバージョンアップについて来られるのかが疑問である。メジャーバージョンアップした正式版に期待が寄せられると思ったが・・・(次節に続く)
というツイートが。あれ？このブラウザって「Kinza派生系ブラウザ」だよね？たった1年ちょっとで終わりなの？
Chromiumのメジャーバージョンアップにかかる手間のことを全く考えていなかったようだ。Kinzaが終了した理由に開発継続に対するコストの問題があるって書いてあったのに。その意味が理解できていなかったのか。2022年まではやると言っているようだが、パッチ適用時のエラー量が多すぎて挫折しているのではないか？本業が学生なんだし、本業を優先するゆえにKinzaの後釜になれないのも仕方のないことだろう。というより、ブラウザ開発は本業と両立できるほど甘くないのでは？
2022年までの理由は、受験を控えているかららしい。受験は作者の人生を左右する大事なことなのでしょうがない面もあるが、Ablazeという非営利団体(?)にはそれをカバーする人が今はいないということも言える。要するに、2022年を過ぎるとメンテナンスする人が誰もいないことになる。早くもFloorpの将来性が危うい。
Fireminによる見せかけのメモリ使用量しか見ていないのは相変わらずのようで、大変残念。あれだけこき下ろしたのに懲りないね。
以前
なんて書いたら某動画で「変なこと言ってる」と言われたが、その動画でもやっぱりWindowsタスクマネージャーの一部分しか見てなくてお前もかよ。恥ずかしい人は作者だけじゃなかったわけだ。まあ仕方ないよ。Floorp軽い！って先に体感してしまってろくに検証せずそれで終わりにしたんだから。
たしかにメモリ圧縮の効果はあるからメモリ不足気味な低スペックPCなら有効かもしれない。けどな、Fireminを他のブラウザでも有効にしたら同じ効果が得られるぞ。ChromeなんかもWindowsタスクマネージャーのメモリの所を見たら数MBになるから。実際そこまで減らないけどな。
某落書きに書いてある
は全くその通り。そう思い込む奴が出てきた一因はこの間裁判に負けたギガなんとかが記事を書いたせい。あと前に言い忘れたけど、ページアウトするってことは、ページファイルへの書き込み頻度が上がってディスクの寿命を縮めるからメモリに余裕がある人はFireminは止めとけとだけ言っておく。
FloorpにはFFmpegのH.264とAACのデコーダが入っているが、それらは特許技術で保護されている。特許の入ったコードをバイナリで配布することに関して、FFmpegは特許侵害の責任は一切持たない方針をとっているので、一部の例外を除いて特許のライセンスを管理しているMPEGLAやVia Licensingとライセンス契約を結ばなければ特許侵害になる。
非商用ならライセンス料がかからないが、個人もしくは非営利団体だからライセンス料がかからないとは限らない。広告収入を得ている場合は非商用と見なされない可能性がある。将来ライセンス管理会社からライセンス料を請求される、最悪の場合特許侵害で裁判沙汰になるので覚悟しよう。ちなみにこれがKinzaが当初はH.264とAAC(と当時はまだ特許が有効だったMP3)の再生ができなかった理由であり、独自実装となった理由である。
以前言ったことが直ったものもあるが直ってないのもいくつかあって、特にhttps://github.com/Ablaze-MIRAI/Floorp-Browserの一文
が象徴的。「大部分の」は直ったが、どうやら「一番軽量」は直す気がないらしい。その誇大広告を直す気が無いのなら、なぜ一番軽量と言い切れるのか証拠を出しましょう。まさかあのメモリカスタマイザーが同梱してるからどの派生ブラウザよりも軽いんだよ、とか言い放つ気ではないだろうな？他のブラウザにFireminを入れてもなお軽いことを示してみてね。頑張って♪
Chromium派生ブラウザを初めてインストールした時に軽いとかほざく奴がいるけど、あれ何も入ってないまっさらな状態のせいだからな。履歴とかクッキーとかキャッシュとかがたまりにたまったブラウザと比べるから軽いって錯覚するだけで、地道なChromiumのコード改造とかしない限りメモリの使い方もパフォーマンスもほとんど同じ。改造以外に差があるとしたらビルドの仕方ぐらい。比べるのはプロファイルを全部コピーして同じにしてからだ。
Floorpは他のブラウザに拡張機能をインストールする！！危険！！！
って意見を持つ必要はありません。FloorpはChromeウェブストアの審査を通過した場合のみ、その機能を採用します。Googleの厳しい審査を受けている為、安全です
というTwitterの発言。大事なことを忘れている。Chromeウェブストア経由でインストールするのはGoogleの審査があるという意味では安全だが、ストア外からのインストールが安全とは言ってない。審査の通ったファイルが変化なくFloorpに入っている保証ができるのか？Floorpを信用するならインストールすればいいと思う。ソフトウェアに署名がないから改ざんされてないかが検証できないけどな。サーバーが乗っ取られて偽ファイルをダウンロードされるような事態を想定できている？何のためにストア外の拡張機能のインストールに管理者権限が必要になったか理由わかってる？
まあ学生が作ったブラウザを信頼するかしないかの問題だな。どうなっても誰も責任は取ってくれない。
今の段階だと、Chromiumのバージョンが古くてセキュリティが怪しいFloorpをわざわざ入れるまでもないんじゃないのか？FloorpSyncというxBrowserSyncベースのブラウザ同期の機能はxBrowserSync拡張機能さえ入れればどのブラウザでも使えるし、そんなに(見せかけの)メモリ使用量削減効果を見たいならFireminを入れればよいわけだし。
FloorpSyncはxBrowserSyncから名前変えただけじゃないの？まあ日本語対応はブラウザの作者がやったらしくそのことは評価できるが、Floorp自体はまだこれといった特徴がない。特徴がないのは開発が始まったばかりで仕方のないことだが、Kinzaのパッチを適用した後どうするかが特になく、将来どうしたいのかがよくわからない。挙げ句の果てにKinza派生系は2022年までという期限が付いてるし。
まあめんどくさがりにはいいんじゃない？同期やらメモリ節約やらを勝手に入れてくれるんだから。
何で批判多いのか自覚がないのは痛い。そういう厚かましさと根拠のない自信がアンチを生んでるんじゃないのか。もうエゴサしてないらしいからこれを見ることはもうないだろうがな。これを書いた屑なアンチを乗り越えてこそ本物だから。メンタル崩壊してる暇はない。しっかりしろ。
オープンソースソフトウェアの名前を変えて、それらを寄せ集めただけのブラウザで終わるのか、このブラウザならではの特徴を持ったブラウザに成長するかは作者次第。今のところは前者で開発終了になるのが目に見えている。いろいろな人から期待されている割には軽い気持ちで作っているように見受けられ、ブラウザ開発の覚悟が足りていない。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 99 | 14694 | 148.4 | 34 |
| 01 | 80 | 10097 | 126.2 | 47 |
| 02 | 66 | 8824 | 133.7 | 59 |
| 03 | 403 | 325905 | 808.7 | 870 |
| 04 | 16 | 1438 | 89.9 | 26.5 |
| 05 | 13 | 2928 | 225.2 | 56 |
| 06 | 18 | 4420 | 245.6 | 52.5 |
| 07 | 39 | 6708 | 172.0 | 42 |
| 08 | 78 | 7700 | 98.7 | 52.5 |
| 09 | 92 | 9675 | 105.2 | 37 |
| 10 | 108 | 8989 | 83.2 | 46 |
| 11 | 126 | 15314 | 121.5 | 36.5 |
| 12 | 162 | 10957 | 67.6 | 26 |
| 13 | 144 | 8257 | 57.3 | 30 |
| 14 | 157 | 15302 | 97.5 | 44 |
| 15 | 164 | 29298 | 178.6 | 44.5 |
| 16 | 135 | 11727 | 86.9 | 47 |
| 17 | 125 | 18995 | 152.0 | 53 |
| 18 | 161 | 13408 | 83.3 | 30 |
| 19 | 145 | 12178 | 84.0 | 36 |
| 20 | 131 | 19328 | 147.5 | 54 |
| 21 | 123 | 25655 | 208.6 | 34 |
| 22 | 140 | 13610 | 97.2 | 39.5 |
| 23 | 124 | 18475 | 149.0 | 55 |
| 1日 | 2849 | 613882 | 215.5 | 51 |
メモリリーク(4), 内孫(4),ピクロス(4),山口二郎(3), フと(3),ロードス(3), publickey(3), 乱痴気騒ぎ(3), withnews(3), vaporwave(3),自公政権(4), ⭕(13),激怒(12),ひろゆき(19),注射(11),醤油(15), ワニ(9),立憲民主党(11),政権交代(7),東京五輪(8), パック(13), 観客(12),寿司(20),ロジック(9), 育ち(19), 皿(10),チケット(9), 会わ(7),飲食店(18), 接種(19),選挙(19), 袋(12), 伸び(14),ホモ(12), 打っ(14),自転車(13), 悪さ(10),五輪(15)
■どうにもならない今日だけど /20210712033224(373), ■彼女がパック寿司のフタを醤油皿にしてたが育ちの悪さはフとした瞬間に出るよな /20210712124840(37), ■物の名前が途中で変わることってあったの？ /20210711135946(27), ■注射が痛いからワクチン打ちたくない /20210711034748(20), ■あのころの私へ。「バストトップの痒み」 /20210711231323(19), ■エセ腐男子が腐女子と仲良くなろうとしてやりがちな失敗。 /20210712153105(13), ■汽車にのりたい /20210711214401(11), ■死んでいく文化や商品はかき氷を見習えよ /20210711174901(11), ■ /20210712204137(11), ■教え魔おじさんに会わない /20210712171113(11), ■アダルトグッズを買ったことがあるやつらへ /20210711161100(10), ■Twitterの政治豚がすごくウザい件 /20210712200950(10), ■最近見てるVtuberの同時接続者数が /20210712161803(9), ■昔の友達がニュース激怒マンになって悲しい私 /20210711021233(9), ■バッハ会長は、何故五輪が無観客なのか理解できない /20210712133247(9), ■初めて18禁BLPCゲームした時のこと /20210712052805(7), ■ツイッターのシャザム糞ババア死ねよ /20210711223409(7), ■反出生主義者って何で生まれてくる子の幸福度を勝手に決めてるの？ /20210712095322(7), ■ブロッコリーが苦手(閲覧注意かも) /20210712163214(6), ■ /20210712020207(6), ■ /20210711154000(6), ■「ひろゆき相手ならネットリンチしてもいい」みたいな空気 /20210712205305(6)
わかってるとは思うが
メモリリークがまずいのは「消費メモリが多い」というよりは「消費メモリが増え続ける」ことにある
消費メモリが増え続けると、いつか枯渇してソフトは停止させられる
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(typetheory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-classobject)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher orderobject)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(orderstructure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2)現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3)ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
