@babukaru 翻訳の難しさというより、英語版だと対象を選ぶこと（今回だとCR 115.1c, 601.2c, 603.d辺り？）自体が単独の文になっているわけではなく、文章中にtarget [something]が含まれる呪文や能力がスタックに乗る時点で対象を選んで宣言することがルールに定義されている（テキスト自体には対象をいつ選ぶかが書かれていない）のに対して、日本語版のテキストだと「〜を対象とする。」という単独の文があってそれが対象を選ぶタイミングを決めているかのように見えるというテンプレート由来の難しさがありそうですね
@babukaru 少なくとも私は解決って結局なんなんだと思ってルールを読むまでは「〜を対象にする」という文面から解決するときに行われる処理の一部だと思っていて、MTGAはやたら早く対象を選ばせるなと疑問に思っていました
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Dockerで再現性がある（と信じたい）構築手順や結果をやり取りできるようになったのはとても良くて、Dockerが秘伝のレシピと化してどの部分が不可欠な部分でどの部分が選択の余地がある中で一つに定められた部分なのかがわかりにくくなるかもしれないのが悩ましい
インストールマニュアルにHardware PlanningやらDatabase Backend Selectionやらのセクションがあるプロジェクトは本当にえらい
今話題になってるこれ ( https://misskey.dev/notes/7z7qn7tr15 ) 日本人のSorry! Japanese Only.を逆に外国人がやったみたいなんじゃ 
このアカウントは、notestockで公開設定になっていません。
それは（観測範囲にいなかっただけで実際いるという可能性はひとまず棚上げするとして）日本語話者がどちらかというと「入っていく」側だったからで、逆の立場になることは十分にありえることだと思う
Firefoxの開発ツール（Ctrl+Shift+Iのアレ）を実装しているJavaScriptコードにTypeScriptで型検査できるコメント（ https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html のこと。.jsを.tsに書き換えているわけではない）を実験的に導入し始めたことを知った https://groups.google.com/forum/m/#!msg/mozilla.dev.platform/qLdRm-VutMg/RbHnTWo2DAAJ
現時点では開発ツール担当チームのメンバー（他のプロジェクトでFlowやTypeScriptの経験がある）が実験的に自分たちのコードにコメントで型注釈を付けて手元で検査している段階で、CIの過程で検査する・.tsに書き直すといった他のチームとの議論や調整が必要な作業は行っていない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Are We Fission Yet? https://arewefissionyet.com/
Firefoxのcontent processをeTLD+1ごとに分離するFissionプロジェクトのページ
eTLD (effective TLD) はたとえばwww.postgresql.jpにとってのeTLDはjpだけどwww.mext.go.jpにとってのeTLDはgo.jpといった感じのもので、eTLD+1は「サイトごとに」何かをするというときに実用上使いやすい単位
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
GNOME files defense against patent troll – GNOME https://www.gnome.org/news/2019/10/gnome-files-defense-against-patent-troll/
「mikutterで艦これ、やってみました。動作しました。ruby1.9だと動作しないかも? なんでアイコンが全部妙高さんになるんですかね……」 https://twitter.com/kotatsu_mi/statuses/408510209200361473
Ruby 1.9、いわゆる文字列のM17Nで結構影響が大きいリリースだった記憶
年末リリース予定のRuby 2.7、GCにコンパクション入ったのか、すごい
かつては日蘭学会があって，うちのどっかにもそこが出してたオランダ語の教科書があるが，日蘭学会はもう解散してしまって，日本でオランダ語関係の組織というと，先のライデン大学東京事務所と，アーツフランダース・ジャパン（http://www.flanders.jp/ ）とかくらいだ…
日本でオランダ語をやる人は，オランダそのものの研究以外に，インドネシア史の研究で学ぶ・必要になる人も多い．
へー
「日本が元気だった時代は政府としても日本に触れたい人材の輩出にきちんとお金を出していました。80年代はそれが顕著でした。海外の大学に日本研究や日本史を教える人がいなければ、寄付金を出して「新しく日本コースを作ってください」と支援をしてまわっていましたから。そういった日本コースは5年ほどで軌道に乗せることを目指して後は大学に自己資金で運営させる手法が確立していました」
今、ケンブリッジ大学の日本研究が危ない⁉ 【ケンブリッジ大学日本研究教授ミカエル・アドルフソン】 https://guruli.net/community/508/
ヨーロッパで日本学というとレイデン大学に日本学科があって，これは世界で最初に設置された（1855年）日本学科として知られている．
ライデン大学東京事務所 http://www.luot.jp/
Firefox 70登場 - 高速JavaScriptエンジン搭載 | マイナビニュース https://news.mynavi.jp/article/20191023-913301/
タイトルを見てSpiderMonkeyの改良に重点を置いて解説しているのかなと思ったけれど公式のアナウンスと同じでETP重点だった
The Baseline Interpreter: a faster JS interpreter in Firefox 70 - Mozilla Hacks - the Web developer blog https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
ちなみにJavaScriptの性能について説明しているのはこの記事で、インラインキャッシュを搭載したバイトコードインタプリタを昔ながらのバイトコードインタプリタとベースラインコンパイラの間に置くことで、大量のコードをJITCに流し込むことなくプロファイリングできるようになってロード時間やメモリ使用量に少し良い影響が出たという話
典型的なJITコンパイラ（JITC）はまずバイトコードインタプリタ上で実行して（直接ターゲットの機械語を出力していた昔のV8は典型的なJITCではないものとする）これはコンパイルしようと判断した一部を改めてコンパイルするようになっていて、最近ではそこそこのコードを出力するベースラインコンパイラと最適化をガッツリ施すコンパイラの二段構成（直接機械語を出力していた頃のV8もこうなっていた）が主要JavaScript処理系では主流になりつつあるのですが、ベースラインコンパイラでコンパイルするのもタダではないのでインタプリタが賢くなるとうれしい
そもそも、JITCであってもすべてのコードが強烈な最適化コンパイラを通るわけではない（別にそうしてもいいけれど、メモリ使用量とコンパイル時間の増加で割に合わなくなる）のでバイトコードインタプリタが軽くて速いのは大事だというのは割と意見が一致するところ、だと思う
「最初から機械語にコンパイルして、プロファイリングしてホットな箇所だけ更に最適化します」「正規表現式そのものをコンパイルするJITCを用意することで正規表現のマッチングが速くなります」などで知られるV8もバイトコードインタプリタを実装して https://v8.dev/blog/ignition-interpreter 今年とうとうJITCを使わないモードをサポートした https://v8.dev/blog/jitless
JIT の話題で思い出したけどこのまえの USENIX ATC の best paper の『A Retargetable System-Level DBT Hypervisor』はなかなかよかったよ。CPU emulator として QEMU よりこっち，なんてのも有り得るのかもなと考えたりしたぐらい（現実的には優れたアーキテクチャだからって既存のシステムを置き換えたりはしないだろうけど
A Retargetable System-Level DBT Hypervisor | USENIX https://www.usenix.org/conference/atc19/presentation/spink
『A Retargetable System-Level DBT Hypervisor』は CPU マニュアルみるだけで記述できるような instruction の semantics を記述できる DSL が用意してあって，これを記述して offline の compiler に喰わせて unikernel とがっちゃんこする。で，unikernel なので QEMU と違って異なるアーキテクチャのゲストコードが Ring 3 ではなく Ring 0 で動かせる。しかも unikernel と VMM が協調してより深い水準で JIT する。
QEMU の新しい CPU target 書くのはめっちゃ大変な上にそれで OS までちゃんと動かせる system mode やろうとすると QEMU を奥深くまで知った上で target のアーキテクチャも深く知っててさらに手動で最適化できる職人でなければならなかった。それでも regression しまくって Arm64 のバグ修正 commit だけでも 100 近い。
このアカウントは、notestockで公開設定になっていません。
ところがこの『A Retargetable System-Level DBT Hypervisor』ではそこまで知識なくても DSL 書くだけだし，それでいて QEMU より速い。
PyPy3 7.2.0はインタプリタ起動時にfortuneしてくれないので7.0.0でしてくれたのは開発版のみ有効なイースターエッグがオフにされないままリリースされただけっぽいな（あるいは完全に削除されたか）
dynamic binary translation ではないけど他にも面白かったのは x64 と Arm64 の fat binary の unikernel 作って HPC の task を VM migration（between heterogeneous ISA）やって offloading しよう！SBC な Arm64 マシン性能低いけど価格や消費電力がそれ以上の規模で低いからこれたくさんならべてうまく migrate と scheduling したらコストかけずに高速化や！というやつ
Popcorn Linux のひとたちがやってた HEXO というやつ（名前かぶりネタかよ
このアカウントは、notestockで公開設定になっていません。
それがまさに現代のJITCがバイトコードインタプリタとコンパイラの二段構えになっている理由ですね
Popcorn Linux - HEXO - Heterogeneous-ISA EXecution Offloading of Unikernel VMs
http://popcornlinux.org/index.php/hexo
java -clientかjava -serverかは64ビットOS上だと無視される（常にserver VMが使われる）ようになって結構経った記憶がある
このアカウントは、notestockで公開設定になっていません。
@charsiuCat Popcorn Linux がそこらへんの先行研究になってて，まず checkpoint はユーザーがアプリ書くときに仕込む（HPC の offloading のための migrate なのでいつ migration されるかわからん live migration と違ってタイミングがハンドリングできる。で，関数呼び出しのときだけ仕込むことにしてしまえばスタックやレジスターは関数のエピローグプロローグの処理にプラスαなだけなので簡単になる
@charsiuCat あとツールチェインが同じでライブラリも同じの使えるので malloc のアルゴリズムは揃えられるからヒープの確保のされ方は考えなくていいし，最近世の中はリトルエンディアンに征服されたからそこも考えなくていいし，グローバル変数や TLS のレイアウトはリンカーを改造して揃えて解決
HPCだからASLRとかやらなくていいし考えなくていいんだよ的な発想か、まあ確かに
Popcorn Linux の team は Live migration 文脈でも heterogeneous ISA migration ネタ出してた気がするけどあれは ASLR 諦めることにしてた気がする
JITless V8、ゲーム機のメーカーはゲームソフトにJITCを載せることを禁じている場合があり、またJITCを使うとコンパイル後のコードを保持する都合上メモリ使用量が増える傾向にあるので、組み込みシステムよりの環境だとJITCが禁止されていなくてもバイトコードインタプリタがうれしい場面がある（V8にバイトコードインタプリタが載ったのもAndroid向けのChromeに欲しかったからという背景がある）
このアカウントは、notestockで公開設定になっていません。
heterogeneous ISA migration はプロセスレヴェルで弱い方から強い方に移るのはすでに研究があって，たとえばスマートフォンのタスクをクラウドで処理とかが考えられるんだけど，HEXO は逆で x64 から Arm64 に migrate させてるししかもプロセスの一部タスクとかじゃなくて VM まるごとどーんと全部移せてる（のに全体として高速化できてる）のがミソ
2016 年の京都の HPDC の併設ワークショップで出てきた HermitCore という Unikernel を移植して使ってるしツールチェインも popcorn linux の産物の応用だからフルスクラッチよりかはかんたんなはずだけどそれでも絶対大変
big.LITTLEといえばEnergy Aware Schedulingって結局mainlineに入ったんでしたっけ？
HPC にとって OS は noise だけどかといって baremetal フルスクラッチはしんどい！そこで Unikernel！みたいなハナシ > HermitCore
Linux Kernel | Energy Aware Scheduling (EAS) – Arm Developer
https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/energy-aware-scheduling
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
nearとfarの違いが分かりやすいという意味ではインターコネクトバスが遅い方が教材になる説
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
長崎の寺町通りはお寺が並んでいるんですが京都の寺町通りもそうなんでしょうか
このアカウントは、notestockで公開設定になっていません。
松江の寺町は松江藩開府のときに意図的に寺社をまとめたり他所から移らせたりしたらしいので寺ばかりだった
このアカウントは、notestockで公開設定になっていません。
Social - アプリ - App Store - Nextcloud https://apps.nextcloud.com/apps/social
Nextcloudだとこれ
あの手のサービスを自分で建てても完全にプライベートなものとして運用することが珍しくないのであまり見かけないのも仕方ないとは思いますし、まだ機能的に足りないというのもありそう
Firefox Nightlyでmegabarを試してなるほどねになった
megabar、そこまで好きではないけれど、ひどいバグは大体直されたようで動きはする
megabarというのは検索したりURLを入力したりできる例のバーの新デザイン案のことで、今Nightlyで実験中の機能
の投稿
shinderuman@ding-dong.asmodeus.tokyo
このアカウントは、notestockで公開設定になっていません。
自分は今回も数日使っていればなれるとわかっているのであまり好きではない程度の変更なら問題ないけれど、正式版になってから不満を表明する人々が現れるだろうなという気はする
食べると喋るは確かに母音が同じだけど音声ベースで学習する機械翻訳システムがあるかなにかだろうか
このアカウントは、notestockで公開設定になっていません。
変数を箱に例えると同じ実体（OOPLに限らないのでオブジェクトという言葉をあえて避ける）を指す複数の変数が現れたときに意外な振る舞いに出会う（特に最初に学ぶ言語で実体の内容を書き換えることができる場合）けれど、一方で変数をラベルに例えると値として等しい複数の実体をそれぞれ指す変数が現れたときにこれらが同じ実体を指しているのかどうか悩む可能性があり、メタファーやめた方がいいんじゃないか感がある
変数そのものを実体として操作する機能がその言語にあったとしても変数について説明を受ける段階でその機能を必要とすることは多分ないので、箱やラベルのような実体があるものに例える必要もあまりなくて「ここで[1, 2, 4]をaと名付けます。ここのaのような名前を変数と呼びます」のような実体がなさそうな説明の方がかえってよさそうな気がしている
