ん〜なんだろうこれ

libmruby.aを適切にプロジェクトにリンクするための設定、もしかしてpodspecで動的にやったらよかったりせん?

悲惨

なんらかのスクリプトで頑張って.frameworkにバンドルするとかさーなんかしらせんと実用厳しいな

今は動作確認用の環境作ってるだけだから、これ以上やらんでも良いのだが。

おっおっ

GCDあると全てを任せられて楽やな

これでDelayer.run回し放題

command DSLで登録されたコマンドを全部収集するC API欲しいな

やーでもPlugin.filtering(:command, {})するだけではあるんだよな

This account is not set to public on notestock.

mikutterで培ったCairoのスキルを活用するな

Objective-CのCの部分を活用している

Swift、コールバック関数としてそのままクロージャー渡せるのか

あっそれいいな

うんこ!

巻き込むな

週間mikutterを作ろう
適当なCocoaアプリにmrubyで生やしたコマンドを見せるところまで。

やっぱり書くのに腕力が必要だからCレベルで取りやすい情報に一旦落としこむレイヤーが欲しいな

いちいちinternしてmrb_hash_getするのクッソだるいw

いやまあそこだけならCならマクロ、他でもなんかラッパー書けば十分か…

お、Swiftにもそういうのあるんだ。ならmrubyのオブジェクトに対するプロキシ作成余裕やん

今なんとなくObjCで書いてる動機、C APIの呼び出しのための記述習得コストをゼロにできるただそれだけです

結局データモデルとのやりとりはそういう動的アクセスが容易になるやつを介してやるのが都合良くて、俺が今セットアップしないといけないのは他だなあという感じはある。ネイティブPluginのイベントハンドラ登録とかその辺のショートハンドとか?

まあそれも、なんか腕力でバインディング作りこむと割とどーでもよいというのは、yukari-exvoiceが示してるんだよな…

任意のオブジェクトに対してダイナミックな呼び出しになるようなのを作るのも……まあそれができる言語なら悪くはない。色々考えなくて済む未来がありそう。

まあmrubyからC世界に返ってきたオブジェクトは全て保守的にGC Protectされるぞという注意点があるが…

雑にやりすぎるとあらゆるネイティブからmruby VMへのコールで解放不能オブジェクトが生える

またyukari-exvoiceのコードとか読んでどこを楽にするか考えてみよう

例外を使った大域脱出、mruby-catch-throwで見た

mikutterのcommandエミュレーションのためにProcに何を渡さないといけないかは文書化したほうがいいな

呼び出すことそのものは簡単なので

会社のWi-Fiに繋がってるの忘れてTissueのリンク踏み抜いたので徳が下がった

めちゃくそねむい

家帰って遊びてえ〜

やっとか！！！！

これなあマジでMSVC死ねボケ案件

これのせいでFloraRPCは1クラス書き直す羽目にあったからな

C++として使えるようになるのはいい話

（まあ特定のコンパイラがいつ対応するかは…見なかったことに…）

テストが落ちる 最上川

yukari-exvoice、前よりC++書けるようになったからC++で書き直すのもありだなあ

C++使ったほうがJNI APIを呼びやすい

CのJNI APIは呼び出し方が半端にオブジェクティブできもい

あとLocalRefの管理がクソだるいからRAIIなり解放関数付きスマポなりで何とかしたい

zgockさんや！

孤独の粗食（チームメンバーがリモートばかりで飯メンバーが集まらない）

This account is not set to public on notestock.

This account is not set to public on notestock.

わ、和〜

すし、いいやつだった

あああああー今日はやる気がねえーーかえりてえーーーー

ヤク中

末代じゃん、酒飲めよ

ボケ老人なので、数日前に買ってかばんに入れたきり食べてなかったお菓子をまた買いそうになった

暑いししけてるしカス

会社のmikutterアップデートしたらクラッシュした

気が狂ってきた

ほー対応したんか…

いつの間にこんなに属性増えたんだ

サガの連携技

ね゛む゛い゛

くそねみい、かえる

家についた

コード行数減らしたけど、これ嬉しいか……?

Kernel.require呼んでるだけなので、関数名がだいぶ嘘

俺案件じゃねえよアイマストドンいけ

mrb->exc、触らないほうがいいとtake-cheeze氏が言及しているのを見かけてマジかーとなった

Q. ではどうするか?
A. mrb_protect()がある

マジか

ほーー、そもそもmruby内に例外が発生したらlongjmpできるようにする仕組みが備わってるのか。

まごうことなき例外処理だが、なるほど

どおりで例外発生時の処理にmrb->jmpとかいう不穏なメンバを触ってるのがあったわけだ。

あ、これ手が込んでるwww
MRB_ENABLE_CXX_EXCEPTIONをdefineしてビルドするとC++の例外機構使うようになってる

mrb_protect()理解した

そしてスクショを貼ってるうちにXcodeが死んだ

どぼぢで…

NSExceptionにしてもいいかも、まあ組み込み先処理系に合わせてラップして使うのが吉ですね

とてもじゃないけどCでもなければ、このまま使うのはだっるい

関数ポインタとvoidポインタを受けるコールバック機構、可能性が無限だけど無限のだるさを感じる

まあCだと他に収まる所がない…か。

これもしかしてPromiseKitと組み合わせたら愉快なコードにできないか

headerとm間違えて生成したのをリネームしたらアイコンだけ両方mになったが

やっぱObjCキモいから書いてて楽しい

ObjC、もうこの先にこんなキモ言語は出てこねーだろうなという点で学ぶ価値がある。プロダクションで書きたくは……あまりないです

んなことしたら勘当でしょ

頻度高くない?

mrubyのコードは頑張ればまだ読める気がするけど、CRubyのコードは全然読める気がしないのですげーなーって思う

単純な関数実装ならさして変わらんのだけど…

あ、Doxygen形式でいいんだ、コメント。

むじるしタワーバトル

もしかしてmrubyはシンプルなので、CRubyのように蛮族がSymbol使いすぎてとうとうGCされるようになった世界線になっていないのでは……?

@toshi_a 古いブログ記事でそう書いてあったので今見てみたところ、シンボルテーブルに対するmrb_freeはmrb_close()の時しか実行されてなかった。GCないね。

ああでもパックして16bit程度に収まるsymbolならそもそもシンボルテーブルに登録しないのか

えっ何その処理は。