日報 2016-07-31

exported form https://nippo.wikihub.io/@_ksss_/20160731140352

mrubyでのforkのバグを直した。

https://github.com/iij/mruby-process/pull/7

引数に初期化されてない変数がブロック引数に渡されているので、 これをmruby側で参照すると死ぬ。

そもそもforkにブロック引数はいらない。

mrubyのC側でブロック引数を無くす方法は2つ

  • mrb_yield(mrb, block, mrb_nil_value())
  • mrb_yield_argv(mrb, block, 0, NULL)

mrb_yieldmrb_yield_argvはほぼ同じ関数だが、ブロック引数の取り方に違いがある。 mrb_yieldはブロック引数を1つだけ指定できる。 mrb_yield_argvは0〜いくらでも指定できる。 関数の中身もほぼ同じ

MRB_API mrb_value
mrb_yield_argv(mrb_state *mrb, mrb_value b, mrb_int argc, const mrb_value *argv)
{
  struct RProc *p = mrb_proc_ptr(b);

  return mrb_yield_with_class(mrb, b, argc, argv, p->env->stack[0], p->target_class);
}

MRB_API mrb_value
mrb_yield(mrb_state *mrb, mrb_value b, mrb_value arg)
{
  struct RProc *p = mrb_proc_ptr(b);

  return mrb_yield_with_class(mrb, b, 1, &arg, p->env->stack[0], p->target_class);
}

https://github.com/mruby/mruby/blob/eb7422af581edff0dd4b1f8259598677b4d32793/src/vm.c#L657-L671

要約すると、mrb_yieldではどんなにがんばっても引数を一つ与えていることになるので、意味的にはおかしい。 ブロック引数を0個にしたければ、mrb_yield_argv(mrb, block, 0, NULL)を使うほうがヨサゲ。

どうやってこのバグを発見したかというと、単にコンパイルしたらclangがwarningで教えてくれただけだ。

つまりコンパイルさえすれば発見できる状態にあるが、2年近く放置されていたことになる。(ブロック引数なんかつけなきゃ問題ないので)

そしてこんなミミッチイ事を気にするのは、世界で僕ぐらいだったようである。

おしまい。

日報 2016-07-22

exported from https://nippo.wikihub.io/@_ksss_/20160722124458

mruby本体に2つバグがあった。

一つめ

Struct.new(:a) do
  def foo
  end
end

とすると、fooメソッドはStruct.newで作られた新しいclassのメソッドになることを期待するが、 なんと、Structclassのメソッドになるというもの。ここでメソッドを定義してしまうと、全部のStruct classの小クラスで共有されちゃう。 しかもselfはちゃんとStruct classの小クラスになっていて気が付きにくく邪悪。

ほんとStructって誰も使ってないんじゃないの……。

これの修正は1行修正でよかった

https://github.com/mruby/mruby/pull/3179/files

二つめ

Struct.new(:foo) {
  def initialize(*)
    self.foo
  end
}.new

がSEGVするというもの。

ここでのinitializeは、新しく作られたStructからのインスタンスclassのinitializeで、 それを上書きしているわけだけども、上書きしないinitializeでself.fooと呼べる準備をしており、 その準備をしないままだと、ありえない参照(StructはArrayとほぼ同じだ)をしてしまって落ちるようだった。

一つめの修正前でもselfは新しいStructのインスタンスclassなので、1つめとは別の問題。

一つめの修正をした上で

https://github.com/mruby/mruby/pull/3178/files

の修正をするとなおるっちゃなおるんだけど、実装が汚い。

なぜ汚いかというと、C言語は関数のスコープを「ファイルで閉じるスコープ」か、「実装内部だけで共有できるスコープ」か、「別のアプリケーションから参照できる公開されたスコープ」を作れる。 mrubyには「実装内部だけで共有できるスコープ」の部分がない(CRubyにはある)ので、 これをわざわざ作るのか、それともpublicなAPIとするしか共有するすべがない。

この辺を考えるのがめんどくさかったので、別の「ファイルで閉じるスコープ」の関数をコピペしてきた。これが微妙だ。

まあCRubyでいうallocにそうとうするやつなので公開してもいいような……でもmrubyではallocメソッドを作ってないから公開しないほうがいいような……。

というわけで、判断はmatzにまかせることにした。 margeされなくても、セグフォなのでいずれ誰かが何とかするでしょう。

日報 2016-07-20

exported form https://nippo.wikihub.io/@_ksss_/20160720141728

おもしろそうなのでこっちに書いてみる。 riloっていうmrubyで動くミニマムエディターを作っている。

https://github.com/ksss/rilo

ワンバイナリ化

mruby-cliについて勘違いしてた。 mruby-cliはmrubyでcliツールを作りたい時に、雛形をいい感じに生成してくれるものっぽい。 mrubyのお作法をある程度省略できるのがメリットっぽい。 特にbuild周りに重点されていて、Dockerfileとかdocker-compose.ymlも用意してくれる。 当然雛形なので気に入らない部分とかは書き換えちゃえばいい。

あと、コード読むときに「ああ、あれね」という分かりをえることができるのも利点かなあ。

mruby-clirakeするとmruby v1.2.0を落としてきてbuildするようになっている。 もちろん手元のmrubyでbuildすることもできる。 依存するライブラリも手元のやつを指定すれば、もしライブラリがバグってた時に直せる。 mruby-cliは雛形生成ツールなので、これに依存しているからbuild_config.rbでなになにみたいなことはない。

もともとmruby-cli無しで四苦八苦して作っていたのが、だいたいこの雛形と一致したので僕にはあんまり意味がなかったっぽい。 (当然Dockerまわりは助かった)

参考リンクからはこの「雛形生成ツール」であることがいまいち伝わらず、 「なんでいるんだろう?なくてもcliツールできるくない?」と思ってた。

というわけでriloもmruby-cliに対応?したのでワンバイナリとしてbuild & 実行可能になった。

自分がよく使うツールを自作する感じは楽しい。

だいたいの仕様をkiloにあわせてるけど、 別に合わせる必要はないので、頃合いを見て参考にせず突っ走っていこう。

参考リンク

http://dojineko.hateblo.jp/entry/2016/02/22/002701 http://blog.kentarok.org/entry/2015/10/27/000522 http://hb.matsumoto-r.jp/entry/2015/10/23/133753

mrubyでテキストエディタ書いてる

大体動くようになってきたので公開。

github.com

きっかけは、まず最初にkiloがあった。

github.com

kiloはredis作者が作った、C言語で書かれた超ミニマムなテキストエディタだ。*1

「このコードを読めば、ベーシックなテキストエディタの実装方法が分かるはず」

と思って実装を読み、大体わかったので試しにRubyで書いてみるかとはじめてみたのが始まりだった。

そのうち「mrubyでも動くようにしてみるか〜」と思って、

必要そうなmruby-io-consoleを書いた。

というわけで、riloはkiloを参考にして、rubyでもmrubyでも動く(ように今のところなっている)超ミニマムなテキストエディタ。という感じだ。

今後の展望は

  • ワンバイナリで動くようにする
  • riloはriloで書く
  • 対応プラットフォームを増やす
  • カラースキーマプラグインで書けるようにする
  • viバインド・emacsバインドみたいなカスタマイズができるようにする(もちろんmrubyで書く)
  • 文字列検索・タグジャンプなどを実装する

といったところだろうか。

やる気さえ継続していれば……。

*1:多分antirez本人も遊びで作ったんだと思う

ニブンノイクジに感化されて保護者会に行ってきた

ニブンノイクジ

ニブンノイクジは「大東京トイボックス」や「スティーブズ」で有名なうめ先生の描くwebマンガで、 ママテナとcakesで連載されている。

ニブンノイクジ | mamatenna

ニブンノイクジ|うめ(小沢高広・妹尾朝子)|cakes(ケイクス)

毎週楽しく見させていただいているんだけども、七十話〜七十二話が異様に刺さる内容だった。

第七十話 はじめての保護者会 | ニブンノイクジ | mamatenna

第七十一話 アウェイ | ニブンノイクジ | mamatenna

第七十二話 アピール | ニブンノイクジ | mamatenna

なぜ刺さる内容だったのか

僕自身も1歳の子供がいて、この一年真剣に育児に取り組んできた。

仕事も週4で自宅勤務にできるように努力して、できるだけ子供の側にいれるようにしてきた。

たしかに『あなたはよく『お手伝い』できていますね』と言われたら、ムッとするだろう。

男性立入禁止のベビールームにも出くわしたことがある。

この「悪気があってやっているわけじゃないのは分かるんだけど、もうちょっとやりようがあるのでは」という気持ちが共感できたんだと思う。

いってきた

自分の子供も保育園に通っている。

そして、タイミングのいいことに自分にも保護者会なるものに行く機会があったので、実際に行ってきた。

マンガは7〜8年ほど前の特定の園での話なので一概には言えないが、この話が刺さった自分も実際に保護者会に行ってみるべきだと思い、妻に子供を預けて一人で休日の昼間に行ってきた。

保護者会、よい

結果的にはマンガのようなことは一切なく、非常に有意義な交流の場であった。

園での取り組みの紹介にはじまり、園からの連絡事項、園児に実際に提供されている食事の試食会では食材の硬さ・大きさ・味付けなどひじょうに得るものがあった。

また、保育士さんを交えての自由な意見交換・悩み相談などがあった。普段はすれ違うことしかできないおやごさん同士の話が聞けて、「わりと夜泣きで悩んでいる家庭は多いんだな」とか「名前の決め方も画数を気にする人もいれば音で決める人もいておもしろい」など非常に参考になった。

男性の参加者は5割りとは行かなかっもののちらほらとみられ、会話上でも一切の性別による不公平感が感じられなかった。

そんなわけで、保護者会は非常に有意義な場であり、何ら面倒でも不快でもない素晴らしい情報共有の場であることを確認できた。

フィードバック

保護者会で得た情報はすぐさま家庭内にフィードバックされた。

食事はこれまで小さくやわらかすぎたし、味も薄すかったので、 少し大きく、固めに、味もかつお節などで少しつけるようになった。

最近は食事のペースがかなり遅く、1時間ほどかかってしまっていたのだけど、これが見事に改善されてスルスル食べるようになった。

睡眠も、園では毎日2時間ほど昼寝しているのに、休日の家では全然昼寝しない状態だった。

そのことを保育士さんに相談したところ、「園では生活リズムをしっかりと付けて、音楽を流すなどしてお昼寝タイムのスイッチになるようにしています」との回答をもらったので、寝る際に音楽をかけてみることにした。

これまたいつもは23時ぐらいまでなかなか寝なかったのが、22時には寝付けるようになった。

保護者会、ほんとにいいことずくめだった。

ニブンノイクジ 保育園実績解除編 (コルク)

ニブンノイクジ 保育園実績解除編 (コルク)

わけがわからないことを雨のように体験する。それが東京Ruby会議11

regional.rubykaigi.org

東京Ruby会議11で「Rubyに型があると便利か」という発表をしてきました。

speakerdeck.com

何百人もの人に30分も時間をとってもらって話を聞いてもらうのは物凄く贅沢な時間だと思います。

トークを聞いていただいた皆様。声をかけていただいた皆様本当にありがとうございました。

発表内容についてはるびま記事としてまとめる予定ですのでお楽しみに。

みんなちがって、みんないい

今回の東京Ruby会議11は本当にそれぞれが非常に濃い内容だったと思う。

正直発表の7割ぐらいはよくわからなかった。

しかしそれでいいんだと思う。

東京Ruby会議11の目的にはこうある

技術的好奇心を改めて呼び起こし、プログラミングの難しさ、そして楽しさを再発見する場を目指します。

例えば火星がポンとあってもわけがわからない。

でも、「もっと知りたい」という好奇心がかきたてられるし、その好奇心で地球という殻を破って宇宙に出ることもできる。

今回の会議では色んな星が提示されていて、自分の見ていた世界がいかに狭いかを痛感させられた。

プログラミングの宇宙は無限に広くて興味がつきない感じが、やっぱりすごく楽しい。

僕も色んな世界を提供できるように殻を破っていけたらいいなあ。

www.youtube.com

議論はすべきでない

最近感じている、「議論はすべきでない」という自説について書いてみる。

この説を裏付ける、二つの話題が自分の中にあったからだ。

人を動かす

最近読んだ本「人を動かす / デール カーネギー」がきっかけだった。

人を動かす 新装版

人を動かす 新装版

70年も昔に出版された古典だが、今も売れ続ける世界的な名著で、「人を動かす」という普遍的なテーマを扱っている。 この本の「人を説得する十二原則」の項目の最初に紹介されるのは「議論を避ける」というものだった。

その項目を読むまでは、「議論は大切だ」「議論は積極的にしていけば、よりよい物ができあがるはずだ」と思っていただけに、僕としてはこの本での一番の衝撃的な内容だった。

内容を自分なりに要約すると、「誰かとあるテーマで議論をして相手を打ち負かし、自分を満足させて相手に恥をかかせるくらいなら、議論しないほうがよっぽど有効な関係を築ける」というものだ。

本書から引用すると

「議論に負けても、その人の意見は変わらない」

バイリンガルニュース #209

最近聴き始めたポッドキャストバイリンガルニュース」では、「コロラド大学ボルダー校の社会学の研究で、グループディスカッションをすると、意見が極端に分かれていき、さらに自分と反対の意見だけを極端だと信じこむ傾向にある事がわかりました。」というニュースがあった。

このニュースでは、相手の意見をまちがえて覚えていたり、自分の意見が極端になっていたことにも気が付かない。

議論が白熱していくと、元々の自分の意見も忘れてしまう。といった研究結果が紹介されている。

議論が成功したことはあるか?

自分の経験に当てはめると、たしかに経験したことがあるものだなと思った。

A案とB案、どちらがよいかで議論が始まると、どちらも同じかなぐらいの気持ちだったのにもかかわらず、些細な事からA案のよい所を見つけると、同時にB案をけなす意見も考えているのだ。「A案はこういうところがよい、B案にはそれがない。だからB案はよくない」というふうに。

それを聞いたややB案寄りだった人も反論してA案のよくないところを探そうとする「でもA案は**じゃない?」。 それを聞いたらますますA案が正しいことを証明するためB案のへの攻撃は強まる「B案だって**じゃないか。もし**だった場合どうする?」

こうやって「A案こそが正義・B案は悪」とする者と「B案こそが真実・A案は間違ってる」という極端な考えに両者が分かれていくパターン。ついには「B案を信じるアイツは悪」「A案を信じるアイツは愚か」となり、議論はただのケンカとなる。

本当の目的は、A案かB案かを決めることではなく、誰もが納得する最良の案を見つけることであるにもかかわらず。

このパターンがあまりに多いように感じる。

こうして両者は精神的に疲弊し、何らよいアイデアが浮かんでいない事実に愕然とする。 もしかしたらより優れたC案やD案もあったにも関わらず、A案派/B案派どちらかが強行作業を開始するか、中途半端で波風立てない作業だけが行われたりする。

これまで自分が行った議論のうち、果たしてどれだけがより生産的で良い結果になったか。果たしてどれだけがただのケンカになったか。

僕は確信する。議論は成功する確率より、失敗する確率のほうがはるかに高い。

正論は攻撃である

最も信頼の置ける人間である配偶者とですら、うまく議論できずにケンカになってしまうことは多い。

もちろん大人なので、明らかに人格を否定したり侮辱したりはしない。

ささいな議論が「いかに自分の意見が正しいか」を証明するためのバトルにシフトしていくのだ。それは本来全く必要のないであるにもかかわらず。

「自分は正しい」と言うことは「だからお前は間違っている」と言っていることになるのだ。

「ほら、私は正しいだろう?」という正論を吐けば、他者を攻撃していることになる。

なぜこうなるのか

「自分が傷つきたくないから」の一点に尽きると思う。

自分を守るために相手を攻撃する。その攻撃は相手の守りを強固にし、新たな武器を探させる。議論という名の戦争は、議論をした時点で始まっている。

「自分が間違ってるかもしれない」と考えられて、なおかつ「自分は間違っていた」と言える人は、そうでない人に比べて圧倒的に少ない。

自分で自分を否定することはとても苦しく、間違いを認める勇気が必要だからだ。

どうすればいいのか

こうして僕は、最近はできるだけ議論をしないようにしている。基本的には議論は避けるべきだと思う。「人を動かす」にもあるように「誤りを指摘しない」ようにしている。できてなかったらごめんなさい。

とはいえ、議論から産まれるメリットは当然あるだろう。明らかな間違い(バグ)は指摘しないと全員が不幸になることもある。

会議だ相談だで、議論は日常に存在する。

議論をしたくないからといって、独裁政治を許すことはできない。

どうしても議論しなければならなかったとき、次の教訓を思い出そう。

  • 議論はすべきでない。
  • 基本的に議論は失敗しやすい。
  • できるだけ間違いを指摘しない。
  • 議論に勝とうと思わない。どの意見に決まろうと受け入れること。
  • 相手を信頼する。
  • より良い案があると信じること。より良い案を探そうとすること。
  • 極端な考えに正解はないと知ろう。

また、一つ考えたアイデアとして、最初に極端な説をいくつかうちだし、そこから収束する方向に議論を進めていけば、中間のアイデアに収束しやすいのではないかと思う。

自分が自分の立場でなしうる最も正しい行いを、仏教用語では「中道」と言う。*1

wikipediaにはこうある。

中道とは(略)相互に対立し矛盾する2つの極端な概念・姿勢に偏らない実践(仏道修行)や認識のあり方をいう。

https://ja.wikipedia.org/wiki/%E4%B8%AD%E9%81%93

議論とは、

互いの信頼関係が十分構築されていて、

議論が失敗しやすいという共通認識をもち、

お互いにどちらかが勝とうとせず、

共通の前提知識があり、

両者が協力関係が望める成熟した人格を持っており、

かつ十分な時間があってはじめて成功する、

超高度なコミュニケーションなのだ。

おわりに

このブログも「いかに自説が正しいか」に極端によせて書かれているため、自己矛盾する。

あたりさわりないメッセージよりも、極端な説のほうが一石を投じれる可能性が高まる。

社会は、声が大きい者が有利になるようにできている。

よくないものに「よくない」と言うことで世界が良くなることもある。

これで議論は深まるだろうか。

こんなのはクソだとリプされるだろうか。

*1:仏教に詳しいわけではなく、光圀伝から引用