mixメモ

PythonのC++インターフェイスboost.pythonの使用例

2009-10-17T16:34:00.000+09:00

少し前に、PythonのC/C++へのインターフェイス作成手段としてはctypesとboost.pythonが良さそうだという話を書いた。その後ctypesの使用例をメモった。

すでにCで開発されたライブラリがある場合にはctypesを使った方が楽だと思う。しかしC++や、あるいは自分でさらから書く場合にはC++を使いたいところ。場合によっては基本的にはC++で開発し、その後より楽に使用するためにPythonからも使えるようにしたい事もある。
そういう訳で、個人的にはPythonのC/C++インターフェイス開発にはboost.pythonが一番だと思う。Python自体に標準的に付随するものではない点だけが気になるところだが、とても簡単にC++のプログラムへのインターフェイスが作成できる。

というわけで、boost.pythonの使用例をメモ。

まず、C++で適当にクラスでも作る。ここでは簡単のためにsuffixarray.hhというヘッダファイルだけ。

// suffixarray.hh
#include <iostream>
#include <algorithm>
using namespace std;

class SuffixarrayCmp : binary_function<const int,const int,bool> {
protected:
    const wchar_t* _buff;
    
public:
    SuffixarrayCmp(const wchar_t* buff) : _buff(buff) {};
    bool operator()(const int x, const int y) const
    {
 return wcscmp(_buff+x, _buff+y) < 0;
    }
};

class SuffixArray {
protected:
    wchar_t* _buff;
    int      _size;
    int*     _idx;

public:
    SuffixArray() : _buff(NULL), _size(0), _idx(NULL)
    {};
    ~SuffixArray() {
 if (_idx != NULL) delete[] _idx;
    };

    bool construct(wchar_t* buff, const int size) {
 _buff = buff;
 _size = size;
 _idx = new int[_size];
 if (_idx == NULL)
     return false;

 for (int i=0; i<size; i++) {
     _idx[i] = i;
 }
 sort(_idx, _idx+size, SuffixarrayCmp(_buff));
 return true;
    };
    
    int getSize() const {
 return _size;
    };
};

このプログラムはC++として完全に独立していて、Pythonとは関係なくコンパイルもできるし利用もできる。wchar_t型(ワイド文字)の配列、要するに日本語文字列などを想定して、そのサフィックスアレイを作るもの。日本語は今はUTF-8を使う事が多いようだけど、メモリ節約にはなってもランダムアクセスには不便なのでwchar_tの配列とした。
また、私の使っているPython(2.5.4 on Debian GNU/Linux x86_64)ではunicode文字列はUTF-16で表現しwchar_t配列に格納しているようなのでそれに合わせたという意味もある。
そうでない場合に対応するにはテンプレートにでもしておけば良いのかな。そういう意味もあってヘッダファイルのみにした。

次に、これをPythonから使えるようにする必要がある。
construct()メソッドにはwchar_t*を渡す必要があるので、Pythonのunicodeからの橋渡しをする必要もある。
そのためのファイルがsuffixarray_py.cc。

// suffixarray_py.cc。
#include "suffixarray.hh"
#include <boost/python.hpp>
using namespace boost::python;

class PySuffixArray : public SuffixArray {
public:
    bool construct(PyObject* op) { // op must be a unicode object
 _buff = (wchar_t*)(PyUnicode_AS_DATA(op));
 _size = PyUnicode_GET_SIZE(op);
 return SuffixArray::construct(_buff, _size);
    };
};

int compare(PyObject* x, PyObject* y) { // x, y must be unicode objects
    wchar_t* xp = (wchar_t*)(PyUnicode_AS_DATA(x));
    wchar_t* yp = (wchar_t*)(PyUnicode_AS_DATA(y));

    return wcscmp(xp, yp);
};

BOOST_PYTHON_MODULE(suffixarray)
{
    class_<PySuffixArray>("SuffixArray")
 .def("construct", &PySuffixArray::construct)
 .add_property("size", &PySuffixArray::getSize)
 ;

    def("compare", compare);
};

PySuffixArrayクラスはSuffixArrayクラスのconstruct()メソッドをオーバーライドしているが、その中でPythonのユニコードからwchar_t*本体とサイズを取り出し、SuffixArrayのconstruct()に渡している。
unicode文字列の橋渡しもboost.pythonがやってくれるようになるとこんな面倒も必要ないのだろうけれど...
整数や普通の文字列の橋渡しはboost.pythonが面倒をみてくれるようだ。

BOOST_PYTHON_MODULEというところがPythonから見えるモジュールの定義。
大体見れば分かると思うが、suffixarrayモジュールの中にSuffixArrayというクラスを定義し、construct()メソッドをPython側からも見えるようにしている。
ここでsizeは「プロパティ」である。
実はadd_property()には三つめの引数を渡すこともできるが、その場合には

.add_property("pyname", &cplusclass::getter, &cplusclass::setter)

として、プロパティのgetter/setterを設定できるようになっている。setterを省略するとそのプロパティ(attribute)はread onlyとなる。
最後のcompare()は、クラスではなくC++の関数を取り込むためのもの。

これをコンパイルするわけだが、boost.pythonのチュートリアルだとbjamというビルドツールを使っている。実は以前、boost.pythonを触ろうとした時にそれが嫌で一瞬でやめてしまった事がある。
要するにmakeの代わりだが、最近はJavaだとAnt、boostだとbjamと、「進化」したビルドツールがよく使われるようになってきているようだ。
しかし、面倒くさい...
サブプロジェクトを含むようなプロジェクトのビルドだとか、そういうことのために色々進化しているらしいが、めんどい...
XMLみたいの書かされるのはとてもめんどいです...
あんなもの人間様が手で書くもんじゃないよね....ツール使う？それもめんどい...

ということで時代に取り残されている気もしないでもないけれど、馴染のmakeにした。
Makefileは個人的にあれこれしているので、ここでは実際のコンパイルコマンドがどうなっているかだけ。オプションもboost.pythonのコンパイルに必要なものだけ。

$ g++ -c -o suffixarray_py.o -I/usr/include/python2.5 -fpic suffixarray_py.cc
$ g++ -shared -o suffixarray.so suffixarray_py.o -lboost_python

これでsuffixarray.soというシェアードオブジェクトができる。

これをPythonから使うのはこんな感じ。

>>> import suffixarray as S
>>> s = unicode('これはぺんですがあれはぺんしるです。', 'utf-8') ## 文字コードは環境依存
>>> sa = S.SuffixArray()
>>> sa.construct(s)
True
>>> sa.size
18
>>> sa.size = 10
Traceback (most recent call last):
File "", line 1, in 
AttributeError: can't set attribute
>>>

もしPythonからの使い勝手が悪ければ、ラッパークラスを作ってもいい。面倒なのでboost.pythonのレベルで解決した方が良さそうだけど。

なお、Pythonのunicodeオブジェクトはimmutableだが、こうしてC++に渡してあげると自由に変更できる。

Bloggerにコード片を載せる時に利用できるもの・・・？

2009-10-17T16:22:00.001+09:00

ちょこちょことコード片を載せてきたけれど、なんだかpreタグだとかじゃうまくいかなかったりでとても嫌。
プリティファイしてくれないまでも記号類やインデントも込みでそのまま表示してくれる程度の機能は備わっているものなのだろうと思ったんだけど、GoobleのやってるBloggerにもそういう機能はないんだな・・・。他でブログ書いたこともないので他所にもあるのかどうか知らないけれど、まあ、コード片載せるなんて一般人からみたら極一部の少数派なんだろうから、きっとないんだろう(それともあるのかな？)。
が、こんな記事を見付けた。

ハイライトもGoogle流 - "google-code-prettify"でソースコードに色付けを

というわけで、この記事を参考にやってみる。ことにした。が、なんだか記事読んでもわかんない。
自前のウェブページじゃなくてBloggerでそれやりたいんだけど・・・

で、ぐぐってみるとそのやり方を説明してくれているサイトがあった。
しかもさっきのツールを一発でBloggerに追加してくれるリンクまである。ありがたい。
が、追加してみてもなんだか効いてないような・・・
ということで、そのページには前から困ってた<と>を変換してくれるツールもあったので、それだけ利用させてもらうことにした。

EmacsのWanderlustからGmailの読み書き(.foldersの設定)

2009-10-12T14:01:00.003+09:00

メインのノートPCを常に持ち歩いていた頃には、メールは全てノートに取り込み、Emacsの中のGnusやWanderlustで読み書きしていた。
しかし今では主にGmailを使っている。
どこからでもケータイからでもアクセスできてとても便利だし、大きな不満はないのだが、一つ嫌なことが・・・
このブログの文章を書くのも同じだが、文章をブラウザで書くのがイヤ・・・
とても書き難い。文章のチェックすらする気にならない。

なので時々はEmacsで文章を書いてから貼り付けたりすることもある。

それで、いっそのことEmacsからGmailを読み書きできるようにしておくことにした。
ググると結構そんな話があり、メイラはMewかWanderlustと言ったところのようだ。
となれば以前使っていたWanderlustだという事で、ヒットしたブログなどを参考に久し振りにWanderlustの設定をした。

.emacsや.wlの基本設定などはヒットした内外のページを参考にすれば何の問題もなかった。

しかし.foldersが良く分からなかった。
特に、皆「受信トレイ」位しか見ていないような記述ばかりで、Gmailのラベルはどうすればいいのか・・・と。
なので一応メモっておく。こんな感じ。


%Inbox "受信トレイ"
%Gmailのラベル1 "ラベル1"
%Gmail label2 "ラベル2"
カテゴリ1 {
 %Gmailのラベル3 "ラベル3"
 %Gmail label 4 "ラベル4"
}
%[Gmail]/スター付き "スター付き"
%[Gmail]/下書き  "下書き"
%[Gmail]/すべてのメール "すべてのメール"
%[Gmail]/送信済みメール "送信済みメール"
%[Gmail]/迷惑メール "迷惑メール"
%[Gmail]/ゴミ箱  "ゴミ箱"

「%Inbox "受信トレイ"」は、Gmailの「受信トレイ」をWanderlust上でも「受信トレイ」と表示するためのもの。
「%[Gmail]/スター付き "スター付き"」は、Gmailの「スター付き」をWanderlustでも「スター付き」と表示するためのもの。
「%Gmailのラベル1 "ラベル1"」は、Gmailの「Gmailのラベル1」という名前のラベルをWanderlust上では「ラベル1」と表示するためのもの。
「%Gmail label2 "ラベル2"」は、Gmailの「Gmail label2」という名前のラベルをWanderlust上では「ラベル2」と表示するためのもの。
カテゴリ1というのは、Wanderlustでフォルダをグループ化して名前を付け、入れ子表示するためのもの。

また、「[Gmail]/xxxx」というのは、自分で作ったラベルではなく、Gmailのシステム側が用意してあるxxxxというラベルという意味だ。Inboxだけは例外。Gmailの「設定-ラベル」画面で確認できる。

うっかりGmailに無いラベル名を指定するとwlで接続に行った時にGmail側にそういう名前のラベルを作ろうとするので注意。間違って作ってしまった場合にはGmail側で削除する。

もう一つ、Gmailのラベル名に":"(コロン)を使っていると問題が発生するので注意。
aa:bbbなんて名前にすると、.foldersに「%aa:bbb」と記述する事になるが、bbb上のユーザーaaと認識するようで、aaのためのパスワードを要求されたりする。

最後に、念のためメモ。
日本語ラベルを使っているが、.foldersの記述もEmacs(23)のデフォルトエンコーディングも全てUTF-8にしてある。Emacsの事なので、それにWanderlustの開発者は日本人だった気がするので、その辺りはうまくやってくれていそうだが一応注意。

キーバインドなど細かいカスタマイズをしないとまだ快適とは言えないが、とりあえずWanderlustで読み書きできるようになった。サマリーで"$"キーでマークするとそれがGmailのスターと同期もしてくれるし、ひとまずOK。細かいことは普通にGmailでやればいいし。

古いシステムにOpenSSH5.1を入れる

2009-10-12T13:40:00.002+09:00

sshで多段ログインする話を書いてきたので、ちょっと脇道になるがその中で必要だったこともメモ。

homepc - (mansion LAN - the internet) - gw1 - gw2 - workpc

という環境下で、gw1, gw2, workpcにそれぞれsshでログインできる状態だった。
しかしgw2のsshクライアントのバージョンが古く、そのため-Yオプションが無いためtursted なXの転送ができずにXアプリが使えない状況だった。

そのためgw2にOpenSSH 5.1をインストールした。
もちろん自分のホームディレクトリ以下にインストール。
幸いgccは使えたので助かった。

OpenSSHのコンパイルに新しめのzlibとopensslも必要だったので、それらもインストール。
いずれもソースは手元のDebianマシンで

$ apt-get source zlib

のようにしてゲット。それらをgw2に持っていき、

$ ./configure --prefix=/HOMEDIR/local
$ make
$ make install

などとした。
順番はzlib, openssl, openssh。
OpenSSHのconfigureの時には

$ ./configure --prefix=/HOMEDIR/local --with-zlib=/HOMEDIR/local

とした。OpenSSLやzlibでも何かオプションが必要だった気がするけど、忘れた・・・試してエラーが出てくれば分かるはずだからいいか・・・

最後にPATHに/HOMEDIR/local/binを追加して完了。
というか、gw2、そろそろなんとかした方が・・・

sshでリモートからemacsclient

2009-10-12T10:10:00.004+09:00

という訳で、sshで自宅から職場の強力マシンに入れるようになったし、rsyncで同期もできるし、Xアプリも使えるようになった。自宅にいるも職場にいるもあまり意識せずにほぼ同じ感覚で作業できるようになったわけだ。

しかしもう一つ。

作業の多くをEmacsの中で行なっているので、当然Emacsは常に立ち上げっぱなし。終了して起動し直す事なんて特に理由がない限りはない。当然職場PC上でもEmacsは常時起動しっぱなしだ。
で、自宅から職場PCに入って一番最初に起動するのもEmacsなわけだが、職場でやっていた作業の続きができない。diredでディレクトリを開いていたりファイルを開いていたり、shell-modeの中で何かやっていたり、Pythonその他を動かしている事もある。場合によっては時間のかかる処理を流しっぱなしにしている事もある。
その様子を見たり続きをしたいこともあるが、それにはまさにその、職場PCで動いているEmacsに入らないといけない。sshログインして別のEmacsプロセスを起動しても無理だ。

そこで思い出したのがemacsclinet。(以前はgnuclientという名前だったような気が...)

職場PCで使っているEmacsで M-x server-start とすると、Emacs serverが起動する。
そして自宅からsshで職場PCにログインしたら

workpc$ emacsclient -d localhost:10.0 test.txt

のようにすると、手元(homepc)でEmacsのウィンドウ(フレーム)が開いてtest.txtファイルのバッファが開く。そしてそれは職場PCで動いているEmacsと同じプロセスであり、当然他のバッファも見られるしその中で作業もできる。本当に中途半端な状態で職場を出て、その続きを自宅でしたり、あるいはその逆もできる訳だ。

なお、-dで指定しているのはXのディスプレイだが、サーバーEmacsと同じディスプレイの場合には既に開いているEmacsの中でtest.txtバッファが開く。今回のように別のディスプレイを指定すると、新たなフレームが開く。

指定したファイル(test.txt)のバッファをkill-bufferすると、emacsclient自身は終了する。しかしフレームは残るのでその中で作業を続けることは普通にできる。
が、先にフレームを閉じてしまいtest.txtのバッファをkill-bufferし忘れると、なぜかemacsclient自体は終了しない。起動時にファイル名を求めるというのはそういう意味だったのか...
まあプロセスを殺せばいいんだけど、ちょっとしっくりしない。

ちなみに、localhost:10.0 というのは、sshで入った時のこちら側に割り当てられたDISPLAYだ。試している限りでは、一段sshと二段sshでは自動で環境変数DISPLAYが正しく設定されているが、三段sshでは自動では":0.0"と正しい値が設定されていない。なので自分で

workpc$ export DISPLAY=localhost:10.0

のようにしないとXのウィンドウを手元に持ってこられないので注意。
また、"10.0"の"10"の部分はログイン状況によって異なるようだ。
一段・二段sshの時の値から推測すると、10あたりから順番に大きな数を使うようになっているようだが、この辺りの正式な説明は見付けられなかった。

なにはともあれ自宅から職場PCで起動しているEmacsに横入りして作業できるようになった。
普通のターミナル上でならばscreenでも使うところなのだろうが、Emacsメインの人間にとってはemacsclientの方が100万倍便利。

ただしEmacsでサーバーを起動しておかないといけないので、うっかり忘れないように.emacsに下のコード片を加えて自動で起動するようにしておいた。


(when (equal (getenv "DISPLAY") ":0.0")
  (server-start))

sshの圧縮オプション

2009-10-12T09:36:00.002+09:00

いちおう追加メモ。

前回sshで二台越しのログインをし、Xのウィンドウも表示できるようになった。Emacsなどはほとんどリモートと意識しないで使える。
しかし、例えばgimpなどのお絵描き系の場合、やはりマウスの動きに2テンポ位遅れる感じだ。まあ仕方ないだろう。

次に試しにリモートのLinux上のVMware(の中のVista)を使ってみた。
結果から言えば、あまりガシガシ使う気にはならないが、Wordで簡単な文書を書いたりPowerPointで質素なスライドを作る位なら十分使える。オートシェイプを入れたり動かしたりするのはやはりとても苦しいが。またウィンドウズの装飾的な表示効果はなるべく切っておいた方が良さそうだ。
とりあえず万一自宅や職場のウィンドウズ環境がおかしくなった場合の最後の逃げ場にはなりそうだ。

ただしこれはsshに"-C"オプションを付けて圧縮した上で転送するようにした場合のこと。
-Cオプション無しではとてもとても遅くて耐えられなかった・・・

多段sshとrsyncでデータの同期

2009-10-10T23:03:00.003+09:00

boost.pythonの利用例をメモっておこうと思ったけれど、最近分かったsshのポートフォワーディングの使い方を先にメモしておく。
そういう機能があるのは知っていたものの、せいぜいsecureなrlogin程度の使い方しかしていなかった。しかし最近やはり使ってみたくなった。

元々自宅と職場を行き来する中で、自宅マシンと職場マシンでのデータの共有という問題があったのだが、これまではノートPCを持ち歩き、基本的にそれを媒介とすることで目的を果たしていた。
自宅や職場でそのノートとrsyncで同期をとるという方式だ。
しかし、次第にノートを持ち歩くのが億劫になってきた。
持ち歩き用のノートはB5の小さなものだから、それはメインの作業場ではなく、自宅や職場ではより速く大きなディスプレイのマシンがメインの作業場になっている。そうなると持ち歩き用ノートはもはやデータを運ぶためのものでしかない。
かつては自宅でも職場でも出先でも同じノートをメインにしてた事があり、その頃にはメールでもデータでもノートが母艦で、時々他のディスクやマシンにバックアップを取っていた。しかし、今ではメールも基本的にはweb上に置いてあり、ケータイからも読み書きできる。もうメールやWebチェックのためにPCを持ち歩く時代ではなくなっている。
出張その他どこかへ出掛けるのでない限り、もはやノートPCはデータ同期の媒介としてしか持ち運んでいなかった。
また、その目的ならば、もはやポータブルHDDや、大容量化してきたUSBメモリで充分だ。

ポータブルHDDやUSBメモリでも、やはり一々それらに同期してから持っていき、またそれから同期するのが面倒になってきた。
そこで、自宅と職場のPCの間で直接同期(rsync)したくなった。

自宅マシンから職場マシンへの三段sshでのログイン

ここで問題になるのが、自宅PCから職場PCへのアクセスだ。
もちろん、直接入れるようにはなっていない。
その間に二台のゲートウェイが挟まっている。それらをgw1, gw2とすると

homepc -(the internet) - gw1 - gw2 - workpc

という形だ。homepcは自宅のマンションLANの中でプライベートIPを振られているので外から直接アクセスすることができない。

この状況で、幸い(というか厄介事の種になっている訳だが...)gw1, gw2にもsshでログインする権利が与えられている。
ただし、インターネット側から直接はgw1にしか入れない。gw2に入るにはgw1に入ってそこからまたsshしないといけない。また、gw1からはgw2にしかsshできない。
gw2からはworkpcにsshで入れる。

workpcからは、gw1にもgw2にもsshで直接入る事ができる。ただしその他のポートには入れない。

こういう状況では、
homepc$ ssh gw1
でまずgw1に入り、次いでそこから
gw1$ ssh gw2
でgwに入り、さらにそこから
gw2$ ssh workpc
とすることで、自宅からworkpcに入ることができる。

しかしめんどい。
要するに三段越しのsshをしたいわけだが、少し調べると、こうすることで簡単に実現できることが分かった。

homepc$ ssh -t -Y gw1 ssh -t -Y gw2 ssh -Y workpc

ただし、gw1, gw2, workpcのパスワードはその順番で聞かれる。
(このあたりは設定で入力無しやパスフレーズを使うように変更できるようだが、今のところ面倒なのでノータッチ)

"-t"オプションは擬似端末を強制割り当てするものらしい。正直よく分からないが、これがないと文句を言われてしまう。
"-Y"オプションはtrusted X11 forwardingを有効にするもので、これを付けるとworkpcで実行しているXクライアントをローカルマシンに表示することができる。
ネット越しなのでいくらか遅いが、職場マシンのXクライアントを自宅でそのまま使えるのでとても重宝する。なお、-Yオプションは古いssh(私が使っているのはOpenSSH)ではサポートされていない。(untrustedな-Xオプションはあるようだ)

自宅マシンと職場マシンのrsync(三段ポートフォワーディング)

さて、これで自宅マシンから職場マシンに、間に二台のマシンを狭んでの三段sshで入れるようになった。
しかし目的は自宅マシン(homepc)と職場マシン(workpc)の間でのrsyncによる同期だ。

これにはポートフォワーディング機能を使う。
ネット上でも色々漁ってみたが、三段越しのrsyncというのはあまり見付からず、一段越しの例を参考にしてもなかなかうまくいかなかった。
正直sshの仕組みやオプションがよくわかっていなかった。今もそうだが。

結局、残念ながらコマンド一つではまだ実現できていないが、とりあえず次のようにすることでなんとか実現できた。

まず、三段sshと同じ要領で、ポートフォワーディングを三段繋ぐ。

homepc$ ssh -t -L 10022:localhost:10001 gw1 ssh -t -L 10001:localhost:10002 gw2 ssh -t -L 10002:localhost:22 workpc

これでworkpcにsshログインし、同時にhomepcのポート10022がworkpcのポート22(ssh)に、間の二台、gw1とgw2に中継されながらフォワードされる。
つまり、この状態でhomepcのポート10022に接続すると、それはworkpcのポート22に接続することになる。

この状態でhomepcとworkpcの間でrsyncを行なうには、次のようにする。

homepc$ rsync -avuSHx -e 'ssh -p 10022' /homepc/source/ localhost:/workpc/dest/

これで、homepcの/homepc/source/ディレクトリ以下がworkpcの/workpc/dest/にコピー(同期)される。実際にはいつも--deleteオプションも付けてソースにないファイルはデスティネーションからも削除している。
また、実際に行なう前に必ず--dry-runオプションを付けて削除される予定のファイルをチェックしている。
もちろん、引数の順番を逆にすればworkpcからhomepcにコピーすることもできる。

これで何も持ち歩かなくてもデータの同期を取ることができるようになった。しかもこれまでも、きっとできるだろうと思いながらやっていなかった、自宅で職場PCのXクライアントのウインドウを表示して使うことも可能になった。

というわけで、一応三段ポートフォワーディングの説明をしておくと、上記のフォワーディングでは、まず

ssh -t -L 1022:localhost:10001 gw1

の部分で、gw1にsshでログインし、homepcのポート1022がgw1の10001にフォワードされる。
localhost:10001とは、gw1から見たlocalhostという名前(or IP addr)のマシンのポート10001という意味で、localhostとした場合にはもちろんgw1自身だ。
そして、この後に続く

ssh -t -L 10001:localhost:10002 gw2

の部分でgw2にログインし、このコマンドが実行されるgw1のポート10001がgw2から見たlocalhostのポート10002にフォワードされる。
ここまでで、homepcの10022はgw2の10002にフォワードされたことになる。
そして最後に

ssh -t -L 10002:localhost:22 workpc

だが、これはgw2で実行される。そしてgw2のポート10002をworkpcから見たlocalhost、すなわちworkpc自身のポート22(ssh)にフォワードする。
これで、homepcのポート10022へのアクセスはworkpcのポート22へのアクセスを意味する事になった。
rsyncのオプションの

-e 'ssh -p 10022'

の部分は、rsyncでsshを用いそのsshでは10022ポートを用いよという意味だ。
結局rsyncへのパラメータである

localhost:/workpc/dest/

では、localhostの10022ポートを使うことになり、これはworkpcへのssh接続ということになる。

という訳だが、以上はあれこれ試行錯誤した結果の自分なりの解釈なので、間違いがあるかもしれない。一応自分なりに一貫した解釈ができるようになったので良しとする。

職場マシンからマンションLAN内の自宅PC(プライベートIP)へのsshログイン

さてさて、ここまでで一段落、どうにか目的は達成されたが、なんとなくポートフォワーディングの使い方が分かってくるともう少し欲が出てきた。
職場から自宅PCにアクセスしたい。

自宅はマンション内LANでプライベートアドレスを割り当てられているので、簡単にはそれはできない。ゲートウェイにログインできるわけでもない。
しかし、多分やってみればなんとかなるんだろうなとは思っていた。

で、上記のようにsshで自宅からgw1やgw2にリンクを張れるなら、それを職場PCから辿っていけばなんとかなるだろうと思って試してみると、案外簡単にできてしまった。

"-L"オプションで実現しているのはローカルフォワーディングと呼ばれるらしい。
今度は、homepcからsshでgw1に入り、これまでとは逆にgw1へのアクセスをhomepcにフォワードしたい。こういう方向のものをリモートフォワーディングと呼ぶらしい。

結論から書くと自宅のマシンで

homepc$ ssh -t -g -Y -R 10022:localhost:22 gw1

としておいた上で、職場で

workpc$ ssh -t -Y gw1 ssh -Y -p 10022 localhost

とすることで、目的は達成された。
なお、workpcからはgw1へもgw2へもsshで入ることができる。
もしgw2にしか入れなければ、自宅からはgw2まで継いでおけば良い。

勝手に切断されないようにする

最後に、sshのコネクションは、何もパケットが流れないと5分程度で自動的に切断されてしまうらしい。
これを防ぐのにも色々な方法があるようだが、面倒なのでターミナルの一つで

$ tload -d 100

としてそのまま放置することにした。実際ロードを見たいことは多いし。

結局一切~/.ssh/以下の設定ファイルはいじらなかったが、設定ファイルをいじればコマンドラインを簡略化できるらしい。
しかしコマンドラインで書けるものならそうする方が好きなのでこのまま。
ただしaliasで単純な名前を付けておくので、簡単に実行することができるようにはなっている。

ということで、間に挟まったマシンにsshで入れる事が必要だが、おそらく何段挟まっていてもこの方法で同期や双方向のログインができると思う。

Python ctypes からmecabを使う例

2009-09-24T18:48:00.002+09:00

PythonとC/C++のインターフェイスとして有望だと思ったctypesとboost.python。
まずはctypesを利用する例。
もちろん自分でC/C++で書いた関数を呼び出すのでも構わないが、既存のCライブラリをPythonから利用したいというシチュエーションも多いため、まずはそういう例。

というわけで、形態素解析ソフトとして良く使われているmecabのライブラリをPythonから使えるようにしてみる。
ただし、実はmecabのPythonインターフェイスはmecabの開発元から配布されている事に気付いたので、ほんの触りだけ。
ctypesの使い方がなんとなく分かると思う。
要するにシェアードライブラリをそのまま読み込み、その中の関数を呼び出してくれる。
PythonとC間で引数や戻り値を正しくやりとりするために、必要に応じてその型情報を設定してやる必要がある。

ちなみにtext.txtには、インストールしてあるmecab用辞書に合わせて文字コードをUTF-8にした日本語文章が入っている。
他の文字コードの場合には適宜変換が必要になる。
また、unicode文字列を渡すことはできない。(segfaultになる)


import ctypes as C

MECAB_LIB_PATH = '/usr/lib/libmecab.so.1'
libmecab = C.CDLL(MECAB_LIB_PATH)
libmecab.mecab_sparse_tostr.restype = C.c_char_p
libmecab.mecab_version.restype = C.c_char_p
libmecab.mecab_strerror.restype = C.c_char_p

class MyMecab:

    def __init__(self, option=''):
        self.mecab = libmecab.mecab_new2('mecab ' + option)

    def __del__(self):
        libmecab.mecab_destroy(self.mecab)
        
    def parse(self, text):
        return libmecab.mecab_sparse_tostr(self.mecab, text)
    
    def version(self):
        return libmecab.mecab_version()

    def error_message(self):
        return libmecab.mecab_strerror(self.mecab)

if __name__ == '__main__':
    filename = 'test.txt'
    text = file(filename).read()
    mecab = MyMecab()
    result = mecab.parse(text)
    print result

PythonとC/C++のインターフェイス開発の手段

2009-09-23T21:34:00.008+09:00

手元のマシンにも4GBのメモリを入れ、もっと大きなメモリのデスクトップマシンも用意したが、その一番の理由は大規模なテキストの処理や行列演算などを行ないたいからだ。
行列演算そのものは、特異値分解(SVD)などの一般的なものがほとんどになるため、そのためのライブラリが必要になる。
さらに、できればC/C++でゴリゴリやるよりもスクリプトでやりたい。

それで、やはり馴染みのPythonとその数値演算用モジュールnumpyを使おうと思っている。
SVDをはじめ大抵のことはそれでなんとかなると思う。
しかし、中には自分で細かいところから書かなければいけない事もある。
numpyの良い点は、実際の計算のほとんどはC(Fortran？)で書かれた拡張モジュール内で行なわれるので、Python<->C間でのデータの受け渡しなどのわずかなオーバーヘッドがあるだけで、とても効率良く計算できることだ。例えば行列のかけ算などは実際にはそのすべてがCモジュール内で行なわれる。
しかし行列の要素の一つ一つに個別にアクセスするようなコードをPythonで書くと、その一つ一つでオーバーヘッドが生じ、実計算と比率として無視できなくなってくる。

ということで、やはり自分がやりたい計算はC/C++で書いて、それをPythonからシームレスに呼び出せるようにしたい。
そういう目的のための基本はPythonのCライブラリを利用して正規の拡張モジュールを作成することだろうが、リファレンスカウントなどの面倒も自分でみなければいけないとか何かと面倒っちい。
また、既に存在するC/C++のリソースを取り込むのも面倒だ。
幸い正規のモジュール開発方法以外にも、Pythonには様々なC/C++インターフェイス開発方法が用意されている。

その中で最終的に選択肢として残したのは、ctypesとboost.pythonだ。

ctypesはなんと言っても2.6で正規モジュールになり、2.5.xにもバックポートされていること、またPython3.xでも正規モジュールになっており、先々を考えても安心感があることが大きい。
さらにctypesの良い点は、既存のライブラリ(shared object)があれば、Cコードを書く必要がなく、Pythonサイドだけで方が付くという点だ。
もっともその分Python内でライブラリ関数の引数の型情報の設定などが必要だが。

boost.pythonは、C++のSTLの拡張とも言えるboostライブラリに含まれている。
boostはとても活発に開発されており、標準化の進捗と共にその一部はC++の規格自体に取り込まれるらしい。
そういう活発な開発母体があるので、Python 3.xにも対応するのではないかと期待している。
また、C++用ということもあり、C++のSTLや、もちろんboostのその他のライブラリも利用できるため、何かと便利だ。
で、実際に試してみたのだが、思っていた以上に簡単に使うことができた。
二つの点を除いては、もうこれが本命と言って良いと思う。
一つは、あくまでもPythonの外部から提供されているものであり、ctypesのようにPython正統のものではないこと。
もう一つは、いずれこの点も書きたいが、並列処理との兼ね合い。

ということで、ctypesとboost.pythonがお勧め。
サンプルはいずれ。

Debian GNU/Linux amd64で困ったこと

2009-09-23T21:19:00.003+09:00

64ビット版でもほとんど何の問題もないが、若干i386にはあるがamd64には無いパッケージああるようだ。
例えばmozartがない。
$ apt-cache search mozart
とすると、mozart-docなんてのがあるのに、本体がない。

色々ググると、どうやらmozartは64ビット環境ではコンパイルできないらしい。ポインタのサイズとintのサイズが等しいことを前提とするようなプログラミングがされてしまっているようで、そこで問題が出ているらしい。
単純に -m32オプションを付けてコンパイルしただけではだめなのかな。
そのうちソースを持ってきて試してみたいが、そんなことだけでなんとかなるならもう誰かやっていると思われる。
CTMCPを読み進むのにmozartを使いたいが、いざとなったらVMwareの上に32ビット版でも入れようか...
chrootして32ビット環境を、なんて話もあるらしいが、そういうことやったことはないのでまた一調べしてからじゃないと試せないし、他には特にどうしても32ビットで使いたいものもないので、多分VMwareに落ち着くだろう。

そうそう、さすがにCore2Duo+4GBmemだとVMware上のVistaも快適快適。
CPUパワーは正義なり・・・

Linux 32ビット版と64ビット版の違い -- データサイズ

2009-09-23T21:06:00.004+09:00

64ビット版のＬｉｎｕｘに移行しても、普通に使っている範囲では32ビット版との違いを意識する事はまずない。
しかし内部ではちゃんと変化がある。

末尾に付けたtest.cというファイルは、
$ gcc test.c
でコンパイルできる。そして実行すると
int = 4
int* = 8
void* = 8
long int = 8
long long = 8
short int = 2
float = 4
double = 8
char = 1
wcahr_t = 4
となる。

これが32ビット版のLinux上では
int = 4
int* = 4
void* = 4
long int = 4
long long = 8
short int = 2
float = 4
double = 8
char = 1
wcahr_t = 4
となるはずだ。

long longが4->8バイトになっている以外に、ポインタが64ビットになっている事が分かる。64ビットアドレッシングになっているからだ。
ちなみに、amd64(６４ビット版)の上でも32ビット版としてコンパイルすることはできる。
$ gcc -m32 test.c
とすれば良い。
ただしシステム全体は64ビットで、ライブラリ等ももちろん64ビット版としてコンパイルされているので、-m32でコンパイルするにはlib32で始まる32ビット用パッケージをインストールする必要がある。
$ apt-cache search lib32
などとすればそれらしいものが見付かる。


# filename: test.c
#include < stdio.h>
#include < wchar.h>

int main()
{
   printf("int = %d\n", sizeof(int));
   printf("int* = %d\n", sizeof(int*));
   printf("void* = %d\n", sizeof(void*));
   printf("long int = %d\n", sizeof(long int));
   printf("long long = %d\n", sizeof(long long));
   printf("short int = %d\n", sizeof(short int));
   printf("float = %d\n", sizeof(float));
   printf("double = %d\n", sizeof(double));
   printf("char = %d\n", sizeof(char));
   printf("wcahr_t = %d\n", sizeof(wchar_t));
}

Linux 32ビット版と64ビット版の違い -- アドレス空間

2009-09-23T20:52:00.003+09:00

というわけで今やメイン環境はDebian GNU/Linux x86_64(64ビット版)になった。

そもそも何故64ビット版に移行したのかというと、このノートもメモリが4GBだが、もっと多くのメモリを搭載したデスクトップマシンを使えるようになったが、その時にアドレス空間が32ビットという足枷を外したかったからだ。
Core2Duo(Pentium4位から？)には実は拡張が施されていて、32ビットモードでもアドレス空間だけは36ビットでアドレッシングできるらしい。
4GBというと丁度32ビットアドレッシングの限界なわけで、それ以上のメモリを積んでも扱えなくなってしまうわけだが、36ビットになって4ビット増えた事でその16倍、つまり64GBまでは扱えるようになっていたらしい。今度手に入れたデスクトップもさすがにそこまでのメモリは積んでいないので、32ビット版のLinuxでも良いのかも知れない。

が、実は32ビット版には、1プロセスでは2GBまでしか利用できないという限界もあるのだそうだ。さらに、実際のカーネルによるメモリ配置と利用法により、実際には2GBすら使えないらしい。
これまで使っていたマシンで最大のものでも2GBメモリだったので、そこまでを現実問題として考える事はなかった。しかしもはやノートでも4GB、そしてそれ以上のメモリが利用できるようになった。

そして64ビット版では、アドレス空間は64ビットに綺麗に広がり、1プロセスでの上限の壁も消えているらしい。
という事で、64ビット版に移行した第一の目的は、大規模メモリを無駄なく利用できるようにするためだ。

Linux x86_64 (64ビット版)

2009-09-23T20:21:00.004+09:00

ふう、なんと先月は一度も書かなかった。やっぱ続かないな...
というわけで久し振りだけど、無理せず少しずつメモがわりに書いていこうと思う。
なるべくググってもあまり情報が見付からなかった事を中心に。

一時はVistaをメインにしてみようかなどとも考えてVista上にEmacsを導入したりC++コンパイラを入れたりとやっていたが、結局Linuxに戻ったという話。
しかし戻った先は64ビット版だった。

実は先月自宅メインマシンとすべくThinkPad T500を購入した。
IBMからlenovoに変わってからのモデルはちょっと敬遠していたが、他に移る先も見付からず、設計はまだ日本の大和らしいという事でThinkPadに落ち着いてしまった。
ディスプレイは1680x1050、WSXGA+という規格なのだそうだが、最近主流のワイドというのだろうか、横長だ。正直、横より縦が欲しいし、液晶の上、筐体としてはまだ余裕あるよなぁと思うものの、昨今の液晶パネル生産・供給事情というものもあるのかもしれない。
それでもこれだけ横があると、Gnomeのパネルを左右どちらかに縦にして置いて、そしてEmacsを二枚並べても余裕がある。これはいい。
そして今なら当然と言えば当然だが、自宅ノートでは初めてCore2Duo搭載マシンだ。
メモリもこの際4GBにした。
一昔前と比べるととにかく安い。これで12万ちょっとだった。
まだタマが入っていた頃のLet's note、あれはいくらだっただろう・・・CPUは何だっただろう・・・メモリは・・・ディスプレイは・・・・・・本当に隔世の間がある。
ハードディスクにしても容量が足りなくて、ext2に圧縮パッチを当てて自動圧縮して稼いでいたな。

それで、結局というかやっぱりというか、Debian GNU/Linuxに戻ってきたわけだが、この機に64ビット版に移行した。
Debianのディストリビューションには様々なプラットフォーム向けがあるが、フツーのPC、つまりIntelのPentium系列の場合には一般的に i386 というものが使われている。
しかしPentium4あたりからだったか、忘れたけれど、今のCore2Duoには64ビット拡張が施されていて、「64ビット版」として動作する。
ここでわざわざカッコ付きにしたのは、64ビット版ってどういう意味？というのをテキトーに流したかったから。何が64ビットだと64ビット版だとか議論し初めると、なかなか複雑な話になるようだ。
とりあえずは、レジスタも64ビット長になり本数も増え、64ビット演算もあるらしい。
マシンインストラクションの構成と構造も32ビットモードと64ビットモードで異なるらしい。

細かい事を考えなくても、今時のフツーのPCを使っていれば、i386版ではなく amd64 版のインストーラを使うだけで、何の問題も違いもなくインストール作業は終了する。
とりあえず lenny の amd64 用イメージをダウンロードしてCD-Rに焼き、最低限だけインストール(インストールの最後の方で聞かれる環境だのサーバー環境だの、そういうのも一切チェックを外して入れない)し、すぐに /etc/apt/sources.list を編集して sid にし、apt-get update, apt-get dist-upgradeを行なった。
その後リブートし、必要なパッケージを随時インストールした。

とりあえず見た目は32ビット版と何も変わらない。 uname -a とするとカーネルのバージョンに amd64 という文字列が含まれている位だ。

b-mobile 3GをLinuxで使いたいが、だめ・・・

2009-07-18T16:59:00.005+09:00

150時間の通信時間が付いているb-mobile 3Gのhours 150というのを入手した。
USBコネクタに差して使う通信端末で、購入代金に通信料が含まれているため別途月々の料金は発生しないというものだ。150時間使い切るか使用期限の480日が来るまで利用できる。使い切った後は通信時間だけ買い足す事もできるそうだ。

普段は家や職場のネットワークを使えば良いわけだが、出先でも自分のPCでネット接続したい事がある。今のケータイではGmailも読み書きできるのでちょっとした事なら問題ないが、場合によってはファイルをアップロードしたりダウンロードしたり、あるいはそれに手を入れたりしたい事もある。そんな時のためにやはり接続手段は用意しておきたいと思っていた。しかし、使わなくても月々の固定費が取られるPHSやE-mobile、あるいはケータイのデータ通信プランを契約するのもなんだなと思っていた。そんなときに、端末購入代金に通信費も含まれるb-mobileというのを知った。というか、確か以前聞いたことがあったが、当時はあまり興味が湧かなかったものを再発見し、こっちの方がおもしろいかなと思い試してみることにした。実はE-mobileにしようかとも迷ったが、最終的にはこちらはFOMAの電波利用ということでドコモの圏内ならどこでもつながるという事でこちらにした。

それで、そのセットアップはとっても簡単だった。
まずは携帯から電話して開通手続なるものを終える。それから15分くらいすると実際に使えるようになるそうだ。
PCのセットアップも至極簡単。セットアップCD-ROMを入れ、数回クリックするだけだった。
このあとUSBコネクタに差し、認識してランプが赤から緑に変わったら準備OK、インストールされたb-アクセスというアプリのアイコンをダブルクリックして起動し、接続ボタンを押すだけだった。接続が確立すると緑のランプが点滅状態になる。速さは測定していないが、体感として、まあ普通にウェブブラウズするのなら特に問題はなさそうだ。

と、ここまではMS-Windowsの話。
Winで繋がればアクセス確保ということで一安心なんだが、できれば普段起動しているLinuxでも接続したい。それでネット上で情報を漁り色々と試してみた。

結論から言うと今のところ接続できず。
はじめはモデムとしてすら認識してくれなかったが、ネット上の情報を参考になんとかそれはクリアしたっぽいが、残念ながらモデムのATDTコマンドで発呼しようとするところで NO CARRIER となって失敗。
今のところその状態で放置しておく。ネット上の情報では、Ubuntuなどで使えているようなので、なんとかなできるんじゃないかとは思うんだが...
参考にした情報などは項を改めて。

メーリングリストって

2009-07-02T20:33:00.003+09:00

さて、久し振り、なんてもんじゃないな・・・
ジムと同じで、調子良く通ってる時期には続くけど、一旦面倒臭くなってサボり初めるとズルズルとサボりが続くんですね、ブログって。
ちなみにジムは最近調子良く通ってます。ちょっと贅肉が気になってきたので・・・
もともと計算機の設定系の話で後々のためのメモ程度の積りで始めたので、特にそういう事柄もないと遠ざかるのは仕方ないんだけど。
でも最近、ブログってこれからの時代大事だよなぁ、やっぱ、と思うこともあり、巷に多い一言日記風でもいいからチョコマカ書いてみようと思う。といいつつ、書きはじめると一言では済まなくなって無駄に語数が増えていく・・・

それで、メーリングリストだけど、いや、メーリングリストどころかメールそのものについても、案外世の中の人はまだまだ知らなかったり充分に使ってなかったりするみたいだと気付いた。
メーリングリストなんて、結局のところ同時に多数の相手にメールを送れるってだけなわけではあるんだけど、使い方によってはとても効用の高いメディアだと思う。

その使い方というのが問題なわけだけど、基本はメーリングリストのメンバー(これは普通何か共通の興味・関心を持つ集団のはず)が興味を持つかもしれない内容について、あるいは、共有する事で全体の利益が向上する可能性がある内容について、とにかく情報を流し共有するのが第一だと思っていた。
(もっとも「情報量」の無いゴミメールばかり流してはそれはスパムと呼ばれてしまう...)

多くのメーリングリストでは、質問とそれへの返答というのがトラフィックのかなりの部分を占めているんじゃないかと思うけど、Q&Aだって共有するのがとても大事な情報だ。
その時点では興味を持っていなかったことだって、後になって自分も同じ問題に直面し、その時の回答を探して読むなんてことも普通にある。
メーリングリストシステムがアーカイブ機能を備えているのはそんな時のためでもあるだろう。
質問者と回答者が二者間だけでやりとりするのではなく、メーリングリストの中でやりとりすることで、直接そのやりとりに参加していないメンバーにも情報を与える事になる。結果的にコミュニティ全体の利益になる。

もう一つ大事なのは、(メーリングリスト内限定とは言え)オープンな環境で意見を交わし合う事だと思う。
そもそもが同じ関心を共有するメンバー達だから、誰かと議論している時に「横から」口を出してくる人もいるだろう。
議論が行き詰まっている時に、こういう「第三者」がつい軽視していた事実や可能性なんかに気付かせてくれる事もある。場合によっては、その内容についてより詳しい人がコメントしてくれる事もあるだろう。

結局、大事なのはオープンさと共有することだと思う。

ところが、これが嫌いな人もいるらしい。
プライベートな話という訳でもないのに、自分のメール(意見)が「第三者」の目に触れるのが嫌な人もいるようだ。
そういう人は大抵は自分の「意見」に反論されたり議論する事そのものが嫌なようだ。
質問や間違いの訂正を「ケチを付けられる」ことと感じていたりするようだ。場合によっては人格への攻撃とさえ受け取っていたりするのかもしれない。

そんな感覚だと、せっかくメーリングリストがあっても、事務連絡のための、それこそ同報メールシステムとしてしか使われなくなる。
正に道具は使い様。
ちょっと勿体無い気もするけれど、結局のところマインドの問題なので、どんなに技術が進歩しても有益な機能が増えてもどうにもならないのかなぁ、と思った。

Debian GNU/Linuxのptexでjsartilceなどを使う時のフォントの問題

2009-04-27T22:09:00.002+09:00

久し振りにThinkPad T43のLinuxをゼロから入れ直した。
一度現時点の安定板であるlennyを入れてからtestingにdist-upgradeした。
いつも引っ掛かるのは、ptexでjsartilceやjsbookなどのクラスを使うとdvipdfmxでPDFファイルを作成する時にフォントのエラーが出る事だ。
毎度ネットを漁って解決法を探しては思い出すので、メモっておく。

Debian GNU/Linux squeezeで日本語TeX環境を用意するというブログを参考にした。

jsシリーズのドキュメントクラスを使った時にdvipdfmxでフォントのエラーが出て変換できない事への対処としては次のことだけ。(上のリンク先から引用)

/etc/texmf/dvipdfm/dvipdfmx.cfgの末尾に以下を加える。

f jis-cjk.map

Xming

2009-04-27T20:54:00.004+09:00

かなり久し振り・・・
マメに書いてる人は凄いなぁ・・・

母艦のデスクトップでVistaを使うようになって、SKKIMEやkeyswapやkeyhacのお陰で文字入力についてはとても快適に過ごしてる。
おまけにNTEmacsとddskkとptexのお陰で文章書きもかなりLinux上と同様にできるようになった。
でも、やっぱり細かいところでLinuxというかDebianの快適さにはかなわない・・・
結局Windowsの上ってウェブで遊んだりOffice使ったり商用ソフト使ったりするのにはそれなりにいいんだけど、やっぱりEmacsを起点にしてプログラム書いたりあれこれいじるのはLinuxが一番か...

ということで、Linuxに戻ってもいいんだけど、実は母艦のディスプレイは24インチで新しいのに対してLinuxを入れてあるノートPCはそれなりに年数も経て結構画面が汚い・・・(母艦にも一応Linux入ってるけど)
Linuxでは基本的には背景はxplanetなどの暗い系だし、Emacsも背景は青暗くしてある。なのであまりディスプレイが暗いとか汚いとは思わないんだけど、背景が白いアプリ、ウェブブラウザも含めて、そういうのだと白が黄ばんで見える。特にデスクトップの24インチのやつの真っ白な綺麗さと比べると際立ってしまう。
ということで、ノートのLinuxを綺麗な画面(のVista)から使えるようにするために、VistaにXサーバを入れる事にした。

だけどcygwinは入れたくないし商用のサーバ買うしかないかなぁと思ったが、調べてみると他にもフリーのものがあった。
Xmingだ。
なんでも、X.orgをMinGWのコンパイラでコンパイルしたものらしい。

さっそく、上のリンクからXming-6-9-0-31-setup.exeとXming-fonts-7-4-0-3-setup.exeの二つをダウンロードしてインストール。

詳しい使い方は調べていないが、とりあえずインストールされた中の一つ、Xlaunchを起動して実行してみた。

まずはMultiple windowsというのを選択した。One windowだとルートウインドウのようなものも表示されてしまう。

次にプログラムを起動するように指定。

そしてプログラム名とリモートのIPアドレスとユーザ名、パスワードを指定。

あとは二回ほど「次へ」をクリックで、無事起動できた。
当然Emacsを起動したが、普通に使える。
なかなかいい。

CherryPy Essentialのサンプルコードのダウンロード

2009-03-31T23:04:00.006+09:00

随分久し振りになってしまったが、作業メモ。
と言っても結果的にはメモるほどのことではしてない。。。

しばらくの間一応Vistaを使っているので、CherryPyもVistaで動かしたい。
CherryPy Essentialsを読みながらちょこちょこ試すのもVistaでやろうと思う。
で、本を読みながらVistaにCherryPyをインストールした。
いつものようにEmacsの中のbashで

$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ python ez_setup.py

でEasy_installをインストールし、

$ c:/Python25/Scripts/easy_install-script.py cherrypy

でCherryPyの最新版をインストールした。途中"Can't process ..."とか出てたけど、とりあえず無視。一応インストールはできたらしい。後でサンプルを実行してみて問題があれば戻ってくることにする。

で、サンプルを試そうと思ったが、当然手で打ち込むなんて真似したくないので、CherryPy EssentialsのホームページからダウンロードしようとチェックしてみるとSubversionでの取得方法しか書いてないような。。。
仕方ないのでSubversionを入れてみようと思った、が、何かWindows用バイナリをダウンロードしようとすると、飛ばされたサイトでアカウント登録を求められたりする。。。
なんか嫌だし面倒になってやめてしまった。

結局Linuxを入れてあるノートのSubversionでダウンロードし、それをコピーしてきた。。。

Vistaはなかなか快適とは書いたが、その後Linux(Debian)も最新安定板のlennyをインストールし直して個人設定も整理して改めて比較してみると、やっぱりLinuxの方が快適だなぁ・・・
長年の個人設定の積み重ねやツール群への慣れもあるけれど、やっぱりLinuxの方がいい。
それに今回のSubversionもそうだが、Debianのaptでのパッケージ管理はやっぱり楽。楽過ぎ。バイナリをダウンロードしてクリックするだけでほとんど済むウィンドウズと比べても、やっぱり楽。安心。

ただどうしてもVista上でOffice 2007を使わないといけない都合もあるし。。。
という事で、とりあえずはこのままだけど、なるべく早いうちにLinux上のVMware Workstationがちゃんと動くようにして、その中に改めてVistaとOffice 2007をインストールし直そうと思った。

Vista環境その3 (Visual C++ 2008 Express Editionをbashから使う)

2009-03-01T20:30:00.004+09:00

前回MinGWとその中のgccをインストールをしたは良いが、とりあえずg++は先延ばしにしておいた。MinGWのインストーラがg++で失敗するからだ。しかしCで書く事はほとんどなく、欲しいのはC++だ。なんとかしてMinGWのg++を入れようかと思ったが、やはりやめておくことにした。インストーラで成功しなかったのもあり、今後もちゃんとメンテされるのかに不安が残るし。それに、Windows上にLinuxと同じような環境を、とは言っても、そこまで無理する必要はない。cygwinもそうだけど。ちょっと無理矢理でしょ。win使うなら、まあ無理がないところからnativeなツールを使うようにはしたい。
Emacsとその中のbashとそこから使う基本的なコマンドはあまりにも頻繁に使ってきたので、それなしの環境は考えられないが。
という訳で、C++はMicrosoftのものを使ってみる事にした。
実はもう一つ理由がある。どのページだったか今探しても見付からなかったが、gcc, icc(Intel謹製コンパイラ)とVisual C++のパフォーマンスの比較をしてあるページがあったが、そこでVisual C++がとても速かったからだ。確か、Linux上のgccはもちろん、icc(on Linux)よりも速かったような。

ということでまずはMinGWとMsysをアンインストール。してもディレクトリや一部ファイルが残るのでそれらは自分で削除。その代わりwin用のbashのバイナリがあったところからリンクがあった、unix tools for windowsとかいうところのバイナリをいくつか入れた。この中にはmakeもある。実はMinGWのmakeはどうもいつも使っているGNU makeとは違う動きのようだった。こちらのmakeは大丈夫のようだ。

で、Visual C++ 2008 Express Editionをダウンロードしてインストール。
これはMicrosoftが無償で提共しているもので、他にもVisual Basic、Visual C#、Visual Web Developerがある。インストール・設定後に少し試してみたところ、STLはちゃんと入っている様子。ただしboostは無い。

これでGUIを作ったりIDEから使う気はあまりない。とにかくEmacsのshell(bash)から使えるようにしたい。
コマンドラインから、しかもbashからどう使えば良いのか、なかなかその手の解説は見付からないし、winの勘はないしで結構苦労したが、とりあえず~/.bashrcに次のような設定を加えることでbashの上からC/C++のファイルがコンパイルできるようになった。


VSINSTALLDIR="/Program Files/Microsoft Visual Studio 9.0"
VCINSTALLDIR="/Program Files/Microsoft Visual Studio 9.0/VC"
FrameworkDir="/Windows/Microsoft.NET/Framework"
FrameworkVersion=v2.0.50727
Framework35Version=v3.5
WindowsSdkDir="/Program Files/Microsoft SDKs/Windows/v6.0A"
DevEnvDir="/Program Files/Microsoft Visual Studio 9.0/Common7/IDE"

## **CAUTION** paths are separated by ";" in the following two
export INCLUDE="$WindowsSdkDir/include;$VCINSTALLDIR/include"
export LIB="$WindowsSdkDir/lib;$VCINSTALLDIR/lib"

export PATH="$WindowsSdkDir/bin":"$DevEnvDir":"$VCINSTALLDIR/bin":"$VSINSTALLDIR/Common7/Tools":"$FrameworkDir/$Framework35Version":"$FrameworkDir/$FrameworkVersion":"$VCINSTALLDIR/VCPackages":$PATH

visual c++のコンパイラのコマンド名は"cl"、リンカは"linker"だそうだ。これで


$ cl test.c

や


$ cl test.cc

とすればコンパイルできて、test.exeが作成される。ファイル内に日本語がある場合にはsjisにしておかないといけないようだ。Emacsの設定を変更しないと。

INCLUDEとLIBはclが参照する環境変数のようだ。名前の通り、インクルードファイルのあるディレクトリとライブラリ(DLL)のあるディレクトリを指すためのもの。
これは.bashrc内の設定だが、この二つはcl.exeというウインドウズプログラムにより参照されるという点を意識する必要があった。

bashでは、環境変数の、例えばPATHなどで、a, bという二つのパスを設定するには


PATH=a:b

のようにする。":"がセパレータだ。しかしwinではセパレータに";"を使う。
なので、INCLUDEには一つの文字列だけ設定し、その中にwinの環境変数として";"で区切った複数のパスを設定してある。bashのための設定としては普通こんな事はしない。

という訳で、とりあえずbashからVisual C++ 2008 Express Editionでコンパイルできるようになった。
C++でunixやwinに偏ったプログラムを書く気はないので、その範囲で使う分には恐らくこれで問題はないと思う。それにPythonなどこれまでインストールしてきたwin用のバイナリもほとんどはvisual c++でコンパイルしてあるようなので、むしろ相性は良いだろう。

あとはclやlinkerの細かいオプションを調べて基本的なMakefileを書いてしまうだけ。

そうそう、面倒なのでとても重要なもの以外はリンク張ってませんが、キーワードで検索すればすぐ見付かると思う。

Vista環境その2 (スリープ不調も)

2009-03-01T11:49:00.006+09:00

Vista上にLinuxで使用しているものを整える続き。

・ガジェットにGchecker追加。Gmail通知用。その他設定変更で好みに。
・Mozart(Oz)環境導入。OZEMACS環境変数にemacsのパスを追加。

今更だが、winではほとんどのインストールはダウンロードしてダブルクリックするだけでできる。時々インストールパスいじったりインストール後の設定をいじったり。unixや初期のLinuxと比べれば楽といえば楽。しかしDebianのaptと比べると面倒に感じる。統一感にも欠ける。いっそaptのような統一された管理システムがあってもいい。

・keyhac導入。説明が少なく今一つ分からないなりになんとかキーバインド設定変更。Linux上でxmodmapでやっていることはほぼ完了。しかしCapsLockとCtrlキーの交換がうまくいかない。

Ctrlのようなモディファイアキーはどうやらキーコードの発生のさせ方が、デバイスの時点なのかwinがやっているのか分からないが、違うらしい。なのでコードだけ入れ変えても発生の仕方がモディファイアの様にならないためにうまくいかないように見える。今のところkeyhacでの解決法は分からない。仕方ないのでCapsLock<->Ctrlだけはkeyswapで変更し、その他はkeyhacで設定した。できればkeyhacだけでできるようにしたい。
また、ウィンドウ操作についてもサンプルにもウィンドウの単純な移動程度の例しかない。sawfishのように他のウィンドウにぶつかるまで移動するようなことがやりたいが、できないのかもしれない。ウィンドウの縦とか横とかへの最大化なんかの操作もやりたいんだが。今後の課題。

・うまくスリープできない問題の回避方法発見。USBメモリを抜いておく。

スリープを選んでもディスプレイは消えるが本体の電源は落ちなかったり、一度は落ちたようでもその瞬間にスリープから戻ってしまう状態が続いていた。BIOSのアップデートや設定確認、そしてネットも漁ってみたが解決できなかった。その原因がやっと分かった。
スペック的にあまり必要ないと思いながらもreadyboostのためにUSBメモリを本体裏面に差しっ放しにしてあったのをつい忘れていたが、USBメモリを差したままにしておくとスリープに入ってもその瞬間にまた立ち上がってしまう。抜いておけば問題なし。キーボードからのwakeupの禁止のようにデバイスドライバーの電源管理の項目で制御できるかと思ったが、プロパティにそんな項目見当たらず。仕方ないのでreadyboostは止めて、その他のUSBメモリも抜くよう気を付けるしかない。

色々やっているうちにディスクが足りなくなってきたので、パーティションを切り直し、Vistaのパーティションを拡げた。そのためにはLinuxパーティションを削除する必要があったので、削除し割り当て直した。データは全てバックアップしてあるので、Linuxも久し振りにインストールし直す事にした。Debian lennyがつい先日正式リリースされたばかりだし。

思いの外Vistaが快適だったので、Linuxで使っているものをどの位整えられるかと思って始めてはみたけど、やっぱDebianの方が快適…
フォント回りとかOfficeを使わないといけない事とか、いくつか問題はあるけれど、やっぱりDebian GNU/Linuxの方がいいなぁ…
どうしてもwin使ってないといけない事もあるので、一応継続してVista上でも大抵の事は困らないようにしておきたい。Linuxの時と同じキーバインドでEmacsとLaTeX,Pythonあたりが使えるだけでもかなり改善したが。

Vista再導入、Linuxに近い作業環境を整え始める

2009-02-28T09:47:00.006+09:00

前回ノートPCが逝ってしまいあえなく中断したVistaの導入を再開した。例のノートはやはり壊れたようなので、デスクトップに。実は以前からLinuxの母艦にもVistaも一応入れてあった。パーティションも30GBほどしかなくVistaをインストールしただけの状態のままほとんど起動もしていなかったが。
今回母艦上でVistaをいじくって分かったのは、聞いていたよりよっぽど快適だという事。ノートの方はちょっと古かったのでパワー的に問題があったが、まだ一年程度のデスクトップだと、ディスプレイも24"あるし、とても快適。メモリ使用状況などを見てもそれほどギリギリという訳でもない。細かい不満はあるものの、Linux上でよく使っているものも結構準備できそうだという事が分かったので、そのあたりを揃えてみる事にした。

ということで、また別のマシンで設定するかもしれないのでやった事をメモだけ。

・readyboostのためのUSBメモリを差して設定。このマシンではあまり必要ないかも。
・Lhaca+デラックス版導入。圧縮伸長ツール。
・keyswap導入。キーの交換。CTRL<->Caps_Lock, Henkan->Muhenkan, Alt->Escなどいつものもの。istaでは管理者権限で実行しないとだめ。
・7-Zipポータブル版導入。圧縮伸長ツール。
・Firefoxポータブル版導入。USBメモリからフォルダをコピーしただけ。
・Gimpポータブル版導入。同上。Photoshopみたいなの。
・Inkspaceポータブル版導入。同上。Illustratorみたいなの。
・Scratch導入。同上。
・SmatraPDFポータブル版導入。同上。Acrobat Reader8だけは以前入れてあったので必要ないか。
・SKKIME導入。SKK-JISYO.Lも導入して設定。IMEのデフォルトもSKKIMEに。
・Google Earth導入。Linux版は動きが悪かった。今回はじめてVistaで試したが快適。
・SkethUp。Google Earthのついで。まだ使ったことはない。
・explore2fs導入。ext2(3)パーティションからファイル読み出し可能に。
・NTEmacs + apel + SKK(DDSKK) + SKK-JISYO.Lを導入。SKK-JISYO.LはSKKIMEと同じものだが、どうもSKKIMEはファイルの中身を変えてしまうようで共用するとおかしくなるので別にした。
・Emacsのstartup.el内で自分で選んだ場所をホームディレクトリに設定。(setenv "HOME" "...")
・.emacs, .emacs.d/* の設定。Linuxで使っているものを一部修正した。キーバインドも一部修正。
・bashの導入。.bashrcの設定。PATHやPS1、aliasなど。Emacsのshell-modeで利用できるように設定。これでLinux上と同様のmulti shellが使えるようになった。
・pLaTexの導入。「LaTeX2ε美文書作成入門第4版」付属のCD-ROMから。WinShellは入れず。bashのエイリアスでxdvi, dvipdf, xpdfなどで各ツールを起動できるようにした。思った以上にスンナリ導入できた。
・Python2.5.4の導入。python-mode.elも導入。面倒なので.emacs.d/に置いた。python実行ファイルのパスの設定も追加。これでEmacsからpy-shellでPythonが利用できる。
・numpy導入。Pythonで行列算など。
・scipy導入。Pythonで科学技術計算。
・PyQt4導入。
・matplotlib導入。MATLAB風ツールfor Python。Emacsのpython-shellからだとグラフ描画がおかしい。固まる。原因不明。ネット上でも一二件しか同様の問題報告が見当たらず、しかも解決策見付からず。困る。IDLEからは問題なし。なぜだ。
・gnuplot導入。なぜかEmacsのcomint-runからだと問題が。matplotlibの問題と関係があるかも。Emacs環境特異。プロセスとのやりとりの問題？文字コードの問題の可能性もあり。bashではそういう事があった。
・R + rpy2導入。統計解析ソフトとPythonインターフェイス。これもグラフ表示で同様の問題。
・VMware Player導入。vmware.comからダウンロードしてインストール。いつも思う、日本法人(というかなだの窓口？)の存在価値ないよね。
・Windows XPのVMware用イメージ導入。これまでLinux上のVMware workstationで使っていたもの。とりあえずOffice 2003とか入っているので当面必要。
・VMplayer用Debian lennyのイメージを導入。vmware.comのappliance集からダウンロード。aptでとりあえず必要なパッケージを追加。いざとなったらこのLinuxに逃げ込めるようにしておく。

この位までで一息。
そして、耳にした事はあったが良く知らなかったMinGW(Minimalist GNU for Windows)を導入する事にした。cygwinは仰々しくてやだなぁと思っていたが、こちらはwin32ネイティブで導入ももっと手軽そうなので。いくらbashだけあってもgrepだのdiffだのそういう細かいツールがないとシェルの威力も半減だし。

・MinGW導入。ただし、g++を選択すると展開エラーでインストールが異常終了してしまう。仕方ないのでコンパイラはgccのみ。しかもversion 3.x。
・MinSys導入。MinGWの片割れらしい。開発環境となる細々したコマンド類。
・.bashrcでパスを通してEmacsのshellモードから使えるようにした。どうせEmacsの中からしか使わないので、Vistaの環境変数はあまり触らない。MinGW, MinSysのパスは前に入れる。そうしないとfindコマンドとかvistaのアホfindを先に見付けてしまう。EmacsからもM-x grepできる。これないとほんとに不便。

このあたりで力尽きる。
今後整えていきたいもの。

・Office 2007。そもそもこれが必要になりそうだったのでVistaを導入。購入はしばらく先になりそう。
・Adobe Creative Suite導入。CS2があるので。Acrobatだけは結構使う。これまでVMware上のwinxpで使っていたもののライセンスを移動予定。
・auxtexの導入・設定。LaTeX作業をもっと楽に。
・適当なRDBMS。pythonからアクセスできるもの。後々同じプログラムをLinuxでも動かせるようにどちらでも使えるもの。できればInterbaseのようにバックアップがファイル一つのコピーで済むような手軽なもの。Debianでapt-getでインストールできるもの。
・BeautifuSoup、DBIなど、Pythonの諸々のモジュール群。時々しか使わないようなものも入れると結構たくさんあるので少しずつ。
・mecabなどの形態素解析ソフトとPythonインターフェイス。
・gcc, g++。できれば最新の4.x系。gdbも。g++についてはSTLとboostも必要。
・そういえばGNU nanaのようなassertionツールも欲しい。
・CVSなどバージョン管理システム。Emacsインターフェイス。
・CherryPy導入。Pythonが動けばほぼどこでも動くらしいので多分問題ない。
・いっそVisual Studio入れてvisual c++使ってみようか。折角なのでPythonの拡張モジュールもコンパイルできる環境にしたい。
・辞書。そういえば最後に買ってから結構経ってるので新しいものが出ていないかチェック。Emacsのlookupで検索できるようにする。
・新たに見付けたkeyhacの導入。キーバインド変更ツール。しかもPythonスクリプトで設定できる。キーと文字のバインドだけじゃなく、キー操作にプログラム呼び出しまでバインドできるらしい。大分前にunixで使っていたscwmを思い出す。scwmはもう消えて存在しない。確かScheme Configurable Window Managerというのが正式名だったか。Schemeプログラムでウィンドウマネージャーの操作を色々できて、ほんとに便利だった。keyhacはそれと同じような事ができそう。まだ触ってないが是非とも試したい。

調べないといけないこと。

・unixのcronのようにプログラムを定期的に自動実行する方法。
・Emacsのpy-shellからだとmatplotlibやrpy2などからウィンドウを出すと一度でかたまり戻ってこなくなる問題の回避方法。Emacsとプロセスとのやりとりあたりが怪しい？Windowsの中身よく知らないので分からない…

しらべてみようかなと思うこと。

・windowsの内部全般。まじめに勉強したことないけど、やはり多少は知っておくべき。
・Pythonのwin32モジュールの使い方。使えると便利そう。

メモだけなのに随分長くなった。全部じゃないけどこれまでやったことを大体書いた。
別のマシンで同様の環境作る時のためでした。

遅ればせながらVISTA導入、そしてVistaマシン逝く・・・

2009-02-23T17:44:00.007+09:00

備忘録代わりのメモの積もりだったのがなんとなく日記のようなものになりつつある・・・

さて、このところようやくVistaをまじめに使ってみようとしている。
自分は使いたくなくても、主にMS-OfficeのためにWindowsを使わざるを得ないことが多い。これまではXPの上でOffice 2003を使っていたが、どうやらそろそろOffice 2007を用意しておかないといけないかなという状況になってきた。ならばもうこの際なのでVistaも使おうかと。本当はやり過ごしてSystem 7に移行したかったんだけど。

これまでXPは古いマシンと母艦のLinux上のVMwareの中で使っていた。今回はせっかくなので最近あまり使わなくなったPentium M 1400MHz 1.5GBmemのノートに入れてみた。
インストールは問題なく済みその後あれこれいじっていると、いつまでたってもなんだかディスクをがりがりやっている。そのせいかどうも必要以上に遅いような気がしたのでネットを漁ってみるといろいろと高速化のための設定があるらしい。なんたって「Vista」で検索するだけでGoogleが「高速化」をサジェストしてくれる位・・・ディスクがりがりはどうやらファイル検索のインデクス作りのためにファイルシステムをなめているという事のようだ。今回入れたのはVista BusinessなのでAeroを切るというのは関係ない。
何をやったのか簡単にメモ。

・Windows Searchサービスをとめる
・ついでにいくつかサービスをとめる（SuperFetch, Telephony, Themes, あといくつか忘れた・・・）
・Readyboostを使う

結局この位だったのかな。Themesを停めたせいか、デスクトップの見栄えが多少味気なくなったが、軽くなったような気もする。
とりあえず少しは軽くなったようなので、officeはまた後で入れるとして、他に少しでも快適に作業できるように必要なものを入れて環境を整えていった。とりあえずは

・Firefox＆Flashなどのアドオン導入
・NTEmacs導入、apel, skk導入
・猫まねき導入

Firefoxはインストールせずにポータブル版にした。
NTEmacsは初めての導入。Windows上で使えるEmacsというのは何種類かあるようで、日本ではMeadowが有名らしい。Muleのころに始まって、Emacs本家のコードを取り込んだりコントリビュートしながら今現在も開発が進んでいる様子。
今回選んだNTEmacsは本家のコードをWindows用にコンパイルしたものらしい。多分。普段はLinux上で本家のEmacs22を使っているので、それとのギャップがなるべくないものということでNTEmacsを選んだ。そして、日本語入力のためにSKKとそれに必要なapel。
なんだか大変そうだなぁと思いきや、ドキュメントの指示に従っていたら案外簡単に導入できた。Windows上で真正Emacs+本物SKKが使えることにちょっと感動。いろいろやってくれている皆さんに感謝。しかもこれってUSBに入れて持ち歩いて使えそう。

さて、Emacsだけでは意味がない。Windowsマシンを触っていて一番イライラするのはキーマップ。
普段はLinuxのX上でxmodmapでキーマップを変更し日本語キーボードを英語配列で使っている。さらにEmacsでdefine-key関数でキーバインドを変え、SKKで無変換、変換キーを親指シフトっぽく使えるようにしたりバッファ操作を簡単なキー操作でできるようにしている。

これまでもWindows上ではkeyswapというフリーのツールでCtrlとCaps Locksだけは入れ替えていた。
しかし、":"や"@"や"*"など、主に右手小指あたりの記号類が日本語キーボードと英語キーボードでは細かく異なっている。この違いがWindows上での作業をイラつくものにさせている。
それもなんとかしたかった。

それでいろいろ探してみると、やはり良いツールがあった。
keyswapの他にもChange KeyやXKeymacsなど、「キーを交換」できるツールはいくつもあるが、上に上げた記号類など、Sfhit押下や非押下時の文字だけを変更することはできず、用を足さない。xmodmapのwindows版みたいなものはないのか・・・と諦めかけたところで「猫まねき」というツールに行き当たった。
早速試してみると、一部多分バグじゃないかと思われる動きがあったものの、ほぼ求めていたキーレイアウトにできた！
Emacsのキーバインド設定もそれに合わせて若干手直しし、ほとんどLinux上のEmacsと同じ感覚で日本語入力ができるようになった。これで文章を書くだけならVistaでもできるじゃん。

あとはEmacsのshell modeでbashが使えたり、Python入れてpython-modeが使えたり、そうそう、Mozartも使えるようにしたいなぁ・・・そうそうpLaTeXも・・・なんて思っていたら・・・・・・

一生懸命設定したノートが逝きました・・・
これはディスクじゃない、本体っぽい・・・
設定のメモなんかもまだ外に出してなかったのでパァ・・・
一通り終わったらUSBに退避しようと思っていたけど、その前に、こんなあっさり逝くとは・・・しかもHDDもどうやら駄目っぽい・・・ほんとか？・・・
気力を失ってまだちゃんと確かめていないけど

ということで、すべては徒労に・・・

CherryPy本も到着

2009-02-22T19:03:00.005+09:00

Scratch programming for teensと前後してあと数冊本が届いた。
まずは「CherryPy Essentials」。Pythonでウェブアプリを書くためのフレームワークであるCherryPyの本だ。これも随分待ってやっと到着という感じ。という事で少しずつ進めていきたい。いや、こういうのは一気にやるに限るかな…

もう一冊の本は積読になりそうだなぁ…こんなに厚くて重いとは思わなかった…
「Concepts, Techniques, and Models of Computer Programming」で、900ページ近い大部。
表紙のサグラダ・ファミリアからガウディ本とか頭文字からCTMとかCTMCPと呼ばれているらしい。SICPとしてお馴染のStructure and Interpretation of Computer Programsに比べられる事も多い名著のようだ。
SICPは学生時代に大変楽しく読んだので、これも読んでみたくなり発注しておいたのがやっと届いた次第です。
しかし時間あるかなぁ…

SICPと言えばScheme言語だが、CTMではMozart(Ozのサブセット？)を使っているようだ。これも昔触ってみた事があるが、こんな所で再会するとは思わなかった。その頃触ったことがあるものではOcamlが一番メジャーになったようだが、多分実験的なものとしてその後消えたものにLifeという言語があった。Ozも同系統だったような気がするし、もう消えたのかと思っていた。当時からEmacsを使ったインターフェイスがあったと思うが、普通にEmacsのメジャーモードとして作ってくれればいいと思うんだけど、何かちょっと特異な感じが...
まあ慣れるしかないか。
という訳で時間があれば、いや、そのエネルギーがあれば、少しずつ読みたい。

「Scratch programming for teens」が届いた

2009-02-22T18:46:00.014+09:00

発注してから結構経つが、数日前にやっと表題の本が届いた。
今のところScratchについては英書としてこの本、そして日本語のものはアイデアブック、これら二冊しかないようだ。他にも各国語の本は出ているのかもしれないけど。

まだパラパラとめくってみた程度だが、アイデアブックとは趣きがちょっと異なるようだ。
アイデアブックは第一章冒頭で「あなたが小学生、中学生なら」なんてメッセージがあるので、子供でも自分で読み進められる事を考えてあるのだろう。紙もスベスベの上質紙でカラー印刷だ。
for teensの方はペーパーバックの本としては普通の紙で、白黒印刷。
内容的にも、各命令ブロックの説明など、リファレンス的内容も含まれている。
アイデアブックではその中で使うものだけにしか触れていないようだった。最初の導入としては必要なものだけに絞って説明する方が分かりやすいと思うし、成功していると思う。
大体の事は実際にいじってみれば分かるとは言え、アイデアブックを一通り終えた後もう少し網羅的な説明が欲しくなった時に「for teens」があると丁度良さそうだ。そういう意味では良い順番で手元に届いてくれた。

それで、また少しScratchをいじっていたが、また引っ掛かった事があった。

命令を繰り返すためのブロックはいくつか用意されている。
最も単純なものは「forever (ずっと)」で、いわゆる無限ループ。
for文的な「repeat [n] ([n]回繰り返す)」もある。
他に「repeat until [condition] ([条件] まで繰り返す)」と「forever if [condition] (もし [条件] なら、ずっと)」だ。
良く分からないのはforever ifだ。

ブロックは上下に他のブロックを接続する事で上から下に順番に実行されるようになる。
repeat [n]のブロックはそのブロックの内側のブロックをn回実行し終えると、その下に接続されたブロックが実行される。まあ普通の事だ。
foreverは文字通り永久に繰り返されるようで、終わらない。
そのためだろう、foreverブロックの下には別のブロックは接続できないようになっている。

forever if ～(もし～ならずっと)は、条件が成り立っていればその間続けられる、のかと思ったら、違うようだ。
永遠に「もし～だったら…」というのを実行し続けるということらしい。
言われてみれば「forever if～」なら「if～」を永遠に続けるって事かなと思う。
だけど日本語判の「もし～ならずっと...」はやっぱりちょっと変じゃないかな。
初めにこの文を見た時には、一度だけ条件をチェックして、それが成りたっていれば後は永遠に繰り返し処理なのかと思った。

「forever if [x = 1] ...」は、疑似コード風に書くと


forever {
    if (x == 1) { ... }
}

となる。xが1ならば内容を実行するが、そうでなくなれば実行しなくなる。しかしまたxが1になったら実行する。Scratchでは色々なキャラ(スプライト)や背景のスクリプト辺が同時並列で動いているようで、別のスプライトなどが状態を変えるとそれに反応するということのようだ。
しかし日本語版の表記からはそういう内容を想像できなかった。
子供に使ってもらいたいものという事を考えると直した方が良いのではと思った。

ただ僕は時々自分でも自分の日本語感覚は変なのかもと思う事があるので自信なかったり...

SunbirdとThunderBirdでのGoogleカレンダーとの同期

2009-02-22T17:47:00.009+09:00

GoogleカレンダーとSunbirdの同期でSunbirdはオフラインではカレンダーを見る事ができないのか...と書きましたが、間違いでした。まだ正式ではないようですが(実験的となっています)、キャッシュ機能があり読めるようです。ネット上にも読めないとか読めるとか色々あるんですが、ちゃんとオフラインでも読めました。

画面左側のカレンダー一覧で目的のカレンダーをダブルクリック(右ボタンからプロパティ選択でも可)して表示されるダイアログに「キャッシュ(実験的、再起動が必要)」という項目があるのでこれにチェックを入れます。
これで無事にオフラインでもキャッシュされたカレンダーを見る事ができます。

ところが、ネット上の情報を漁っていると、オフラインでも変更ができるとあります。
が、いくら試してもそれはできませんでした。
追加に関しては、例えばSunbirdにはじめからあるHomeというローカルなカレンダーに追加しておき、オンライン時にカレンダー種類だけ変更することでまあ対応できなくはないかもしれませんが、削除はちょっと無理ですね。これもメモ的にHomeに書いておくくらいしかできなそうです。
ということで、ひょっとするとこれも本当はできるのかもしれませんが、色々試したり設定を探した限りでもできませんでした。

今のところのファイナルアンサー(ファイナルじゃないじゃん...)は、「キャッシュを有効にしておけばオフラインでも見られるけれど、変更はできない」です。

ところで、メールソフトのThunderBirdにLightningというアドオンを入れるとカレンダー機能が統合され、さらにprovider for google calendarというアドオンを入れればSunbird同様にGoogleカレンダーを利用できます。折角なのでこちらの方がいいかな。

設定についてはこちらのページが参考になります。

PyQt4アプリにてscimで日本語入力

2009-02-17T15:15:00.009+09:00

CherryPyの本が未だに届かないので、少しPyQt4を触ってみた。
PyQt4はC++で書かれたアプリケーション開発フレームワークであるQtのPythonラッパーだ。ちなみに開発元はTrolltechという会社だったが、Nokiaに買収されて社名が変わったらしい。アプリ開発用フレームワークと言っても、個人的にはGUIライブラリとしてしか認識していない。
さらに、Pythonのようなスクリプト言語で使えなければ触る気にはならないと思う。つまり目的はPythonでGUIを作ってみる事だ。

さて、環境は Debian GNU/Linux lennyで、Python2.5.2&PyQt4。
Python2.5.2ではユニコードを使えば日本語文字列も正規表現などでもちゃんと扱え、PyQt4のウィジェットにも表示できる。
早速二三サンプルを試してみたところ、ちゃんと日本語も表示できた。
しかし、日本語入力ができない。
普段Emacsの外のX環境で使っているのはscim-skkだが、ktermやFirefoxでは普通に日本語入力できているが、PyQt4アプリの上では入力できない。
ネット上を漁りながら適当に試していたところ、やっと入力できるようになった。

まず、 scim-bridge-client-qt4 というパッケージを入れる。
そして環境変数を QT_IM_MODULE=scim-bridge としておけば良いらしい。
もちろんscim自体のための環境変数設定 XMODIFIERS="@im=scim" はそのまま。

ということで日本語入力できるようになった。
考えてみたらまともなGUIアプリなんてMS-Windows上でVisual C++でちょっと書いてみた事があるだけで、Linux上では作っていない。はるか昔に、Sunのワークステーションでだったが、Xlib&Xtで作ろうとしてあまりの面倒くささにウンザリして止めたっけ...
せっかく良いライブラリが、しかもPythonから使えるので、一通りの事はできるようになっておきたい。

しかし日本語入力回りの仕組みはいまだに良く分からない。今回もscimとbridgeはどういう関係なのかピンと来ない。大抵はこんな感じで設定さえなんとかすれば使えるようになるので、いつまでもブラックボックスのまま。
まあ、何もかも知ろうとする訳にはいかないし、仕方ないか。。。

GoogleカレンダーとSunbirdの同期

2009-02-16T20:22:00.011+09:00

これまた最近になって、USBメモリに入れて持ち運べるポータブルなソフトウェアが広まりつつある事を知った。
例えばここやここにはそんなソフトウェアが集められている。
そこでFirefoxにもポータブル版がある事を知った。ポータブル版は、基本的にはインストールが必要なく(形だけインストール作業が必要だが、実際にはフォルダが作られるだけ)、フォルダをUSBメモリにコピーして持ち運べば、USBメモリから直接アプリケーションが起動できる。Firefoxは普段Linux上でも常用しているブラウザだが、MS-WIndows上でも使っている。ブックマークツールバーなどの設定がどこでも同じものが使えればいいなと思っていたのでこれは有り難い。しかも、どこかで共用マシンのブラウザを使ってうっかり何か情報を残してしまう事もなくなる。Gmailをチェックしてうっかりログアウトし忘れるような事があっても大丈夫だ。

他にも色々なソフトのポータブル版が存在する事に驚いた。
例えばPhotoshopに迫るとも言われるフォトレタッチソフトのGimpのポータブル版なんていうものもあった。Photoshopをそれほど使えるわけではないので実際にどれほどPhotoshopに迫るものなのかは分からないが、多分僕が使う程度の範囲であればその要求を充足するに十分なものだと思う。ちょうどPhotoshopの使い方をもう少し勉強しようかと思っていたところだが、やっぱりGimpにしようと思った。無料な上に持ち運んでどこでも使えるというのはとても便利だ。
これらをはじめ持ち歩けると便利そうなソフトをいくつか早速USBメモリに入れておいた。

そんなポータブルソフトの中に、Firefoxと同じくMozillaプロジェクトが開発しているスケジュール管理ソフトであるSunbirdもあった。SunbirdにはGoogleカレンダーと同期する機能もあると聞いていたので、一度は試しに使ってみようとは思っていたが、まだ触った事がなかった。Googleカレンダーは、ネット接続とブラウザさえあればどこでもスケジュール管理ができるので大変便利なんだが、時にはオフラインでチェックしたり入力したいという時もある。そんな時のためにオフラインソフトで同期できるものが欲しいと思っていたんだけど、さらにそれがポータブルという事になればそんなに有り難い事はない。

という訳で、Sunbirdポータブルを使ってみた。Firefox、Thunderbird、Sunbirdについてはちゃんと日本語版があった。
普通に起動すればOutlookなどと同じようなカレンダー形式の画面が出てくるので、その手のものを使った事があればすぐに使えそうだ。
とにかくGoogleカレンダーと同期できるようにしたい。

画面左側のペインの「カレンダーリスト」タブの中に、Homeというのがある。グーグルカレンダーのマイカレンダーに相当する部分のようで、初めはデフォルトのカレンダーとしてHomeというのがあるらしい。
そこで右ボタンを押すと「新しいカレンダー」というメニューがあるのでそれをクリックする。
すると「新しいカレンダー」というダイアログが表れるので、そこで「ネットワークのサーバに保存する」を選択して次へをクリック。
次の画面に「Googleカレンダー」という選択肢があるのでそれを選択し、「場所」としてXMLフィードのアドレスを入力して次へ。
このXMLフィードのアドレスというのは、グーグルカレンダーの設定画面の「カレンダー」でマイカレンダーの種類を選択すると下の方に出てくる「カレンダーのアドレス」という部分にある「XML」という四角いアイコンをクリックすると表示される「カレンダーのアドレス」というものだ。
次に、それに名前を付けるが、これはGoogleカレンダーで使っているものと同じにした方がいいだろう。
設定が終わるとSunbirdのカレンダーリストに新たなカレンダーが追加され、Googleカレンダーからデータを読み込んで自動的にSunbirdのカレンダーの中に予定が表示された。

これでSunbirdとGoogleカレンダーが同期されるようになり、オフライン環境でもMS-Windowsさえあればスケジュールをチェックしたり変更したりできる。
というわけで、さっそくSunbirdのフォルダもUSBメモリに入れておいた。

あとはケータイとも同期できればいいんだが...

ちなみに、ScratchもUSBメモリに入れてあり、持ち運んでどこでも使える。

追記:
書き忘れたが、Googleカレンダーとの同期にはSunbirdに「Provider for Google Calendar」というアドオンを入れる必要がある。「ツール-アドオン」メニューで表示されるアドオンダイアログで「新しい拡張機能を入手」をクリックすればSunbirdのアドオンのページにいくのでそこで検索すれば見付かる。

さらにとても重大な追記:
Sunbirdではオフラインではスケジュールを見ることはできませんでした...
すっかりキャッシュしてくれるものだと思い込んでました...
こうなると、ローカルインターフェイスとしての意味しかないからあんまり利用価値ないかなぁ。。。

とても重要な訂正(2009/2/22):
ローカルへのキャッシュできるようです。エントリーを改めて書きます。

「スクラッチアイデアブック」を一通りやってみた

2009-02-15T00:42:00.012+09:00

さて、前回手元に届いた表題の本に一通り目を通しながら、実際にScratchでスクリプトを組み実行してみた。
ピコボードというフィジカルなモノがないとできない部分は残念ながらやっていないけれど。

まず最初に言いたいのは、Squeakでは感じた良く分からない抵抗がほとんどなく、Scratchには非常にスムーズに取り組めた事だ。このあたり、SqueakからScratchに発展する過程で、僕には明確には分からない所で色々思案された成果が出ているんだろうなと思った。

本の方も非常にスンナリ読み進む事ができた。何箇所か説明されないものがあり、コレは何だろうと思う点があったけれど、全体的には非常に楽しく進められた。一般的なプログラミング言語の場合、タイポなど、まあ道具の扱いという意味では非常に根本的な問題ではあるけれど、プログラミングの本質(と言っても、問われても明確には答えられないが...)には関係ない部分で足をすくわれる事も多い。この本を一通りなぞる間にそういう経験はなかった。子供やPC操作に熟練していない一般的な人が取り組む時、実はこういう「些細な」点は非常に重要だと思う。

一通り終えて、日本語の最初の本としては非常に良い本が出たなと素直にそう思えた。
ただ、今のところ一冊だけ、英語の本を入れても二冊しかない状況を考えると、「ゼロからの入門」のさらにその先へ橋を架ける内容も欲しかった。残念ながら今後もScratchの本が続々と出てくる事は考え難いから。(ところで「ゼロから学ぶ…」という副題はfrom scratchに引っ掛けてあるんだろうか...なんて思ったり)

今回この本をなぞりながらネットで調べつつ日本語版Scratchを使ってみて初めて知った点や気付いた点、若干気になる点もあった。

まず、Scratchはスクリプトでインスタンスを作れないらしい。
プロトタイプベースというのだろうか、クラス定義からインスタンスを生成するのではなく、具体的なインスタンスを作り、それを人間の手動操作で複製してはじめて別のインスタンスを作れるらしい。
本の第5章「シューティングゲームを作る」のところで、複数の弾丸(ビーム)を同時に使うにはどうすればいいのか考えている時に調べて知った。

また、メソッド(スクリプト片)には名前が付けられないらしい。引数もない。返り値もない。
メッセージもブロードキャストされて、特定インスタンスだけに送るという事はできないようだ。
このあたり、オブジェクト指向プログラミングの基本概念を教える事が主目的の一つになっているらしいAliceとは大きく違うようだ。
まあ、大域変数(全スプライト用の変数)とメッセージを使えばメソッド呼び出しっぽい事はできるわけだけど。変数を使って基底のチェックさえしてやれば再帰のような事もできそうだし。新たなローカル変数が自動的に生成されるわけではないのでできないか...
なんて事を考えるのは無粋なんだろうと思う。

日本語版については、コマンドタイルの日本語の文章がしっくりこないところが何箇所かあった。
例えば、配列の要素の値を変更するコマンド、「replace item [1] of [xx] with [thing]」という、配列変数の要素への代入が、日本語版では「[1]番目([xx]の)を[もの]で置き換える」となっているが、これは普通に「[aa]の[1]番目の要素を[もの]で置き換える」の方が良いんじゃないだろうか。今のままだと日本語としても気持ちが悪い。「要素を」が入ると長過ぎるかもしれないので、それは無くても構わないけど。

本を一通りなぞった後に、タートルグラフィックスっぽい事をして遊んでみた。再帰の問題があるのでフラクタル画像なんかはあまりやりたくはないけれど、ちょっとした幾何学模様を描いて楽しむ事もできた。

色々いじりながら、Scratchのターゲットはどういう層で、その層が成長した時にはどうさせたいのだろうという疑問がふと浮かんできた。
「本格的」にプログラミングに取り組みたくなった人や、あるいはアニメーションやゲームを作りたくなった人、そういう人達はこの後なにをすればいいんだろう。
もしプログラミング教育の導入としてScratchが使われた場合、その後どう導いてやるんだろう。
今回色々いじりながら、「マウスでドラッグ&ドロップして気軽にプログラムが作れる」わけではなく、ちゃんと考えながらやらなければいけないのは良く分かったので、しっかりトレーニングにはなるのだろうとは思ったけれど。

何はともあれ、非常に楽しく取り組めた。

「スクラッチアイデアブック」

2009-02-08T23:37:00.004+09:00

というタイトルの和書が出た。サブタイトルは「ゼロから学ぶスクラッチプログラミング」。頭には「ゲームで遊ぶな、ゲームを作ろう！」とある。

前回書いたScratchに関する、日本人により日本語で書かれた初の入門書だ。別ルートで発注した英語の本の方はまだ届かないけれど、さすがAmazon、ポチった翌日には手元に届いた。素晴らしい。いや、騙され(るようにし)て継続中のAmazonプライムのお陰か...

まだパラパラとめくっただけだけど、「超簡単入門」からはじまって、シューティングゲームやロールプレイングゲーム作りなど、楽しみながらスムーズに進んでいけそうだ。プログラミングの導入教育の最初にこんなことをやってもいいんじゃないだろうか。
一般的なプログラミング言語を用いた教育では、特別に関心のある人以外は容易に挫折しそうだけれど、Scratchを使ったこんな授業ならそういう人も救われそうな気がする。
なにはともあれまずは自分で少しずつ読み進め、試してみたい。

Scratchというプログラミング環境

2009-01-31T22:29:00.013+09:00

さて、Scratchというプログラミング環境がある事を数カ月前に知った。
アラン・ケイが子供でもプログラミングを学べる環境を、と開発を主導してきた
Squeakから派生した発展形のようで、MITで開発しているらしい。
Squeakについってはかなり以前から知っていた。
もう何年も前だがNHKでもNYの小学校で使われているなんて事を紹介する番組が放送された記憶がある。
Squeakは現在どんなプログラミング言語でもその考え方を取り入れていると言われるオブジェクト指向の源流となった言語の一つだと言われる、Smalltalkというプログラミング言語の上に築かれた、一種のビジュアルプログラミング環境だ。
要するに、キーボードで英語の呪文のような命令を一文字ずつ打ち込むのではなく、タイルのような目に見える部品をマウスでドラッグして、まるで絵の世界のロボットでも組み立てるようにして、視覚的にプログラミングを組み立てるこのできる環境だ。正確に言うと、それはSqueakという環境の上に築かれたMorphとかe-toysという環境のことなわけなんだろうが、一般的にはそう受け止められているようだ。
要するに、難しげな英語っぽい命令を沢山覚えたりそれをキーボードで一文字ずつ打ったりせずに、マウス操作だけでもプログラムが書ける環境であるSqueakを、さらにユーザーフレンドリーにしたものがScratchだ、と言ってもそれほど間違っているとは言われないだろう。

以前から、これだけ「コンピュータ」と呼ばれるものが身の回りに溢れるようになったこの時代に、実は本当にコンピュータらしいものなんて全然ないんだと感じていた。コンピュータ雑誌なんて呼ばれるものはいくらでもあるけれど、本当に「コンピュータ」について語る雑誌なんて一冊もないじゃないか、と。もう10年位経つのだろうか、bit、とうい雑誌が「休刊」という名の廃刊になった。あれが唯一の「コンピュータ」の雑誌だったのに…
「本屋」が無くなって「雑誌・新書屋」ばかりになったとの似ている。

今の「コンピュータ」なんて、ビデオレコーダーとほとんど同じだ。誰かが作ってくれたものを、そう使うように決められた方法を「学んで」、その通りに操作するだけ。
このどこに「コンピュータ」の本質がある。
universal turing machineの有限近似たるコンピュータは、今、これだけの種族の繁栄を見ながらも、きっと心の底は虚しさが渦巻いていることだろう。

SqueakやScratchを開発する心の底には、こんな虚栄を、きっとこんな虚しさを、ぱっと見この世の春を謳歌するコンピュータに、本当の生き甲斐を与えたいという思いがあるんじゃないだろうか。
子供でもプログラミングできる、そしてコンピュータに対しては素人である、ほとんど全ての大人にもプログラミングできる、すなわち、「コンピュータ」と呼ばれる家電製品を、正しくコンピュータたらしめるためにそのuniversatilyを引き出すための道具としてSqueakやScratchを開発しているんじゃないかと思う。

酒が入っているのでなんだか良く分からなくなってきたが、要するに、CだのC++だのC#だのJavaだのLispだのPrologだのMLだのPythonだのPerlだのRubyだのActionScriptだのJavaScriptだの…、呪文のようなプログラミング言語を自分の指で一文字ずつタイピングせずとも、アイコンのような部品をマウスでドラッグ&ドロップすることでプログラムを組み上げていくことのできる環境が、Scratchです。まだSqueakの情報量には及ばないけれど、英語の本は一冊出てきました。いずれここで報告したい。
小中高で、教える先生が「何をすればいいか分からない」から、とりあえずネットで調べてパワポでプレゼン作って発表会させる、なんて授業をする位なら、こんな環境でコンピュータに自分の気持を伝え、それを実行してもらう経験をしてもらえたらいいなぁ、と思った。
コンピュータは、気持を正確に伝えることさえできれば何でもしてくれる、万能機械なんだから。

SKKIMEとは、SKKとは

2009-01-25T15:37:00.017+09:00

ところでSKKIMEと言っても知らない人が多そうなので少しだけ説明。

名前から分かる通りMS-Windowsのための日本語入力メソッドの一つです。
Windowsに初めからついてくるMS-IMEや、ジャストシステムのATOKなどの一般的なIMEとはちょっと変換の方法が違います。
元々はEmacsという、現在も主にunix系OSで広く使われている(ひょっとして、「いた」、になっちゃった？)テキストエディタで利用するために、Emacsの組み込み拡張言語Emacs Lispで実装されたものでした。unix系では早くからEmacsを飛び出してX-Window環境全般でSKK風に日本語入力ができるようになっていました。
それで、MS-IMEが嫌になってウィンドウズでもそれを使いたいなぁと思っていた時に見付けたのがSKKIMEでした。
つまりSKK風の日本語入力・変換をウィンドウズで可能にしてくれるIMEです。

SKKでは、平仮名入力モードで「aiueo」と打つとそのまま「あいうえお」と確定した平仮名が入力されます。余分なEnter押下は必要ありません。
「愛飢え男」と入力したい場合には、「Ai[space]UEO[space]」という感じに打ちます。
ふだんは平仮名が確定入力され、漢字などに変換したい時にはその初めを大文字で打つという感じです。送り仮名などがある場合には「KannJidesu」のように漢字(変換が必要な部分)と平仮名(変換が不要の部分)の区切りを大文字で入力します。ちょうど手書きのような感覚と表現される事が多いです。
もちろん変換候補が複数ある場合にはスペースキーを何度か押すなどして候補を選択します。

もし変換したい漢字が辞書に登録されていないと、そのまま辞書への登録モードになります。
辞書登録が文章入力とシームレスになっているので、辞書登録画面を出して…のような面倒なことなく非常に楽に辞書を育てる事ができます。
まあ、連文節変換とか前後の文脈を読んで変換するというような「賢い」ことはしてくれません。まさに手書きの感覚なので。しかし「小賢しい」ことばかりされてイライラすることもなく、大変快適に入力できます。

ただ、大文字を入力する事が多いのでシフトキーを多用、つまり小指を酷使するのがちょっと大変です。
Linux上で常用しているEmacsではキーバインドをいじって日本語キーボードの「無変換」「変換」キーを利用しているので、疑似親指変換の気分で快適に入力できるんですが…
この辺はウィンドウズでもなんとかなるかもしれないのでそのうち調べよう。

そうそう、SKKを手放せない大きな理由の一つが、カタカナ英語の変換です。
例えば、「ディスプレイ」のようなカタカナ英語は非常に多いわけですが、これを読み入力するのはとても面倒で、嫌いです。
SKKでは「/display[space]」と打てば変換できます。つまり英語の綴りをそのまま入力すれば変換できるのでとても自然に楽にカタカナ英語を入力することができます。
その他にも補完入力など必要な時にだけ利用できる小賢しくない便利な機能があり、文章書きという大変基本的な作業のための基本の基本ツールとして手放せないものになっています。

ということで、気になった人はぜひ試してみて下さい。オススメ

SSKIMEのインストールと設定

2009-01-25T14:38:00.024+09:00

GAEやウェブアプリ作ってみたいなと思ったのも、仕事的にちょうど区切りが良い時期になったからだ。
それで母艦のPCや若干ごちゃごちゃしてきていたバックアップなどを整理して、資料やメール環境なども整理していた。
Windows環境も綺麗にしてキーマップの入れ替えなどもしてみた。常用しているツール群は過去にダウンロードしたものを保存してあったので問題ない、はずだったんだけど、最近ずっと使っていたSKKIMEだけはファイルが見付からなかった。
なのでググってみたもののあまりヒットしないんですね。まあ、ユーザー少なそうだし。ひょっとしてもう死んでしまったのかと思いつつ探し続けると幸いこれまで使っていたバージョン1.0系だけではなく1.5系が存在する事が分かって一安心。

さっそくインストールして使ってみた。
XPを使っているのでSKKIMEの開発者さんのページから1.5のXP用をダウンロードして展開。展開してできたフォルダにあるSKKI1_5U_WXPファイルの上で右クリックし、プルダウンメニューから「インストール」を選択してインストール。
これで言語バーにSKKIMEの選択肢が追加された。

続いて辞書の設定。
まずはここから辞書ファイルSKK-JISYO.Lをダウンロード。gzipで圧縮してあったのでこれも展開し、圧縮を解いた辞書ファイルを自分の好きな場所に置く。
そして言語バーの上で右クリックしてメニューから「設定...」を選択して「テキストサービスと入力言語」ダイアログを表示。

その「設定」タブ内でSKKIME ver.1.5を選択した上で右側にある「プロパティ」ボタンを押してSKKIMEのプロパティダイアログを表示させる。

その「辞書設定」タブで辞書ファイルを指定。ひょっとして既に動いてるSKKに知らせる必要があるのかも知れないのでついでに「同期」ボタンも押しておいた。
これで言語バーから「SKK IME Unicode Edition」を選択すればSKK IMEが使える。

フレームワーク選び

2009-01-25T14:14:00.007+09:00

GAEに興味を持った理由はやはりGoogleのBigTableなどのバックエンドを使ってみたいと思ったのと、現在自由になるglobal IPを持ったマシンがないためで、何かウェブアプリを作ってもそれを外から使えないなぁと思っていたからだった。
金銭的なコストなしに簡単に誰にでもアクセスできる場所で自分で作ったものを動かす事ができるのは魅力的だよね。

でも、細かい事はこれから勉強していくとして、でもやっぱり色々制限があるだろうわけで、できれば自分で自由な環境を選んでウェブアプリ作りたいなぁとも思ったり。

それで色々耳にする事が増えたウェブアプリ用のフレームワークを探してみる事にした。GAEもPythonだしとりあえずPythonのものを探してみたけど、いろいろあるんだね。
RubyだとRailsってのが一番有名なのかな。
PythonだとZopeの子孫？のPloneや、一番人気のDjango、元気がありそうなTurboGears、新進気鋭？のPylons、さらには身軽そうなCherryPyやweb.pyなど。
できれば手軽なものが良いなぁと思うので、Pythonさえインストールされていればどこでも稼動して、ほとんど通常のPythonプログラムの感覚で開発できるというCherryPyに特に興味を持った。多機能さや今後の発展性を考えるとPylonsなのかなと思いつつ。
ただ、一番人気のDjangoは文献も多く日本語のものもあったり、またGAEとの関係も深いようでちょっと気になる。
PylonsはRuby on Railsとの関係も深いらしくてちょっと気になる。CherryPyでなければこれかな。
あれこれ欲張っても仕方ないし、とりあえずは手軽そうなCherryPyにする。

もう10年位前だろうか、ウェブブラウザが日常的なツールになってきたころ、面倒なGUIを作るかわりにウェブブラウザをインターフェイスにしようなんてことが増えた時期があったと思うけど、今やりたいのも実際にはその程度の事だし、まずはCherryPyで十分そう。
認証機能も提供されてないってのがちょっと不安だけど、まあ基本はスタンドアロンなCUIプログラムを作ってそのインターフェイスにしたい程度なのでとりあえず問題はない。
それ以上のことをやりたくなってCherryPyでは厳しそうだったらPylonsにでも移行しよう。

GAEの参考文献

2009-01-24T15:44:00.004+09:00

さて、これからGAEを試していくわけだが、基本的にはGoogleから提供されているヘルプなどの文書を読みながやっていく事になる。
が、できればもっとフレンドリーな参考文献はないのかなと。
Googleのヘルプって、結局知りたい事が分からない事多いような気がするんだよね…
まあ、Gmailとかカレンダーとかの話だけど。

それでさっそくamazon.co.jpとamacon.comで探してみたところ、もうすぐ一冊、6月頃にもう一冊GAEの本が出るらしい。
つまり現時点ではまだ出てないってことね…
"Google Apps ..."なんてのは色々あるけど、これは別物だよね。
一冊目、19.99ドルのものが日本円で2200ということなので、大人しくco.jpでショッピングカートに入れておきました。

Google App Engineをはじめてみたい

2009-01-24T15:28:00.003+09:00

ブログを作って半年放置してから、そういや作ったと思い出した...

というわけで、当初の目的どおり、このブログはメモ的に使っていこうと思う。
これまでいろんなメモをPC上に作成したり溜めたりしてきたが、時間とともに整理がつかなくなり、価値を失う事が多かった。
それでいっそブログにメモってアチラさんに保管をまかせて検索などの諸機能もお願いしてしまうことにした次第。
実際そんなメモ程度のものでも助けになってくれるブログは結構あって、ちょっと忘れてしまった事や自分でちゃんと調べるのが面倒な事をチェックするのに役立っていることだし。

ということで、まずはGoogle App Engineを使いながら導入方法などをメモっていこうと思う。
"Google App Engine"でフレーズ検索してみても、(少なくとも日本語の情報は)あまりみつからない事だし。

という訳で、今日はとりあえずのとりあえずで、GAEのアカウントを作ることにした。
が、すでにGmailやGoogle Groupなどを使っていてそちらのアカウントがあったのでそれで良かったらしい。
GAE公開当初は先着何名様とかだったと聞いたので、別アカウントかと思っていた。
結局パスワードの再入力と二三クリックしながら携帯メールで本人確認コードを送ってもらい、それを入力することでGAEを開始できるようになった、らしい。

というわけで(←これ多いね)、とりあえずSDKをダウンロードした。
基本的には Linux 上で作業する積りなのでLinux用を、そしてついでなのでMS-Windows用も。
Python2.5が必要とのことだが、既に入れてあるので問題なし。
サーバのエミュレータがＰｙｔｈｏｎ2.5で書かれているらしい。
そしてそもそもGAEの使用言語がPythonということなので。
この点も、興味を引くものは幾つもあれど、GAEを実際に使ってみることにした理由の一つ。

とりあえず

2008-07-30T14:03:00.002+09:00

ブロブことはじめ。

とりあえずはじめてみる。