GMT特に理由もなく一年以上放置していましたが、特に理由もなく再開します。最近、仮想端末をiTerm2にしたので、xterm-256使えるぞと思って色々遊んでいました。(*OSX標準のターミナルもいつの間にかxterm-256対応していた)Unicodeには点字を表現するための文字群があり、2x3の点字64種類とそれを含む2x4の点字256種類で構成されています。これはUnicode中で自由に制御できる最も解像度の高い文字群ではないかと思い、xterm-256と合わせて利用してみることにしました。1まずは点字のみで、二値画像を表現してみます。新しい職場でPythonを使い始める時期だったのでPythonで、二値画像としては手頃なマンデルブロ集合を使います。ポイントはWikipediaにもありますが、2x3の点字が最初のほうに固まっているので、ビットを入れ替える必要があるところとマンデルブロの綴りくらいでしょうか。2Pythonにも慣れてきたので次はいよいよxterm-256を使いますが、いきなりカラーは難しそうなのでグレイスケールを使います。以下のシーケンスで前景色、背景色が指定できます。"};puts'そうしてできあがったのが以下のコードです。誤差拡散法なるべく前景色/背景色が同じにならないようにするガンマ調整(のようなもの)といった工夫によりかなり画質を向上させています。興味のある方はコードを弄って、どれくらい画質に影響を与えているか見てみると楽しいかもしれません。3カラー対応といいたい所ですが、3次元から1次元へ削減を行わないといけなかったり、人間の色覚モデルを考慮するのが面倒そうだったりしてまだやってないです。GMTこういうエントリはほとんど書かないんだけど、Photosynthはそのはじめのころからずっと見ていたし、首の消えてしまったおじさん(プライバシーに配慮して)の向うには出町ミスドがあるし、なによりPhotosynthが素晴らしかったので。iPhone持ってる人は一度は試してみるべき。共有しなければアカウント作成とか要らない。一部破綻が見られるけど、iPhoneで誰でも撮れるというのはかなりインパクト大きい。map今からでもGoogleMapsと張り合える。外部にライセンスするか、api公開していい会社買った方がいいものできそう。さんらとSDLをWebSocketと組み合わせて...という話をしていておもしろそうだったので実装してみた。WebSDLRuby/SDLの画面描画を全て文字列としてシリアライズし、WebSocketで送信、Canvasに描画する。ブラウザ上で発生したイベントをWebSocketで送信、SDLのイベントモデルの中に還元してやる。いうのが基本的な仕組み。webでWebSDL版が起動するようになっている。Canvasに対応したブラウザで開く。Canvasを使うだけでは芸が無いので、マルチユーザに対応、ユーザ間の情報共有にも対応してみた。0.1秒毎に更新しているのがかっこわるいが、適切なイベントに基づいた処理をすれば、パズルゲームやアドベンチャーゲームなど頻繁に画面更新のないものなら実用的なものができる可能性がある。ウェブへぇボタンとかね。現在の方法では実現が困難である。GMT初めて人の死に接したのは、ひいおばあちゃんのお葬式で、4〜5歳くらいだった。今でも覚えているが、別に悲しいことではなかった。誰だかわかっていなかったし、親戚の家で行われた式だったが、その家にはお気に入りのおもちゃ群があって、僕が騒がないように親戚のお兄さんが遊んでくれた。棺に花を詰め、霊柩車に載せて、火葬場まで行って、遺体が焼かれるのを見守った。死んだ、というのはわかっていたが、生きている姿を見たことがなかったからか、眠っているような遺体をみんなで囲む会が催された、というだけだった。それからしばらくして、バイオリンの練習をサボったかどで母親に怒られ、ふてくされて、布団にくるまりながら泣いている時に、初めて死を意識した。母親の言い放った、空からひいおばあちゃんが見てるぞ、というような意味の言葉について考えていた。くだらない脅しを言ったものだと思うけど、カーテンの隙間から曇った夜空を覗いてみて、今日は曇ってるから大丈夫だな、と思ったのを覚えている。その言葉から、死んだ後も意識が存続し続けるのだ、という概念を感じ取ったに違いない。埋められるというものだった。泣き止まなくて、この時ばかりは厳しくしすぎたと思ったのか、その晩だけは母親は優しかった、と思うのは美化された記憶かもしれない。今では、死はそういうものではない、とわかってはいるものの、あの時見た死のイメージは今でも残っていて、死に対しては悲しさよりも恐怖、時には憤りすら覚える。--with-opencv-include=/opt/local/include/opencvとやったらいけた。Gyazoモジュールを追加しました。デフォルト環境にはロードされないので、自分でロードする必要があります。pluginとして動く言語、purlを公開しました。クライアントサイドから柔軟な画像処理を行うために開発されました。サムネイルの生成などを行うプラグインはいくつかありますが、そのどれよりも強力で汎用性、拡張性があります。デフォルトの環境では、画像の保存にデータベースを利用します。imagesテーブルに、blob型のdataカラムを追加してください。以下のように記述します。実行されるようにします。書く場所は先頭に近い方がいいと思います。endendそんなこんなでセットアップは終わり。URL上で記述されることを前提としています。逆ポーランド記法を採用しています。データと命令を書かれた順番にスタックマシンにプッシュしていき、命令が実行された結果がスタックマシン上につまれていきます。命令列は最初に:で区切られ、数字としてパースできるものは数字へ、()で囲われた部分は文字列へと変換されます。ポリシーデフォルトで用意される全ての命令は、外部の値に依存しません。命令列が決まれば実行結果は確定します。このポリシーにより、全ての実行結果がキャッシュ可能になります。スタック上に既にある数字1を消費して、ID=1のImage#dataをデータベースからロードして、スタック上にプッシュします。スタック上の画像データをPNG形式のバイト列に変換し、mimetypeとともにスタック上に積みます。次の例では、画像をGIF形式に変換しています。/purl/1:load:to.gif画像のリサイズ次の例では、画像を100x100にリサイズしています。次の例ではふたつの画像を合成しています。/purl/1:load:9:load:composite:to.png次の例では順番を入れ替えています。/purl/1:load:9:load:swap:composite:to.pngコメントスタックに積んだ後すぐにpopすると、単純に無視されるので、コメントとして使えます。キャッシュのライフサイクルコントロールなどに使えると思います。詳しくは解説しませんが、試験的にcairoの描画機能をベースにした図形描画命令を用意しています。ctx命令で、指定したサイズのcairoコンテキストを準備し、xtc命令で実際にサーフェースへの描画を実行します。実行結果をファイルとしてキャッシュする場合、ファイルシステムによる字数制限を受けます。拡張は命令モジュールの追加という形で行います。Compositionもより普通の書き方をするように直してみたので公開。Dictionary.appを再起動。主な使い方は、宇宙(動いてる黒いの)を左クリックでリセット、AppleRemoteで停止、ステップ再生など。GMT:区切りの逆ポーランド記法言語、purlのランタイムを公開。http://purl.netswitch.jp/purl/1:load:3:shadow:medium:to.png上の画像のURLがそのままソースコードになっています。こちらから画像をアップロードすると、統合開発環境に飛びます。こんなかんじ→といったことが、URLだけで実現可能。2:load:dup:2:shadow:swap:composite:geom:1:load:100:100:4:pull:4:pull:crop:swap:composite:to.png:がリテラルの区切り、その他は数字と演算子。上のコードでは、2番の画像をロードして、ドロップシャドウしたものに1番の画像を背景として合成している。ソースコード中に改行は入れられない。