MyPaint とか押してる

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

なるほど

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

熊本来てまで後輩と TOKYO MX 観ている

​

ああっ！一眼レフ忘れた！

金型学園四コマ漫画という文言を何回読み直しても意味がわからなくって怖くて泣いた

路面電車を死ぬほど久々に見た……。

あはー。天気悪いですねー。

飛行機のった

いやまあある意味イヴェントに行くんだけどさ。

今週末いろいろイヴェントやってるからそっち行きたかったね……。

何が颱風よ。晴れてんじゃん。

おでかけの準備でもするか〜

そのまま寝過してもいいよ

もう寝て

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

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

異常すぎる……。

こわすぎない？

7 年も口の中にセミを飼うかるばぶさんすごいホラーなのだけれども

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

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

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

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

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

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

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

あらあら。おるみんさんは不死ではありませんよ？

研究に限らなくても，たとえば WSL をいつまでも Bash on Ubuntu on Windows と言ったり Modern UI をいつまでも Metro UI といったりみたいなケースはわりとあると思う

とはいえ，一部の研究者しか知らない論文でしか見ないような語句や概念がいつのまにか人口に膾炙して一般化したとき，微妙に語句が変化したり新たな語句が使われているが最初から追ってた人が後で知識アップデートできてなくて……みたいなケースは考えられるのでアレ

そういった最新の語句はともかくかなり基礎的な語句は一般的な用法に合わせたいよね

まあその分野の論文を色々眺めてなんとなくコンセンサスが取れてそうな語を選ぶのが better なのだけれども

辞書に入っている言葉だけだと最新の研究の用語がほぼ喋れなくなるのだなー

私の ArchLinux も steam と wine のためだけに lib32-* なパッケージがめっちゃ入っとる

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

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

やっぱり前世の行ないでしょそれ

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

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

前世の行いかな。

どうやったらボられるの

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

売り物じゃなければ作品でも自前実装しまくるのもアリっちゃアリだけど（たまにそれがネタになるときもある

練習として車輪の再発明をすること自体は全然アリなのだけれども，何か作品とかプロダクトとか作るときに自前実装はアカンね……

自分で悩んで実装したやつ遅いとかもまああるけどそれより何よりもバグっている確率が高いのがアレなんですよね。頭の良い人がよってたかって実装したやつのほうがバグが少ないんだよなあ……

勉強になりました

ソートアルゴリズムの歴史はそういえばあんまり知らないし今度調べておくか

基本選択法も基本挿入法もググったら出てくるけど，基数ソートとかマージソートは基本なんちゃらって言わないし，基本なんちゃらって言うやつをまとめて基本法って言うのはなるほどなあという感じです

なるほどなぁつってる

基本交換法とは - IT用語辞典 Weblio辞書 https://www.weblio.jp/content/%E5%9F%BA%E6%9C%AC%E4%BA%A4%E6%8F%9B%E6%B3%95

クイックソートとかは交換ソートの発展だしそういうのの基本的なアルゴリズムのことかなって思うけどじゃあマージソートや基数ソートなんかはなぜ含まれてないの……みたいになってアレ

基本〜法という言い回し初めてみた……。

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

what does the 'this' refer to ...

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

まあ C 言語は標準ライブラリで qsort があるし，C++ も std::sort で intro sort というクイックソートの改良が実装されてるし，ソートを自分で実装しないのが一番速いんですけどね！

マージソートやクイックソートは分割統治なのでそういうのはマルチスレッドとかマルチプロセスにしやすいですね。

あとソート済みの配列に対してソートする可能性があるかどうかとかそういうのでも使うべきアルゴリズムは変わる

まあ安定ソートとか内部ソートとかは常にあるとうれしいとかじゃなくて，そのユースケースによって必要かどうか考える感じなので……

（基本法ってなんだろう）

マージソートだとクイックソートより空間計算量は大きいけどまあ最近メモリ大きいし

マージソートとか安定ソートだし N(nlogn) だし実装そんな難しくないしべつにいいのでは感ある

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

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

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

スライド書けたうれし〜

これなにこれなに

よかった

@toshi_a 強く生きろ

@toshi_a #いいえ

Hey Siri, 颱風を日本から消して

こんなことを言う悪い子は原稿炎上してほしい

べつに明朝体のままでもさして困ってなかったけど，最近 Reveal.js を使い出したら h1 や h2 の和文だけ明朝で困る（欧文は Source Code Pro になってる）

みたんですよ

なお今日には会場へ発つものとする

前者の原稿のためのスライドがまだ出来ていないが……。

原稿は 7/4 締切のやつと 7/20 に締切の同人誌のがあったけど今はとくに原稿はないです

Web を明朝体で見たいなあと思って sans とかも明朝を指定してたことがあるけれど最近は戻していて，これは良いんですが未だに FireFox で一部明朝体になってて謎

青年になってもイマジナリーフレンドを持っている人多すぎる……。

世の中の全てを豫知していこうな

あんなふざけたパッケージを管理するハメになったの完全にとしぁさんのせいだから

AUR の ruby-totoridipjp の管理者です

まあめったに更新されないパッケージ or mikutter-git の依存の gem 由来パッケージだからそんな管理大変じゃないしいいかみたいな感じ

これで AUR の管理ラクになるな〜って思ったけどみたらまだ管理してるパッケージが 52 あった

今となっては mpg123 が gst-plugins-good に昇格して ArchLinux のバイナリパッケージになったし，わりと管理が大変で半年放置してしまってたので，そこらへんの管理してた lib32-* を全部 orphan にした

AUR で大量に lib32- を管理していたのは lib32-gst-plugins-ugly と lib32-gst-plugins-bad を管理していた関係でその依存が必要だったからなのだけど，なぜそんなことをしていたかというと wine で 32-bit app を動かして中で MPEG-1 とか再生されると gstreamer の mpg123 のプラグインの 32-bit 版が必要になるからだった。

ソースコードを読むことは簡単でもそのソースコードが意図する動作は最後まで手動で実行していく必要があるので難しくはないけれども面倒すぎる

実行を脳内でトレースするのは難しいけれどもソースコードを読むこと自体は左から逐次命令を解釈するだけだからそれも簡単な気がるな。

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

POINTER_REGISTER は RSI レジスタだし最終的には実行するコードを全部 buf に突っ込んでスタックに置いたら，RSI レジスタを動かして buf を実行するようにコードを吐いてるっぽい

でも全部メモリに置くんじゃなくてちゃんと RAX とか RDI とかのレジスタも考えて使ってるっぽいな

さっきの brainf*ck の JIT compiler のソースみてみたらやっぱり brainf*ck の 8 つの命令を愚直に native code にして配列に突っ込んでるだけっぽい https://github.com/m4tx/uefi-jitfuck/blob/master/src/jit/JIT.c

legacy な BIOS の x86 なら単純に in 命令と out 命令でよさそうだけど

文字の入出力だけが曲者ね。

私も JIT コンパイラの作りかた良く知らないけど，brainf*ck なら + とか - は適当に add とか sub とかにすれば良さそうだし，他の命令も . と , 以外はだいたい素直に機械語にすっと変換できそうだから，配列作る brainf*ck を機械語に置き換えていって配列に突っ込んでいく → スタックに実行属性つける → 配列の中の native code を実行 とかで良さそうな気がするからあんまり考えることなさそう

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

よくよく考えたら UEFI アプリケーションといってもただのベアメタルプログラミングだから x86_64 へ JIT コンパイルする brainf*ck 処理系と考えるとまあ普通にありそうだなって気がしてきた

ほたさんにテロしなきゃ……（使命感）

頭おかしいすぎる…… >> m4tx/uefi-jitfuck: A JIT compiler for Brainfuck running on x86_64 UEFI https://github.com/m4tx/uefi-jitfuck

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

@reiden グローバル変数は使わない，というのは絶対の原則ではなく，不必要にグローバル変数を乱発するとバグの温床になるだけというだけなので，設計によってはグローバル変数が最適解のこともよくある

@reiden グローバル変数ですがそれを良しとするかは設計方針の問題で，main() で宣言して常に引数として渡すとかして複数の関数内のスコープで参照を持たせるのも可能ですが意味もなく関数の引数を増やして無駄に I/F を複雑にすることでバグを増やすのなら，結合度が上がってしまうけれどグローバル変数にしてしまうのも手です

@reiden さっきも書いたがそれを直接言及あるいは掲載しないというのがミソでそのようなポリシーの元運用しています。誰かが勝手に到達して察するのは構わないけどそれを直接言及しないで欲しい（というか本人が一度もしていないことを勝手にするのはどうかと……）

nginx しかつかわないひとなので……。

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

中間証明書を連結しないでも使える時を知らない

@reiden そういうのよくないと思うよ（本名やそれに関連する情報はここに載せたりそれがあるページも直接 toot したりしてないので）。
それはそれとしてなんですか。