このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
ロフトベッドは今のところ人生で最大の後悔だし絶対におすすめしない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
やりましょう。そして「Rustって型安全性とメモリ安全性は細かくチェックしてくれるけれど、プログラムの他の側面はやっぱりテストコード書かなきゃいけないんだよな……」と思い始めたらF*（FStar）やりましょう
このアカウントは、notestockで公開設定になっていません。
人間は本当にクリティカルな部分と些事の区別が付かないという経験則がある (e.g. 標準ライブラリにある文字列処理を無駄に unsafe にするもパフォーマンスへの貢献に確信がないなど)
これは Rust 狂信者にありがちなアレな態度なので努めて冷静に考えるようにはしているけど、「人類、オメーは unsafe である価値のないものを unsafe にしている」みたいな心情が根底にあることは否定できないのよね
あれよ、 C でも a *= 2; を a <<= 1; に書き直して高速化したつもりになる人みたいなのがいるじゃないですか。結局 Rust で unsafe バリバリ使っていこうぜみたいなことをするとこういう本質的に無意味なハックを注入して仕事した気になる人が多いのだろうという悲観的な予測があります
(ちなみにアーキにもよるがコンパイラは a *= 2; を a += a; にすることがある)
Rust は静的解析を強力にすることで最適化を言語処理系に任せようという思想なので、そもそも手動での最適化をゴリゴリしていこうというのはあまり有り難くない
(イテレータ使ったら境界チェック全て消え去るので unsafe なアクセスを使う必要が全くなくなるなどは、その一例)
* 標準ライブラリを見ろ
* どうしても足りないなら外部 crate を探せ
* 外部 crate で足りないときは、自分で実装する前に issue かプルリクを投げてみろ
みたいな……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
I/O の unsafety はまた別の塊だし、 I/O そのものでない他の処理とかは割と unsafe なしで済んだりしそう (要は safe な処理だけで一貫性破壊を起こすなという話なので)
たとえばコード全体を unsafe にしたとき Rust が C に成り下がるかというとそんなことはなくて、型システムとか lifetime とか trait とかは変わらず使えるので、その点では unsafe を無闇に使ってもなお C より Rust の方が良質なコードを書きやすいというのはある
unsafeが問題というよりはunsafeの外から見たときに満たすべき事前条件・事後条件・不変条件を破って全体がunsoundになるのが問題と考えています
軽率な unsafe 、だいたいコメントとか assert を欠いているので……
いや因果が逆かもしれない、 unsafe にちゃんと説明コメントと前後 assert を入れるような人は、それが面倒なのでそうそう軽率な unsafe を突っ込まない
unsafe を説明する attribute みたいなの入れたいわねという話があった気がするけど、進んでるかは知らない
unsafeの外から見たときにそのunsafeが安全性を破っていないかを自動的に検査できないからunsafeと呼ばれるわけで、そこで人間が失敗すると運が良ければいつかunsoundをタイトルに含むバグレポートが飛んでくるが運が悪いと静かに壊れたままになる
unsafe の怖いところは、バグが即脆弱性に繋がるケースが多いところであって、バグ自体の存在だけを問題としているわけではないという認識でいる
端的に言えば、不可避な unsafe を集約したうえで人の目を集めろという意見になるのかな。典型的には std とかだけど
バグは修正すればよいしいずれ修正される、それはそうだろうけど脆弱性があった場合は後処理面倒だぞとか
それでも誰かが unsafe を書かないといけないことは多いけど、そういう本質的に unsafe である必要のある処理は単体のライブラリとして小さくまとめられたうえで多くの人の目で確認されてほしいし、各々のライブラリが本質的に unsafe である必要のない処理を unsafe にしたりするのはどうなのと思う
Rust だと、 unsafe なコードは std には結構あって、ユーザはそれを信用することで自分で unsafe をほとんど書かずにすむ、みたいな感じなので、まあ unsafe な操作を単体で crate として分離して保守というのは現実的な妥協ではある
あるいは最近だと、 actix-web というフレームワークで unsafe コードめっちゃ多いやんみたいなのが話題になって、 unsafe をかなり削減したり、依存 crate の unsafe コードを確認しようみたいな動きもありました
Auditing popular Rust crates: how a one-line unsafe has nearly ruined everything
https://medium.com/@shnatsel/auditing-popular-rust-crates-how-a-one-line-unsafe-has-nearly-ruined-everything-fab2d837ebb1
unsafety こわ
unsafe ブロックは「コンパイラでは invariants の成立を検査できない処理を欠いたけど、開発者が保証するよ」という意味であって、「壊れてるかもしれないよ」では断じてないわけで、その辺りの認識をですね……
まあ壊れてるかもしれないつもりでコード書いてるわけじゃないかもしれないが、現実に、壊れてるんだ、その unsafe ブロックの中身は
たとえば
let mut flag = unsafe { std::mem::uninitialized() };
flag = true;
とか未定義動作になるんですが、これわかるか？ 絶対わからんやろ
C / C++ の UB で散々苦しんだので怖くて unsafe なんて迂闊に使えんわ
『プログラミングClojure』にマクロについて書くな、まだ書くな、必要なところに限って書け、という最適化の法則のパロディがあって、Rustのunsafeもそういうものだと思っています
unsafe を自動で検査できない以上、人の目がより多く集まるべきだし、結局やはり小さくライブラリに切り出して人々がレビューするという方式にするのが現実的に良い解決なのだろうというお気持ち
このアカウントは、notestockで公開設定になっていません。
まあそれはわかる、わかるけどそこまでできるならライブラリ作っちゃった方が早そう (ほんまか)
take_mut::take - Rust
https://docs.rs/take_mut/0.2.2/take_mut/fn.take.html
take_mut とかは一度はみんながやりたがる (けど safe にはできない) 処理なんですが、これ小さいからといって各々がオレオレ実装すると必ずやらかす人いますよ
これは &mut T から一時的に T の所有権を奪って何らかの処理をして、最終的に T を返してやれば全体としては辻褄合うやろというものなんですが。
T を奪って何かをしている最中に panic が発生すると、 UB に突入するわけですね。その辺りの対処をしているのが take_mut crate
このアカウントは、notestockで公開設定になっていません。
let _: () = for i in 0..3 {
println!("i = {:?}", i);
};
ライブラリがコミュニティによって安定して保守されるかどうかは利用者がライブラリを共に保守する一員になろうとするか、それとも単に便利なコードが出てくる魔法の箱と扱うかに影響されるし、最初の作者が意欲のある利用者から信頼できる人を見定めて責任を持つ側に迎え入れるかどうかにも影響される
@sksat 本質的に unsafe 、なぜならメモリセルが型の不変条件を満たさない状態で保持される可能性があるため
Tracking issue for RFC 1892, "Deprecate uninitialized in favor of a new MaybeUninit type" · Issue #53491 · rust-lang/rust
https://github.com/rust-lang/rust/issues/53491
std::mem::uninitialized::<bool>() が UB で世界が衝撃を受けた回です
Rust での bool が LLVM 側で扱われるとき、特定の範囲 (まあ 0 以上 1 以下かな) の値しか取らないというアノテーション付きの型になるんだけど、未初期化変数はこの前提条件を破るので、最適化とかでとんでもないことが起きても知らねえよ、みたいな話
@sksat ？ unsafe 関数と unsafe block の違いの話ですか
使っていたライブラリがいつの間にか廃墟になっていた 
を繰り返す人がもしいたら、ライブラリ作者は魔法の箱ではなくこれから共にコミュニティをやっていく（かもしれない）人間と捉えることから始めると 
unsafe 関数は「この関数は正しく使わないと safety invariant を破ることがあります」というマーカー
unsafe ブロックは「このブロック内の処理は safety invariant を守ることをコンパイラでは検証できないが、開発者がそれを保証します (ので成立しているとしてスルーしてね)」というマーカー
このアカウントは、notestockで公開設定になっていません。
Dependencies and maintainers | Drew DeVault’s Blog https://drewdevault.com//2020/02/06/Dependencies-and-maintainers.html
"Quit treating open-source projects like a black box that conveniently solves your problem. Engage with the human beings who work on it, participate in the community, and make it healthy and sustainable."
kawaiiを探して摂取して寝るぞ、kawaiiを探して摂取して寝るぞ、dependency hellとsustainabilityとmaintainershipはkawaiiじゃないからkawaiiを探して摂取して寝るぞ
kawaii は DLsite にあります (超適当)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@loliconductor https://mastodon.cardina1.red/@loliconductor/103090820891548098
これやっと形容する言葉を思い付いたんだけど、「倒れたドミノを見付けたので何気なく行き先に目を向けてみると、倒れてないドミノの大作が待ち受けていてこれからやってくる未来に気が遠くなった」みたいな感覚
https://mastodon.cardina1.red/@loliconductor/103090820891548098
これやっと形容する言葉を思い付いたんだけど、「倒れたドミノを見付けたので何気なく行き先に目を向けてみると、倒れてないドミノの大作が待ち受けていてこれからやってくる未来に気が遠くなった」みたいな感覚
オープンソース概念の無意識な風化への抵抗 - Ryusei’s Notes (a.k.a. M59のブログ)
https://mandel59.hateblo.jp/entry/2020/03/18/012206
議員苦言「カタカナ語分からない」 福井市の北陸新幹線観光プロモーション | 政治・行政,社会 | 福井のニュース | 福井新聞ONLINE
https://www.fukuishimbun.co.jp/articles/-/1050051?fbclid=IwAR3b1Sb_yLv3Z8pbX_mtpZrHwADp1hhV5oLjZdRTe8fLpkv_Q-pGcRQ08qI
> しかし、堀江委員は「私たちの年代は学校で片仮名を習っておらず、私は片仮名を英語程度にしか読めない」
学校で習わないと何もできんのか
同情はするが、学校で習わなかったが生活に必要な知識は無数にあるし、こういう奴らが「習ってない知識を使うな」みたいなことを言い出すのかもしれないと思ったら腹が立ってきたぞ (これは八つ当たり)
特にプロモーションの文脈において「私には何が良いのかさっぱりわからん」は「オメー向けの宣伝ではない」で一蹴されるだけの話なので、方向性としては「公的機関の予算を使うなら全世代あるいは全人類にアピールしろ」とか「我々向けの宣伝も用意しろ」になると思うわけで、カタカナの問題ではない
https://mstdn.nere9.help/@osapon/103870243743668374
開催国は参加国に含まれそうだし、その前提を破棄しないなら参加国ゼロだと開会式できなそう
南極開催とかで一度そういう暗黙の前提を破壊しておくのがよさそう？
落ちたら他のノードのリソースに少なからず影響が出るプロトコルのノードを建てるのに二の足を踏んでしまう
これは単に Mastodon がポンコツなだけの気がする
おひとりさま、運用しだすといろいろ出てくるからまず運用してみるといいよ メインアカウントとして（悪魔の囁き
このアカウントは、notestockで公開設定になっていません。
MMD のファイル形式、ライセンス文書に不安要素があってこれはアカンなと思ったのでやめました
『100日後に死ぬワニ』は前時代的なプロモーションによって台無しにされ、今もなお石を投げつけられている。｜ゲームキャスト｜note
https://note.com/gamecast/n/n66462a7c47ae
これ、宣伝のしかたが完全に悪いオタク向けのそれだったのに内容が全く悪いオタク向けでなかったので、ある意味究極のミスマッチだったわねという感じ
このアカウントは、notestockで公開設定になっていません。
モデラー界隈の闇もそうなんですが、 MMD の形式の規格文書が同梱されているソフトウェアのライセンスがプロプライエタリ感があり、 MMD 形式のデータやその処理系について OSS とすることの安全性に確信が持てなかったということがあり
ここで言う悪いオタクというのは、たとえば棺桶の絵を4コマ並べた後に「死から1日」とか書いちゃうようなクソマンガのセンスで喜べるような邪悪な感性の持ち主のことです
このアカウントは、notestockで公開設定になっていません。
#fedibird あくあーらさん @aquarla が実装された、時限ミュート機能を導入しました。
https://github.com/iwatedon/mastodon/commit/801143d52edcf39a8f42c38ab3f71829c4cd3bdd
アカウントをミュートする際に、ミュートする期間を指定することができます。（期間が過ぎれば、ミュートしていない状態に戻ります）
『今はちょっとだけ見えなくしておきたい』という時に、気軽にミュートすることができるようになるので、タイムラインをより快適に維持することができるかと思います。
まだ実装して間もない機能で、何か不具合があるかもしれません。もし何か気がついたことがあればご報告ください。
ちょっとまって
more than 3 は普通3を含まない、4以上でしょ！？
このアカウントは、notestockで公開設定になっていません。
サーバのホスト名として直腸異物リストから選んでいたとかは誰の話だったっけ
みなさんフェイクニュース情報源を uBlockOrigin とかのブラックリストに追加しないタイプ？
このアカウントは、notestockで公開設定になっていません。
DeepL によると禿は人生の夜明けらしい (???)
このアカウントは、notestockで公開設定になっていません。
人間関係のメンテに注力する気のない連中がそういうことしても破綻が約束されているし相手に失礼なのでやめとけ
これは任意のことに言えるが、他人を自分の成長のための道具にするな
このアカウントは、notestockで公開設定になっていません。
コンパイラより libc とかの問題を疑う (知らんけど)
このアカウントは、notestockで公開設定になっていません。
内部的に可変長のバッファを管理するようなものがあると、アロケーション (特に realloc とか) の戦略によっては malloc 回数に変化が出てきたりするかもしれないなと思った。
libc の範囲だと I/O 系かな
C++ であれば vector のバッファの伸ばし方みたいなのが効いてくるけど、 C でも I/O 関係では内部的に似たようなことしててもおかしくない (典型的には fprintf 系のシリアライズとかファイル I/O のバッファリングとか)
逆ハーなら釣り合うのでは？ と思ったけど、それオタサーの姫に他ならないな
このアカウントは、notestockで公開設定になっていません。
Mendeley Desktop もいつの間にか Qt じゃなくて Electron になってる……
ｷｭｰﾄからｴﾚｸﾁｵﾝになったのか、意味深 (適当) (下品)
画像が含まれてるかを考慮せずに、単に信用できるオタクのRTだから「目の保養」に抽出しているせいで、なんかFadis氏が突然目の保養タブにポップしてきた
ビルドシステム的なものを作りたさが出てきているんだけど、この方向に進むと絶対に頓挫することがわかっているので考え込んでいる
ところで rake のように依存関係をホスト言語ネイティブなオブジェクトや API で弄ることができるというの、かなり良いと思っているので参考にしたさがある (まあ DSL 文化みたいなのは Ruby 外に持ち出すと少々やりすぎ感を感じるけど)
データとして依存を記述するのが厳しいとか、中間ファイルの名前を自動的に生成したいとか、ネイティブなロジックで依存関係を抽出したいとか、まあいろいろ欲求がある
たぶん一番無難なのは ninja のファイルとかを吐き出す方向なのかもしれない (ほんまか)
このアカウントは、notestockで公開設定になっていません。
