Category: ソフトウェア

マルチプラットフォームで動作する、Rubyで書かれたTwitterクライアントmikutterのプラグイン、mikutter-perlを書きました。 動機: RubyからPerlを呼びたい 前々からNamazuのRuby実装を作りたい、ということを考えていました。現状のNamazuは独自のデータ形式を持っていますが、新しい実装ではバックエンドをGroongaにしたいと思っています。現状、Groongaのperl bindingはこれといった定番がないのに対し、RubyにはRroongaがあるので、作るならRubyだろうと考えています。 ただ、これまでPerlで書かれたフィルター群をどうにか継承できないか、とも考えていました。Namazuのフィルターはさまざまな形式のファイルからテキストを抽出するもので、今となっては結構な種類の数があります。 フィルター部分のみを呼び出すために、RubyからPerlのコードを呼び出したいという考えを実現する最初の一歩として、mikutter-perlを書いてみたというわけです。なお、Perl側には逆のことをするInline::Rubyというものがあります。 libperl呼び出し部分 最初に書いておきますが、やっていることは大したことありません。perlembedのサンプルとそう大きくは変わりません。 当初は直接libperl.soをDL::Importで読み込んで実行することを考えていたのですが、その手法には問題がありました。構造体へのアクセスができず、初期化に必要な作業が実行できません。以下にperlembedでも出てくるコード例を示します。 肝となるのはPL_exit_flagsです。perl_alloc, perl_constructで作成したperlインタプリタのインスタンス的なものに対し、終了時の挙動をフラグとして設定する箇所です。 gcc -Eオプションを使ってこの部分がどのような内容に展開されるかを確認すると、以下のようになります(on Debian wheezy)。 Perlinterpreterはstruct interpreterをtypedefしたもので、my_perlのIexit_flagsに値を代入するようなコードに展開されます。 デバッグ情報、シンボル情報などをstripした状態で、dlopen(2)だけでこれらにアクセスすることはできません。そもそもPerl周りはたくさんのマクロを使っているので、そこをクリアしたとしても汎用性が担保できません。 結局、そのあたりを全部担当するためのコードをCで書き、シンプルなインターフェースだけにまとめてDL::Import(dlopen)で呼び出せるようなコードを書きました(perlstub.c)。 RubyとPerlの間のやりとりも単純な文字列だけなので、割とシンプルに書きあがりました(mikutter-perl.c)。DL::Importはchar *を自動的にRubyの文字列に変換してくれるので楽です。 PL_exit_flagsさえ気にしなければ、DL::Importだけでコードを完結させることはできます。実際に書いたコードをgistにおいてあります。 mikutterプラグインの開発にあたって 今回初めてmikutterのプラグインを作成しました。参考にした資料は以下の通りです。 Writing mikutter plugin (http://toshia.github.io/writing-mikutter-plugin/) 基本的な書き方とイベントフィルタ、アクティビティの扱いについての情報 Event and Filters (http://toshia.github.io/writing-mikutter-plugin/event.html) 利用可能なイベントの一覧。今回は自分の実際のポストのみを対象とするためpostedイベントを監視 mikutter-shell-post (https://github.com/penguin2716/mikutter_shell_post) 似たようなことを実現している先行例として大いに参考になりました mikutter pluigin特有だと思われる、自分がはまった点についても列挙しておきます。 プラグイン内部で発生した例外は自力で受けないとスルーされる。ちょっとしたエラーがあっても止まらないのでわからない mypostイベントは、mikutter起動時に取得される過去の自身のツイートを受け取った時にも発生する。今まさにポストしたツイートに対応するイベントはpostedになる

ほぼ1日ぐらいはまっていたのでメモ代わりに記録しておきます。 Googleの各種サービスはWeb APIを持っているだけでなく、.NET, Ruby, Python, Java等の各種言語向けSDKを用意しています。これを使ってGoogle Spreadsheetsを操作しようとして、ちょっとはまりました。 Spreadsheet APIのリファレンスには、spreadsheetを操作する2種類の方法を提供しています。ListFeed型(行単位処理)とCellFeed型(セル単位処理)です。 CellFeedは割と簡単で、指定した矩形範囲のセルを逐次処理させるのに向いている手段です。ただし、こちらにも若干の罠があって、デフォルトでは値の入っているセルのみしか操作できません。APIリファレンスのサンプルの書き方もそのようになっています。値の入っていないセルも捜査対象にするためには、CellQueryのReturnEmptyプロパティにReturnEmptyCells.yesを代入しておく必要があります。 上記のコードは、5×3のセルすべてにアクセスするためのコード例です。ReturnEmptyを指定しないと、値の入っていないセルはとばして結果を返してきます。 本題のListFeedの罠についてですが、まずAPIガイドのサンプルの一部を見てみます。 このコードをまっさらなシートに対して実行をすると、API側がHTTPステータス400を返すので、GDataRequestExceptionが発生します。 何が問題なのかというと、ListEntry.CustomのプロパティであるLocalNameは「1行目のカラムの値」との対応付けがなされている前提のAPIだからです。上記の例だと、1行目に”firstname, lastname, age, height”という値が入ったセルが必要だということです。このことについて気付いたのは、値の入ったシートに対してListFeedで読み出しをしてみたら、1行分だけ少ない結果が返ってきたからです。CellFeedはそういう制約がないため、1行目を含めて内容の取得、変更等ができます。 あとになってガイドを読み返したら、以下のような説明がありました。 list row Row of cells in a worksheet, represented as a key-value pair, where each key is a column name, and each value is the cell value. The first row of a worksheet is always considered the… Continue reading GData.SpreadsheetsライブラリのListFeedに潜む罠

KAKASI 2.3.5をリリースしました。 実は2006年にリリースしようとしていたのですが、途中で頓挫してしまい実に10年超えのリリース周期となってしまいました。 結構前からCVS版がDebianには入っているのですが、libkakasiが壊れているという問題があるので、このタイミングでのリリースとなりました。あと、 NipponというRのKAKASIバインディングが出来たのが、新しいニュースです。 kanwadictの一新をやりたいところです。辞書は昔からほとんど変わっていないので…