2014-02-16

コード書くのが捗るBGM

雑記

たまには作業用BGMのご紹介でもしてみようかと思います。
作業用なので、基本的にインストです。

勢いでガツガツコード書きたいとき

Pacific Rim Soundtrack from Warner Bros. Pictures and Legendary Pictures

ラミン・ジャワディ
Soundtrack
¥1500

映画を観た人なら何も言わなくても判るはず。
全て粉砕してくれる！って思いながらコードを書けます。

from here to there

桑原あいトリオ・プロジェクト
Jazz
¥1800

The Sixth Sense

桑原あいトリオ・プロジェクト
Jazz
¥1800

BET UP / ai kuwabara trio project - YouTube
ピアノ＋ベース＋ドラムのシンプルな構成ながら勢いのある曲調と、コロコロと変化する表情が楽しめます。
長時間聴いてるとちょっと疲れるかもしれません。

Bridge

fox capture plan
Jazz
¥1200

後ろから追い立てられるような感じがたまりません。

思考をシェイクしたいとき

Trinity

fox capture plan
Jazz
¥1200

fox capture plan / 衝動の粒子 - YouTube
大小の水の粒がきらきら輝いているようなイメージ。
キラキラしたイメージでコードを書きたい時におすすめ。
コードがキラキラするかどうかは判りません。

SCENES

bohemianvoodoo
Jazz
¥1500

Color & Monochrome - EP

bohemianvoodoo & fox capture plan
Alternative
¥900

bohemianvoodoo／Adria Blue PV - YouTube
どこか郷愁を誘うような、それでいて異国情緒のある音楽。
気分がリフレッシュされ、いろいろと思考が進むかも？

少し気分が乗らないとき

Three Primary Sounds

Three Primary Colors
Jazz
¥1050

【Official Trailer】Three Primary Colors "just call my name" - YouTube
メロウでグルーヴィーで、優しい感じ。
もし汚いコードを見ても、許してあげれるようになるかもしれません。

Pool

toconoma
Jazz
¥1350

toconoma "Vermelho do sol" MV - YouTube
なんかちょっとノスタルジックな雰囲気。
馬鹿げたコードを見ても、人間そういうこともあるよねーって思える気がします。

その他（気分に合わせて）

MOVE ON

市原ひかりグループ
Jazz
¥1650

UNITY

市原ひかりグループ
Jazz
¥1650

Devilish Waltz of a Soul (The Tango of February 26th)

Tsumuzi
Jazz
¥1500

ReInterpret the passage

Daisuke Takeuchi Trio
Jazz
¥1200

Brooklyn Purple

纐纈歩美
Jazz
¥2000

YAMAMOTO REIKO TEMPUS FUGIT

アーティスト: 山本玲子TEMPUS FUGIT
出版社/メーカー: 寺島レコード
発売日: 2013/01/09
メディア: CD
この商品を含むブログを見る

Almah

Avishai Cohen
Jazz
¥1300

GHIBLI meets JAZZ ~Beautiful Songs~

Kazumi Tateishi Trio
Anime
¥1800

Disney Adventures in Jazz

作者: オムニバス
出版社/メーカー: Walt Disney
発売日: 2009/05/28
メディア: CD
この商品を含むブログ (3件) を見る

2013-12-29

mrubyにThread実装のための機能を追加したい - その後

mruby

ちょっと時間があいてしまいましたが、mrubyにThread実装のための機能を追加する件のその後のお話をしたいと思います。

あのあと、そんなにいろいろやったら別の処理系になっちゃうよ（意訳）という意見を頂いたので、
なるべくやること絞ってやろうということで、本当に必要なのは何？ってことで調査しつつ実装をしていました。

とりあえず結果だけを観たい人は、下記のgithubのURLに開発途中のbranchを公開しています。
このさきの何をどうしたという話をskipされる方はコードを読んでもらうのが早いかと思います。

crimsonwoods/mruby · GitHub
crimsonwoods/mruby-thread · GitHub

mrubyへの変更

さてそれでは、ここからはmrubyに加えた具体的な変更の話をしようと思います。

まず、今回の設計・実装のポリシーとしては、

なるべくmrubyのcoreに手を入れない
Thread/Lock APIはmrbgemで置き換え可能
multi-thread対応しなくて良い場合にover-headが極力発生しない

というものです。
で、このポリシーにそってどうしたらminimumな変更になるかを考えました。
その結果、大筋では下記のような機能を実装するということにしました。

LockのためのAPIの入り口だけmrubyのcoreで定義
ThreadのためのAPIの入り口だけmrubyのcoreで定義
resource shared RiteVMの実装
resource shared RiteVMの生成と破棄のAPIをmrubyのcoreで定義

ちなみに、このとき課題になったのは以下の点です。

Lock APIとしてmrbgemに何を要求するか？
Thread APIとしてmrbgemに何を要求するか？
mrbgemが一切取り込まれていない状態でもcompileが通ること

それぞれの課題について少し説明したいと思います。

Lock APIとしてmrbgemに要求すること

multi thread環境下でのlockやexclusive accessを提供する方法はいくつもあって、
例えばよく知られたものにはmutexやsemaphoreなどのlock APIがあります。
それ以外にもatomicやthrough putへの影響を押さえやすいread-write-lockなどがあります。
mrubyは組み込み機器も動作環境のターゲットとして含めていますし、何よりmulti-platformに対応しなければなりません。
そのため数あるlock architectureから、組み込み環境のようなcheapな環境であっても使えることが見込めて、かつmulti-platformで動作するようなものを選択しなければなりません。

とはいえ、実際にmulti-threadで動作をさせるためには、なんらかのthreading APIと最低限のlock API（恐らくmutex程度）の存在は期待できるため、それほど難しく考えないことにしました。
それに、最近は組み込み機器といってもLinuxが乗り、POSIXのAPIがそのまま使えることも多々ありますし、mrubyを載せるような規模の組み込みソフトウェアが何らかのOSの上で動くことを期待するのは、それほど無理な話ではありません。
ということで、今回は、API的にはread-write-lockの形をとり、mutexしか提供されていないような環境下ではmutexを使用してread-write-lockを実装してもらうか、lockのupgrade/downgradeを諦めてmutexとしても使えるように実装するという方針を採用しました。

Thread APIとしてmrbgemに要求すること

Threadとresource shared RiteVMのマッピングの管理のために、Thread APIとしていくつかの要件を満たすようにmrbgemに要求する必要がありました。
具体的には、以下の様なものです。

現在のThreadの識別子を取得できる機能の提供
Threadの識別子同士の同値比較機能の提供
Threadの停止を待機する機能の提供
内部実装用のThread管理領域を破棄する機能の提供

このうち、Threadの識別子の取得は大抵のThread Libraryは提供しているはずなので問題はありません。
次のThreadの識別子同士の同値比較は、当初単純に比較すれば良い程度に考えていたのですが、Mac OSでのpthreadのように単純な比較ができないケースもあるため、この要求を追加することにしました。
Threadの停止はmruby側で子スレッドの待ちとかを実装したくなった時のために用意しています。
Thread管理領域の破棄については当然必要なのであまり気にする必要はありません。

mrbgemが一切取り込まれていない状態でもcompileが通ること

これはmrubyのbuildプロセスの問題で、具体的にはmrbc（RubyのコードをC言語のコードに変換するプログラム）のcompileが可能な状態でなければいけないというものです。
これだけだとちょっとよく判らないと思うので、もう少しきちんと説明をします。
まず、mrubyのbuildにはmrbcが必要です。そして、このmrbcはmrubyのcore機能の一部を使ってcompileされます。
このときmrbcのcompile時にはmrbgemは一切取り込まれません。
つまり、Thread APIやLock APIはmrbgemとして提供されますが、その機能が静的にLinkされる構造を前提にしてしまうと、mrbcのcompile時にLink Errorが起きてしまうということになります。
このため、Thread APIやLock APIのための口はmrubyのcore側で静的に用意されているが、
実際のAPIへの呼び出しはmrbgemの実行時に動的にbindされるという仕組みが必要になるわけです。

まとめ

ということで、幾つか課題はあったものの、とりあえずそれらをクリアして動くサンプルを書いてみました。
Threadクラスの実装は、mattnさんのmruby-threadをベースに、今回追加したLock APIやThread APIの実装を追加しています。
とりあえずですが、mruby-thread/example/example.rbを実行すると、

in thread: x is foo
in thread: v is "foo"
in main: v is bar
in main: r is baz

のように表示されるのではないかと思います。
お試しあれ！

2013-11-10

mrubyにThread実装のための機能を追加したい

mruby

LeapMotionのライブラリをmruby用に書いたり、SDL2.0のライブラリをmruby用に書いたりしていて、
mrubyのRiteVMにもThreadをサポートするための実装が欲しいなーと常々思っていました。
で、ふとTwitterでmrubyにもThreadのサポートが欲しいよー的なことを発言したところ、
Matzさんからこんなお返事をいただきました。

@crimsonwoods 「最低限の機能」が定義可能なら協力しますよ。
— Yukihiro Matsumoto (@yukihiro_matz) 2013, 11月 9

ということで、mrubyでThreadを使うために何が必要かをいろいろと考えてみようと思います。

背景

mrubyでは「Threadをsupportしません」というスタンス（というよりはISOで定義されていないものはサポート対象外という方針だったよう）でした。
そうした方針が採用される中で、mrbgemが登場しmruby本体の外側に多様なライブラリの実装を追加することが可能になりました。
このmrbgemの登場により、mruby-threadのような、外付けの拡張機能がユーザーの手によって追加されるようになりました。

こうした外付けの機能の中には、既存ライブラリをmrubyへbindするものも多く、私自身が開発して公開しているもののいくつかも、そうした既存ライブラリをmrubyから利用するためのものでした（mruby-openalとかmruby-sdl2とか）。
既存ライブラリをmrubyから利用する上で大きな問題として存在するのが、マルチスレッドが前提となる機能の場合に、安全にかつ低リソースでmrubyを利用することが難しいということです。

たとえば、mruby-threadの実装を読むと判りますが、現在のmrubyでは生成されたsub-thread上でのコードの実行のために、RiteVMのインスタンスを再生成する必要があります。
このため、シンボルテーブルやヒープなどの、本来であればスレッド間で共有して欲しいリソースがスレッドごとに存在してしまいます。

目的

mruby上で動くRubyのコードでThreadが実装可能なように、
RiteVM側にThreadを実装する上で必要な機能を実装したいと思います。
Threadクラス自体の実装は含みません（Threadの実装はプラットフォーム依存なので）。

必要な機能

Threadの実装にどんな機能が必要か思いつく限りあげて行こうと思います。
基本的にcompile optionでThreadのサポートを完全に外せるようにできたら良いなと思っています。

Thread関連APIの整備

Threadの生成/破棄のAPIの定義
- スレッドサポートの有無のチェック: mrb_is_thread_supported
- スレッドの生成: mrb_thread_create
- スレッドの破棄: mrb_thread_join
定義したThread APIの実装はpluggableにしたい
- mrbgemでAPIの実装を追加する？
- mrb_open_allocfみたいに実装用APIを実行時に注入する？

こうすることで、Threadクラスの実装はmrubyのThread APIを呼び出すだけにできて、
かつplatform dependentなcodeをユーザーが自由に定義しやすくなります。
Threadクラスの拡張（priority設定したりとか）もmrbgemを作ってユーザーが自由に行えます。

Threadの生成

Thread用のcontextの生成（Thread用のmrb_stateの生成）
共有リソースのlock/unlock実装の指定（プラットフォーム依存なので、allocfのようにユーザが置き換えられるように実装する）
- lock resourceの生成用ユーザー指定関数型の定義
- lock resourceの破棄用ユーザー指定関数型の定義
- lock resourceのロック用ユーザー指定関数型の定義
- lock resourceのアンロック用ユーザー指定関数型の定義
- 共有リソース個別のロック/アンロックAPIの追加（mrb_lock_vm_heapとかそんな感じ）
- 可能ならread-write-lockのサポート

Threadの実行

VM heapへの安全なアクセス
symbol tableへの安全なアクセス
global variable tableへの安全なアクセス

Threadの破棄

Thread用contextの破棄
全ての子Threadの終了の待機

Threadと例外

例外のためのjump bufferのThreadごとの個別管理

ThreadとGC

参照がなくなったが実行状態なThreadオブジェクトの破棄の遅延
VM heapへの安全なアクセスとGC
- GC開始時に対象のスレッドの一時停止/再開
GC Threadの構築（これは必須ではないけど）

その他

arenaもThread個別に持っていた方が良いかな？冗長な気がするけど。少なくともthreadの数に比例してarenaの領域を拡大しないなら、thread個別管理が良い気がする。

パッと思いついたのはこのくらい。
他にもいろいろ抜けがありそうだけれど、最低限これだけの機能が実装できれば、
mrubyにThreadの実装を付け足すことができるようになるのではないかと思う。

2013-11-05

もやもやの正体

雑記

最近、ちょくちょくもやもやとしたものを感じることがある。
詳細は書かないけれど、もやもやした感覚を覚えることがある（どっちかといえばプライベートで）。
つい先日もそういうもやもやを感じたので、適当に書き残しておこうかなと思った。

思考を鈍らせるもの

ぼくらが「何か」をしようとしたとき、その「何か」を実現するまでには大なり小なり何らかのパワーが必要で、
それは例えば、肉体を駆動するための美味しいごはんだったり、健康を維持するための体力であったり、
「何か」に向かう渇望であったり、もっと単純な見栄や意地やプライドだったりするかもしれない。
そういう「パワーの源」を誰しも自分の内外に持っているはずだ。
この「パワーの源」自体には良いも悪いも無くて、それが人間を動かすエネルギーを供給してくれさえすれば良い。
だけれども、時々僕らはこの「パワーの源」によって生み出された結果に、「善悪」とか「妥当性」とか「合理性」とかそういうものを重ねて見てしまうことがある。
これも、そう「見てしまう」こと自体には良いも悪いもないのだけれど、ただ、「パワーの源」が何であるのかを観るための目を濁らせてしまうことがある。
濁った目で見た世界は、ぼくらの思考を鈍らせてゆく。
そうやってどんどん鈍った思考の中で、もやもやを募らせるのはつまらない。

ねがてぃぶなこころ

鈍った思考の中で、受け取った言葉を咀嚼していると、苦かったり酸っぱかったり、オエッマズッ！ってなることがある。
そう感じてしまう自分にも問題は当然あるのだけれど、なるべくならオエッマズッ！とはなりたくない。
どうすれば良いのだろうか、最近までもやもやしたものを感じていた。
このもやもやが、最近になってどうもネガティブな部分に反応してオエッマズッ！となる傾向があるらしいということに気がついた。
あぁこれは同類嫌悪なのかもしれない。
逃避のための理由を探して、だらだらと何もしないでいる自分を見ているような、そんな嫌悪感を感じるのかな。
本当のところは判らないけれど、きっとそういうことなんだと思う。
原因はなんとなく判った。よし、じゃぁどうしようか？
ネガティブな発言を封殺すれば良い？そんなことできっこないよ。そうだよね。
じゃぁ、我慢する？うん、今はそうしようか。もうちょっと年をとるまで、待とう。

今だって十分におっさんだけど、
今よりもっと良いおっさんになりたい。

2013-10-05

mruby-sdl2作ってます

mruby

前々からちょっとした理由でSDL2.0をmrubyから使いたいなーと思っていました。
で、今回ちょっと本格的に使いたくなってきたので、mruby-sdl2を作ることにしました。

SDL自体はすごく大きくて、周辺のいろんなライブラリも含めると、とてもじゃないけどそう簡単には作りきれません。
なので、まずは基本的な機能だけをうすーくラップしたクラスライブラリを作ります。
ということで、作ってみたソースはいつもどおりGitHubに公開しています。

https://github.com/crimsonwoods/mruby-sdl2

あまりちゃんとREADME書いてないのですが、サンプルコードはいくつかあげてあるので、
動かすだけならそんなに難しいこと無いんじゃないかなーと思っています。

サンプルコードは↓においてあります。

https://github.com/crimsonwoods/mruby-sdl2/tree/master/samples

一応OpenGLも動作するようになっていると思います。
OpenGLの使い方ですが、下記からmruby-glesを引っ張ってmrbgemに加えてください。

https://github.com/crimsonwoods/mruby-gles/tree/fix_for_compile_on_Ubuntu

基本的にはこんな感じです。

conf.gem :github => 'crimsonwoods/mruby-gles', :branch => 'fix_for_compile_on_Ubuntu'

あとはこれにOpenGL ESのライブラリのコンパイルやリンクに必要な設定をして、サンプルコードを動かしてみてください。

Audio用のサンプルでは、動作させるのに別途サンプル音源が必要になります。
音源については現状こちらでは用意していないので、動作を試される方はご自身で用意頂く必要があります。

それでは。

2013-08-05

mrubyからLeapMotionを使えるようにするmrbgemを作りました

mruby LeapMotion

つい先日LeapMotionが手元に届いたので、
思わず嬉しくてLeapMotionのSDKを見ながらmrubyからLeapMotionを使うためのmrbgemを作ってしまいました。
まだすべての機能が実装できたわけではありませんが、とりあえず認識している手の数とか、
指の本数とか、指先の座標っぽいものとかはとれるようになりました。

というわけでGithubでソースコードは公開しています。
まだ全然READMEにまともな情報を書けていません。ごめんね！
あとUbuntuでしか動作確認してないから、他の環境ではそもそもコンパイル通るかしら怪しいです。

https://github.com/crimsonwoods/mruby-leapmotion

基本的にはLeapSDKの各クラスがほぼそのままmruby側に出ています。
違うのは名前空間代わりに使っているmoduleの名前がLeapじゃなくてLeapMotionなことくらいかな。

Githubにも上げてあるけど、基本的にはこんな感じで使います。

class MyListener < LeapMotion::Listener
  def on_frame(controller)
    puts "frame: " + controller.frame.to_s
  end
end

controller = LeapMotion::Controller.new
listener = MyListener.new

controller.add_litener(listener)

# ここは適当に待ちを入れてね！
# 待っている間にMyListener.on_frameがばしばし呼ばれるよ！

controller.remove_listener(listener)

ということでLeapMotionとmrubyで遊んでみましょう！

2013-06-22

高専カンファレンス5周年記念パーティーに参加しました

高専高専カンファレンス

2013/06/15に開催された高専カンファレンス5周年記念パーティーに参加してきました。

高専カンファレンス5周年おめでとうございます！
運営にご尽力くださった@june29さんと@igaiga555さん本当に有難う御座いました。
そてお疲れ様でした。

私と高専カンファレンスの出会いは、2010/04/24に開催された高専カンファレンス in サレジオ（kosenconf-013salesio）でした。
この時から気づけば3年以上経っているんですね。
いやぁあっという間だなぁ。高専カンファレンスとの出会いはついこの間みたいな気がしますね。
せっかくなので、私にとっての高専カンファレンスを振り返ってみたいと思います。

高専カンファレンスと出会ってから3年、いろいろなことがありました。
私が参加したカンファレンスは、

割とちょくちょく参加していますねぇ。

2010年は母校である沼津高専での開催を目指して各地の開催に顔を出しては、
実行委員をやっていた人にお話を聴くなんてことをしていました。
そして2010年の年末には、念願だった母校での高専カンファレンス開催にこぎつけることができました。
高専カンファレンスの開催にあたって、多大なるご協力を頂いた沼津高専制御情報工学科の鈴木先生には
感謝してもしきれません。
私が学生の時からお世話になっていた教官の方で、高専カンファレンスのことをご相談させていただいた時も、
ご理解と多くのご助言を頂き大変感謝しております。ありがとうございました。
参加者として、各地よりアクセスの良くない沼津まで足を運んで頂いた方にも大変感謝しております。
沼津での開催が成功し、次につながったのは、ひとえに参加してくださった皆様と、
運営のために尽力した若いスタッフたちのおかげです。
改めて御礼申し上げます。

2011年は募金活動をやったり、仙台や長岡などの東北方面に遠征したりしていました。
やっぱりこの年は3.11のことを思い出さずにいられません。
遠く離れた東京にいた私でさえ、命の危険を感じるような地震を体感しました。
被災地の方々の恐怖は、私が感じたものよりもずっとずっと大きなものだったでしょう。
いろいろな苦しみや悲しみに負けずに、高専カンファレンスを開催した各地の実行委員の芯の強さには感服します。
また、多くの方に募金にご協力頂き、大変有り難うございました。

2012年は東京開催のスタッフに混ぜていただき、多くのことを学ばせて頂いた年でした。
あまり外部に向けた活動はしていなかったのですが、NSEGではmrubyネタでお話をさせて頂きました。
長野ではお酒を飲み過ぎて潰れたのが悔やまれます。

2013年には沼津高専での開催2回目となるカンファレンスが開催されました。
運営にはほとんどノータッチで、学生が自分で考え、自分で運営した会でした。
2010年に撒いた種が芽を吹き、顔を出し始めたことを感じました。
沼津の後輩たちのこれからの活躍に期待しています。

高専カンファレンスと出会ってから3年間、いろいろなことがありましたが、
その高専カンファレンスとの出会いで、今でも強く印象に残っていることがあります。
それは、1回めの「高専カンファレンス in サレジオ」の前夜でした。
最近はあまり見かけなくなった気がしますが、当時は前夜祭ラジオなるイベントが開催されており、
その場で当時運営側にいたid:june29に沼津での開催をしたい旨をお話した時でした。
彼は私に、それは素晴らしいことで、是非カンファレンスに参加して当日話をしたいと言ってくれたのでした。
それまでカンファレンスに参加したことすらない人間が、いとも簡単に受け入れられた、そんな瞬間でした。
今でも高専カンファレンスと、そこに参加する多くの人は、新しい参加者を受け入れる準備があります。
いつだって、どこだって、参加したいと少しでも思ったのなら、是非会場までお越しください。
開催してみたいと思ったのなら、是非開催してください。
もしご希望と荒れば、私を始め、いい年をした大人もお手伝いさせて頂きます。

こうして振り返ってみるといろいろと思い出すことはあるのだけれど、文字にするととてもとても多くて、
とりとめのない言葉ばかりになってしまいそうなので、このあたりで良しとしておこうと思います。
今後は若い人のサポートに尽力できたら良いななんて思っています。
まぁ実際どうするかはその場になってみないと判らないものではありますが。

出会ってからの3年間、たくさんの思い出と、刺激的な出会いに巡りあわせてくれた高専カンファレンス、ありがとう！
そしてこれからも宜しくお願いします。