みかん箱

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

category:
DATE : 2025/01/18 (Sat)

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

category: 未分類
DATE : 2008/07/19 (Sat)

Pidginから Twitter を利用する際に便利な機能を提供する pidgin-twitter プラグインがyaz さんによって公開されています。このプラグインを、Windows でビルドしてみました。本記事では、ビルドの方法をメモしておきます。なお、対象とする pidgin-twitter プラグインのバージョンは 0.7、Pidgin のバージョンは 2.4.3 です。

なお、Windows 版のバイナリはnosuke さんが公開されています。

Pidgin のビルド環境を整える

pidgin-twitter プラグインのビルドには、Pidgin を Windows でビルドできる環境が必要です。

Pidgin をビルドする環境を整えるには、Windows/Pidginをビルドしてみる/ビルド手順/pidgin-2.4.3 や Pidgin for Windows Build Instructions が参考になります。特に、後者のページは、必要となるライブラリへのリンクがあるので重宝します。

まずは、上記のページを見て Pidgin をビルドする直前まで準備を進めます。

Pidgin 公式の GTK+ パッケージと、最新版の GTK+ パッケージを入手する

このまま Pidgin のビルドを行いたいところですが、pidgin-twitter プラグインが対象とする GLib のバージョンは 2.14.0 以上となっており、上記のページで使用する GTK+ 2.6.10 は GLib のバージョンが古いため使用できません。

そこで、Pidgin for Windows Build Instructions - Install Pidgin's build dependencies - GTK+ から入手できる GTK+ 2.6.10 パッケージに加えて、GTK+ Download for Windows から、GLib や GTK+ など、「Dev」と書かれたパッケージをすべて入手します（本記事執筆時点の GLib のバージョンは 2.16.3、GTK+ のバージョンは 2.12.9 でした。他のパッケージのバージョンは省略します）。「Dev」と書かれたパッケージがない場合は、「Binaries」と書かれたものを入手します。ここで入手したパッケージは、Windows/Pidginをビルドしてみる/ビルド手順/pidgin-2.4.3 にあるように、win32-dev 以下に gtk_2_0 として配置してください（すでに GTK+ 2.6.10 を配置している場合は、配置した GTK+ 2.6.10 を削除するか、名前を適当に変えてください）。GLib や GTK+ などに依存するライブラリを配置する際に、同名のファイルを上書きするかどうか問われることがありますが、とりあえずサイズの大きな方を残しておけば問題ありませんでした。

なお、GTK+ Download for Windows から入手できる zlib 1.2.3 には、zlib1.dll は付属しているものの、libz.a などは付属していません。Pidgin をビルドする際には libz.a が必要となるため、libz 関係のファイルは Pidgin for Windows Build Instructions - Install Pidgin's build dependencies - GTK+ から入手できる GTK+ 2.6.10 パッケージに付属するものを使用します。GTK+ 2.6.10 のパッケージを解凍すると、gtk_2_0 フォルダが出てきます。gtk_2_0\lib 以下の、ファイル名の先頭が libz ファイル全てを win32-dev\gtk_2_0\lib フォルダにコピーします。

GetText for Windows を入手する

Pidgin 公式の GTK+ パッケージ（GTK+ 2.6.10）と GTK+ Download for Windowsから入手した最新の GTK+ パッケージ（GTK+ 2.12.9）比較すると、前者には GNU GetText のコマンド類が含まれていますが、後者には含まれていません。

そこで、GnuWin32 プロジェクトが提供する GetText for Windows を入手します。「Complete package, except sources」を選び、GetText for Windows をインストールします。インストール先にあるフォルダ（bin、libなど）をすべて、win32-dev\gtk_2_0 にコピーします。

MinGW の gcc が使用されるかどうか確認する

Pidgin のビルドには、MinGW の gcc を使用します。以下のコマンドを実行して、gcc に MinGW のものが使用されるかどうか確認してください。（「$」はプロンプトです）

$ which gcc

MinGW をインストールしたパスが結果に含まれていれば、MinGW の gcc が使用されます。Cygwin の gcc が使用されている場合は、Cygwin の gcc をアンインストールしてください。

（；^ω^）Cygwin の gcc を使用すると、Pidgin のビルドの途中で「undefined reference to `__errno'」というエラーが発生してビルドが失敗してしまいます。

pidgin-2.4.3\pidgin\plugins\perl\common\Makefile.mingw を修正する

以上で Pidgin をビルドできる環境は整いましたが、pidgin-2.4.3/pidgin/plugins/perl/common/Makefile.mingw に間違いがあるため、ビルドは失敗します。pidgin-2.4.3\pidgin\plugins\perl\common\Makefile.mingw を開き、18行目から始まる「INCLUDE_PATHS」マクロに「-I$(GTK_TOP)/include/cairo」を追加します。以下に、追加後の「INCLUDE_PATHS」マクロを示します。

INCLUDE_PATHS =		-I. \
			-I$(PIDGIN_TREE_TOP) \
			-I$(PURPLE_TOP) \
			-I$(PURPLE_TOP)/win32 \
			-I$(PIDGIN_TOP) \
			-I$(PIDGIN_TOP)/win32 \
			-I$(GTK_TOP)/include \
			-I$(GTK_TOP)/include/atk-1.0 \
			-I$(GTK_TOP)/include/glib-2.0 \
			-I$(GTK_TOP)/include/gtk-2.0 \
			-I$(GTK_TOP)/include/pango-1.0 \
			-I$(GTK_TOP)/include/cairo \
			-I$(GTK_TOP)/lib/glib-2.0/include \
			-I$(GTK_TOP)/lib/gtk-2.0/include \
			-I$(PERL_LIB_TOP)/CORE

Pidgin をビルドする

以上で、Pidgin 2.4.3 を GTK+ 2.12.9 でビルドする環境が整いました。

正しくビルドできるかどうか、pidgin-2.4.3 にカレントディレクトリを移動して実際にビルドして確かめておきます。

$ make -f Makefile.mingw install

pidgin-twitter プラグインをビルドする

pidgin-twitter プラグインは、C で書かれています。C で書かれたプラグインのビルドには、Basic C Plugin How-To - Compile, Install, and Load the Hello, World! Plugin の文書が役に立ちます。

pidgin-2.4.3\pidgin\plugins\Makefile.mingw を修正する

C で書かれたプラグインを Windows 環境でビルドするには、pidgin-2.4.3\pidgin\plugins\Makefile.mingw という Makefile を使用します。ところが、pidgin-twitter プラグインをビルドするのに必要なライブラリ libxml2 が、この Makefile.mingw には設定されていません。

そこで、pidgin-2.4.3\pidgin\plugins\Makefile.mingw を開き、

21行目から始まる「INCLUDE_PATHS」マクロに「-I../../../win32-dev/libxml2-2.6.30/include」
36行目から始まる「LIB_PATHS」マクロに「-L../../../win32-dev/libxml2-2.6.30/lib」
43行目から始まる「LIBS」マクロに「-lxml2」

を追加します。

pidgin-twitter プラグインのビルド

まず、pidgin-twitter プラグインのパッケージの中から、pidgin-twitter.c, pidgin-twitter.h を pidgin-2.4.3\pidgin\plugins にコピーします。

カレントディレクトリを pidgin-2.4.3/pidgin/plugins に移して、プラグインのビルドを行います。

$ make -f Makefile.mingw pidgin-twitter.dll

これで、pidgin-2.4.3\pidgin\plugins に pdgin-twitter.dll ができているはずです。あとはこれを、マシンにインストールされている Pidgin のプラグインフォルダに入れればインストールは完了です。

更新履歴

2008/07/19 pidgin-twitter プラグイン 0.7 に合わせて修正。
2008/05/09 公開

category: 未分類
DATE : 2008/04/19 (Sat)

Maven Assembly Plugin の仕様が、2.2-beta1 と 2.2-beta-2 とで変わった

配布用 ZIP ファイルなどのパッケージを構築できる Maven Assembly Plugin を Maven 2.0.9をインストールした後に実行すると、Maven 2.0.8以前とは違ったパッケージができあがってしまいました。

例えば、次のような Assembly Descriptor があったとします。（「...」は省略を表します）

...
  <dependencySets>
  
    <dependencySet>
      <outputDirectory>/lib</outputDirectory>
      <outputFileNameMapping>${artifactId}.${extension}</outputFileNameMapping>
    </dependencySet>

  </dependencySets>
...

この Assembly Descriptor は、プロジェクトが依存するライブラリなどのプロジェクトを、lib ディレクトリに「（アーティファクト名）.（拡張子）」というファイル名で格納するという指定をしています。

ところが、この記述のある Assembly Descriptor を Maven 2.0.9 で実行すると、想定とは異なるファイルが lib ディレクトリに格納されていました。例えば、sample-project というアーティファクト名のプロジェクトがあり、commons-logging というプロジェクトに依存している場合、正しく動作すれば lib ディレクトリの直下に commons-logging.jar というファイルが格納されるはずです。ところが、なぜか sample-project.${extension} というファイルができていました。

Maven Assembly Plugin のページを確かめてみると、Mave Assembly Plugin のバージョンアップによって Assembly Descriptor の仕様が変わったようです。特に、上の例で該当する「outputFileNameMapping」要素の説明には、次のように書いてありました。

Sets the mapping pattern for all dependencies included in this assembly. Default is ${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}. (Since 2.2-beta-2; 2.2-beta-1 uses ${artifactId}-${version}${dashClassifier?}.${extension}) The default value is ${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}.

つまり、Maven Assembly Plugin 2.2-beta-1 と Maven Plugin 2.2-beta2 とでは、 outputFileNameMapping の書き方が異なるということです。

Maven 2.0.9 では Maven Assembly Plugin 2.2-beta-2 が採用されています（Maven 2.0.9 の Super POM）。そのため、自動的に Maven Assembly Plugin も 2.2-beta-2 にバージョンアップされます。そのため、Maven Assembly Plugin の動作変更に対して次のいずれかの方法で対処しなければなりません。

Assembly Descriptor を Maven Assembly Plugin 2.2-beta-2 の仕様にあわせて書き直す。
POM に Maven Assembly Plugin 2.2-beta-1 を使うようにバージョンを指定する。

（；^ω^）仕様が変わるなら、Maven のリリースノートに書いてほしかったですね。

category: Java
DATE : 2008/04/13 (Sun)

[Maven] プロパティの置き換えには、Maven Resources Plugin が使える

システム専用のディレクトリを使用するシステムを開発していると、ディレクトリの指定方法に迷うことがあります。例えば、Hibernate を用いて全文検索を行うことのできる Hibernate Search では、インデックスをディレクトリに格納するため、そのディレクトリをプロパティであらかじめ指定しておかなければなりません。

こういった環境に依存する設定があちこちの設定ファイルやプロパティに散らばっていると、管理が大変です。そこで、Maven Resources Plugin のフィルタリング機能が使えます。この機能の使い方は、次の通りです。

resources ディレクトリ以下のファイル中の置換したい文字列を${...}に置き換える。
プロジェクト設定ファイル（pom.xml）に置換するプロパティを指定する。
プロジェクトをビルドする。

resources ディレクトリ以下のファイル中の置換したい文字列を${...}に置き換える

例えば、resources ディレクトリ中のファイルに次のような設定があったとします。

<property name="hibernate.search.default.indexBase" value="c:/index" />

ここで、value 属性の値はディレクトリへのパスになっています。今回は、この部分をフィルタリング機能で置き換えます。置き換えのために、value 属性の値を${indexBase}に書き換えます。

<property name="hibernate.search.default.indexBase" value="${indexBase}" />

プロジェクト設定ファイル（pom.xml）に置換するプロパティを指定する

続いて、プロジェクト設定ファイル（pom.xml）の中に次の内容を追加します。（「...」は省略を表します）

<project>
...
  <properties>
    <indexBase>c:/index</indexBase>
  </properties>
...
</project>

つまり、project タグ直下に properties タグを書き、properties タグの直下に置き換え対象の文字列のタグを作ります。

プロジェクトをビルドする

以上で、フィルタリング機能を使う準備は終わりです。Maven Resources Plugin は、初期設定でビルドサイクルから自動的に呼び出されるため、プロジェクトをビルドするだけで、resources ディレクトリ以下の${...}で指定された文字列が自動的に置換されます。

参考文献

Maven Resources Plugin - Filtering 本記事は、この記事のまとめのようなものです。

category: R
DATE : 2008/04/05 (Sat)

関数の使い方は内側に書く

R の関数を書くときには、使い方などのコメントを関数の内側に書くと便利です。

R で関数オブジェクトを呼び出すと、その関数のソースコードが表示されます。例えば、次のような関数があったとします。

# 引数同士を足し合わせる。
#
# 引数：
#   a : 足される数
#   b : 足す数
# 戻り値：
#   a と b を足し合わせた数
add <- function(a, b) {
    # 計算結果を返す
    return(a + b)
}

この関数オブジェクトを次のように呼び出すと、次のように関数のソースコードが表示されます。（「>」はプロンプトです）

> add
function(a, b) {
    # 計算結果を返す
    return(a + b)
}

ここで、関数の使い方を記した関数外部のコメントは消えていますが、内部のコメントは残っていることに気づきます。

そこで、関数の使い方を関数内部に入れてしまいます。

add <- function(a, b) {
# 引数同士を足し合わせる。
#
# 引数：
#   a : 足される数
#   b : 足す数
# 戻り値：
#   a と b を足し合わせた数

    # 計算結果を返す
    return(a + b)
}

このようにすると、関数オブジェクトを呼び出したときに関数の使い方も分かって便利です。

> add
function(a, b) {
# 引数同士を足し合わせる。
#
# 引数：
#   a : 足される数
#   b : 足す数
# 戻り値：
#   a と b を足し合わせた数

    # 計算結果を返す
    return(a + b)
}

（；^ω^）これまでは、Java などの癖で関数定義の上に書いていました。ところがある日、関数内部のコメントが残っていることに気づき、R の関数のコメントは関数内部に書くようにしました。

category: 読書
DATE : 2008/03/29 (Sat)

UNIX 文化の本質の抽出

「The Art of UNIX Programming」（Eric S.Raymond 著、長尾高弘訳、アスキー、2007）を読みました。UNIX の設計やそれをとりまくコミュニティの伝統から、「UNIX では、なぜそうなっているのか」を解説する本です。

こういった、これまでにあるものを例として、その本質を抜き出して解説するという本は珍しかったので、面白かったです。特に、テキスト形式のデータの重要性を説いた部分では、実際に使われているデータファイルや、POP3 などの通信プロトコルを例として具体的に説明しています。さすがに、長年使われてきただけあって、説得力がありました。

また、マルチスレッドプログラミングに関しても面白い記述がありました。マルチスレッドプログラミングのやっかいな問題として、スレッド間で共有されているデータが挙げられます。書き換えられるタイミングを調整するのがとても難しいため、本書ではマルチプロセスへの分割を推奨しています。例えば、サーバとクライアントに分けられる場合は、サーバプロセスとクライアントプロセスに分割してプロセス間通信を行うことで、データの保護を行います（例として、PostgreSQL や X サーバなどが挙げられています）。

本書によると、そもそも UNIX の世界にはマルチスレッドの考え方がなかったようです。そのため、普段 Windows を使っている身としてはこの部分は非常に驚きました。確かに、マルチスレッドとは異なり、マルチプロセスの場合は、データへのアクセス方法がプロセス間通信に限られます。まさに、情報隠蔽の考え方だと思いました。

また、オープンソースに関わる方法についても触れられています。例えば、SourceForge などからダウンロードしたパッケージを展開すると、だいたい似通ったディレクトリ構成になっていることに気づきます。この構成は長年培われてきたもので、その意味やその理由について詳しく述べられています。また、パッチの送り方などにも触れられており、オープンソースに関わる際には貴重な指針となりそうです。

実際に使われているアプリケーションや言語などを基に解説されているため、例に用いられている中には、すでに古いものもあります。しかし、そこから抽出された本質はなかなか変わるものではありません。そのため、記述されているアプリケーションがこれから使われなくなったとしても、当分は役に立つ本と言えそうです。

<< 前のページ｜｜次のページ >>

忍者ブログ [PR]