自分のコードを直したいんだけどホントにいの一番に直したいのはAndroid Studio Fだよ…emulatorでもdeviceでもback押して反応するまで1秒とかかかるデバッガおかしくね…（Eの頃から実装が変わったのはわかっている）
あまりにもおかしくてemulator is slowみたいな雑なissueが複数見られるし、そんな雑なissueがassignedにまでなっていて、どうやら中の人も気づいていそうではある

GDGのDevFest、Googleの指示なのか「名刺を2枚お持ちください」って書いてたのが思いのほかツッコミを受けまくっていたのが伝わったのか、今日のメールには「* お名刺をお持ちではない場合は」云々が追加されていたｗ

sfizzのコードがAndroid Studio Dでビルドすると問題なく実行できるけどFでビルドするとクラッシュする問題があって、issuetrackerにレポートするにしても問題の切り分けがたいへんめんどくさい。まあ仕方ないからまだ試しているけど…

ちなみにEはFと同じ感じのランタイムクラッシュになるんだけど、正確に同じ内容なのかどうかはこのバグのせいでデバッグ実行できないからわからない（次で直るはず） https://issuetracker.google.com/issues/255902052
これも早目に報告しなかったらstableまで引っ張ってた可能性あるし、新しい問題もできれば対処しておいてほしいんだよな…

@ikeji Ubieの話だとして、カジュアルなのはnode、ガチなのはgoでやっていきそうっていう印象があるかな…

オーディオプラグインをサポートするMuseScoreでstableになったのは4が初めてかな。そういえば何をどうやってサポートしているのか全然把握していないな。自前実装なのかしら。
https://musescore.org/en/4.0

@ikeji そういう意味のカジュアルというよりは、メモリリークの原因究明が難しくてハマるような複雑が出てこないようなカジュアルなプロジェクト／部品みたいな意図でした。

ブレークポイントで停止しているデバッガーのスタックが実際のコードと全然違う内容になる減少に遭遇して、そのでたらめなスタックの示す行にジャンプするとそのファイル自体は正しく読めるから、スタックがぐちゃぐちゃになってるだけなんだけど、lldbがおかしいのか（そんなことあるかな…でもAndroidサーバならAppleじゃなくてGoogleだろうしな…）、LLDBFrontendがおかしいのか（GoogleかJetBrains…ありそう）、あるいはndk-stackが絡んでるのか（絡んでたらありそう）…てかアプリ開発者が探るようなことじゃないぞこれ。