portal の edge glitch、部屋に入る以外の用途でまともに成功したことないんだけど (特に portal の真上に立ってる状態にするやつ)、あれ難しすぎない？ あるいはルート短縮になりようなやつが悉く修正されてるだけ？

Was the edge glitch in chamber 17 fixed? : Portal
https://www.reddit.com/r/Portal/comments/6ka6dq/was_the_edge_glitch_in_chamber_17_fixed/

頑張ったら chamber 15 を OoB で 40 秒以内にクリアできるようになった

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

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

#portal chamber 13, least time (0:18) with OoB (clipping glitch)

#portal chamber 15, least time (0:27) with OoB (clipping glitch)

#portal chamber 18, least time (0:17) with OoB (edge glitch)

おまけ: chamber 13 の OoB で壁に埋まって死んだ #portal

は？ portal してたらもう朝なんだが

NeruPointerException

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

https://mastodon.cardina1.red/@lo48576/100656624753120387
半年で68時間か……

このまま portal で遊び続けたら人生溶けるわ

ｵｯ そろそろ私も sway に乗り替えるかな？
この時のために XMonad から i3wm に乗り替えたからな

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

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

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

事あるごとに思い出してしまう

普通の東工大生が【gentoo】入れてみた。 : 東京工業大学 ロボット技術研究会
http://titech-ssr.blog.jp/archives/1013311908.html

偶数なら2で割り奇数なら3倍して1を足す、この操作を繰り返すといつか必ず1になるという予想がある。
この反例を見つけようとして計算を行うと無限ループになると予想されるため、兵庫県警に叱られてしまう。
ゆえに、この予想は「『コラッッ』予想」と呼ばれる #適当

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

https://twitter.com/ymduu/status/662288360367521792 #tw

Java シコの人です

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

これは双方向リストの素朴な実装が (特に GC なしの環境で？) 極めて危険であるという事実を明確化していると考えるべきで、そういった「隠されていた不安全」を暴く仕組みとしては Rust の safety はかなり強力だと思います

というか Rust で unsafe なコード書くのと、 C や C++ のコード書くの、実際大差ないと思うし、 unsafe な部分を封じ込められるというだけでも Rust には大きな価値があると思うので、強く推奨

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

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

ミスって空リプした、失礼しました

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

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

これはわかる

たとえば最近の Rust だと、 NLL (Nonlexical lifetime) でライフタイムの範囲をより精密に推論・切り分けするようになったり、 Pin でアドレス固定を表現することで自己参照を安全に実現する仕組みを追加したりなど、まあまあ改善されてきてはいるけど、やはり最後の最後の部分は人間がやるか、コンパイル毎にやれないクソ重いチェックを外部的に行うしかなさそう

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

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

これは真理なんだけど、ガッチガチに証明書くようにすると基本的に表現力がガタ落ちしたりコンパイル時間が無限に発散することが知られており、バランスは難しい

Rust だと、 unsafe なコードは std には結構あって、ユーザはそれを信用することで自分で unsafe をほとんど書かずにすむ、みたいな感じなので、まあ unsafe な操作を単体で crate として分離して保守というのは現実的な妥協ではある

あるいは最近だと、 actix-web というフレームワークで unsafe コードめっちゃ多いやんみたいなのが話題になって、 unsafe をかなり削減したり、依存 crate の unsafe コードを確認しようみたいな動きもありました

まあ Rust を使いたがるような人たちが使う言語なので、コミュニティの意識も (今のところは) 相応に高いという印象です

あとなんだっけ、 unsafe ブロックにコードが safe である理由をアノテーションできるようにしようみたいな機能も提案されていたような (その後どうなったか覚えてないけど)

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 こわ

証明な、してほしいよな……

しょうもない“いかがでしたかブログ”を警告するGoogle Chrome拡張【レビュー】 - 窓の杜
https://forest.watch.impress.co.jp/docs/review/1174083.html

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

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

branch に対して discussion を残しておきたいという動機は考えられますね >独り開発でﾌﾟﾙﾘｺ

Generics support · Issue #8 · lo48576/opaque_typedef
https://github.com/lo48576/opaque_typedef/issues/8

私もこんな感じで issue を立ててブランチやコミットに紐付けたりすることはあります (プルリクはブランチを不可分にしただけの issue に過ぎないのでだいたい同じこと)

discussion を GitHub のようなホスティングサービスや ITS ではなくリポジトリそのものに保管しようという試みもあり、 git-dit などが一例です

GitHub - neithernut/git-dit: Decentralized Issue Tracking for git
https://github.com/neithernut/git-dit

git における tag は、特定のコミットの別名にすぎません

tag も branch もコミットへの参照に過ぎないけど、 tag は参照先を他に変える機能がなくて branch にはある

branch という場合、 branch が HEAD (先端) として指しているコミットを言いたい場合と、そのコミットに至るまでの一連のコミットのチェーンを言いたい場合があるので、これは文脈次第

git におけるバージョン管理はスナップショット前提なので、コミットは(内部表現はともかく)概念的にはリポジトリのスナップショットで、つまりタグもスナップショットについて名前を付けているだけ

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

バージョニングについては、ライブラリを書くならとりあえず semantic versioning を使っとけというお気持ちですね

完全にエンドユーザ向けのアプリケーションなら、開発スタイルに合わせるか、スナップショットとして日付をバージョンに使うか

セマンティックバージョニング、大雑把には

0.x.y なら:
* x は互換性破壊で上げる
* y は互換性の破壊されない変更で上げる

x.y.z なら:
* x は互換性破壊で上げる
* y は機能追加 (互換性破壊のない変更) で上げる
* z はインターフェースなどに変更のない修正で上げる

くらいのお気持ちでやるといいですたぶん

x.y.z については、だいたいライブラリ利用者が 「x.y.z 以上 (x+1).0.0 未満」みたいな指定を行うものなので、そこから逆に考えるとこれが良さそうだというのは納得できる。
0.x.y は early stage で互換性破壊が起きやすいので、 x.y.z の桁をシフトして z を捨てた感じ

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

1.0.0 以降は安定版 (互換性破壊はそうそう起きない) という暗黙の合意があるので、たとえば Rust などだと「1.0.0 以降にするなら、依存ライブラリもすべて 1.0.0 以上のものを使いましょうね」みたいなガイドラインがあったりする (不安定なライブラリに依存する安定なライブラリ #とは ということ)

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

そんな感じ

なので、 semver について「互換性がなくなるたびに番号上げてたら 42.0.0 とかになるだろ」みたいな意見がたまにあるんですが、これに対する返答は「そんなにコロコロ互換性がなくなるライブラリが安定してるわけねえだろ、落ち着くまで 0.x.y やってろ」です

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

まあ仕方ない

たしかに占有している名前が広い、「東京の大学は東京大学なので、東京大学以外は東京の大学じゃなそう」みたいなアレを感じなくもない (適当)

日本大学とか亜細亜大学とかみたいな占有範囲の広い名前は †強い† ので、東工大ももっと広く名前をとって “工業大学” (The Institute) とか名乗ってほしい (適当)

そのうち宇宙大学とか時空大学とか “大学” (The University) とかできてほしい (適当)

そういえばどこかの国に私立パブリックスクールあったな、あれもすき

通信制大学 | サイバー大学
https://www.cyber-u.ac.jp/

こんなのもありましたね、これも割と好き

アプリケーションについては依存される場合のインターフェース互換性を気にしないことが多いので (いやそれは望ましくないんだけど)、日付とか付けてしまいましょうというのは合理的ではある

CLI だと依存性重視でいつまでも deprecated なオプションを残したりするので割と互換性は保たれやすく、 GUI ならそもそも互換性もクソもないので……

まあ依存されるならライブラリ部分とユーザ向けフロントエンドを分離するのが良いのでしょうね (しらんけど)

git入門の前に知っておきたい概念 - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2016/06/27/before-git-introduction/

これはね、 git について説明しようとしたけど面倒になったうえ読みづらいしもういいやと思って途中でやめたけど、せっかくなのでとりあえず公開しとくかと思って雑に公開したやつです

本当は snapshot と diff の概念を説明しようと思ったんですが、気力が保たなかった

人々は VRM を使いはじめているのに、私は FBX のデータ構造を理解しようとしている……何故……

花粉症は酷いし車で本を読むと酔う、睡眠は10時間必要で関節は固い、こんなポンコツな体だけど、 portal をプレイしても酔わないというこの一点だけでも人類の上位数%にいるといえる

どうも chamber 16 の clipping glitch も修正されてるっぽさがある…… #portal

とりあえず edge glitch がまだ使える場所があるので chamber 16 も高速クリアできそうということはわかった

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

プロ👏

まあ「Rust は (同じ安全性のコードを書くなら C や C++ よりは 1048576 倍) 簡単」は事実

今日も今日とて portal

#portal chamber 16, least time (0:26) with OoB (edge glitch)

Portal の OoB にもぼちぼち慣れてきて、 YouTube に上がってる動画とも少しは張り合えるようになってきた (speedrun のプロや ABH / AFH を使い熟してる人々には遠く及ばないけど)

#portal の speedrun で ABH とか AFH を息をするように使ってる人たち、何かに似てると思ったんだけどやっとわかった、マリオカートで所構わずミニターボ使うアレだ

これ以上 portal するとマジで春休みが消滅するので鋼の心で終了した

正直 glitch やら設計ミスやらで数回分の動画を作れる程度のネタはたぶん貯まっている

かわいい女の子に portal の glitch の解説してほしいな……

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

人類って感じだ (?)