Debian on ThinkPad のための雑記録. 作成中というか記録中.
PowerBook US キーボード. uControl というフリーウェアによって, caps lock と ctrl の位置を入れかえているが, 何かのタイミングで ctrl(元 caps lock) がロックされてしまう. スリープ復帰時はよく起きるが, これは仕方ないとして, 他の条件がまだ見つからない.
後は, US キーボードでは, チルダが左上角, バックスラッシュ兼パイプ(縦棒)が右上 delte の下, にあるのはややびっくり. まだ手がなじまない.
その他. X11 下でどう設定するのが一番相性が良いのだろうか.
Mac OS X PowerBook Note. とりあえずまだ移行しきってないのでこのページに書きつづける.
iTunes + iPod は Apple らしく, 良く作られたシステムだ. CD を購入して, PowerBook に差しこむと iTunes が起動する. 読み込みボタンを押すだけで ディスクへ取りこまれる. あとは iPod をつないでやるだけでいい. iPod への転送が非常に高速なのも良い.
スマートプレイリストは, ルールベースの楽曲分類で, シンプルなルールを組みあわせることで, 面白いものを作れる. 特に, 自分で設定したレーティングをルールに含められるのが実に良い. 自分で五つ星を付けた楽曲のセットなどを聴いていると, なんとも言えない, 贅沢な気分になる.
惜しむらくは, PowerBook のスピーカーはやや貧弱. iPod のヘッドフォンに劣る感じがある. 駅からの帰り道を iPod を聴きながら帰宅, PowerBook をスリープから解除して iPod をドックにさっと差して充電しながら, より良いスピーカーで聴く, というのが理想か. まあ iPod と iTunes の同期中は再生できないと思うが, 小さくて良いのでスピーカーが欲しいところ.
emacs dired の問題. LANG などの環境変数が, ja_JP.ujis などの場合, まともに動作しない場合がある. で, 素朴に Dired モードの hook に setenv など追加すると, 今度は emacs-w3m が 文字化けしたりする.
仕方が無いので, dired-before-readin-hook と w3m-load-hook, w3m-mode-hook, w3m-display-hook で LANG, LC_ALL, LC_CTYPE の設定(setenv を利用)をするようにした. なお, w3m-display-hook は引数付きで呼ばれる hook なので注意. '(lambda () (setenv ...)) ではなく, '(lambda (url) (setenv ...)) とする. もちろん, 本質的な解決にはなっていない...
自由にならない環境, root どころか自分のホームディレクトリももらえない環境の下でも emacs をインストールして闘うあなたのための覚え書き.
Wanderlust の設定ファイルをホームディレクトリ以外に置く場合には, 以下を設定. まだあるかもしれないけど. 括弧内はデフォルト.
elmo-localdir-folder-path (~/Mail), wl-init-file (~/.wl), wl-folders-file (~/.folders), wl-temporary-file-directory (~/tmp), wl-score-files-directory (~/.elmo), wl-address-file (~/.addresses), wl-alias-file (~/.im/Aliases), wl-x-face-file (~/.xface).
Lisp 周辺の色々なものに興味が湧くようになった. だいぶ以前, elisp による elserv (http://elserv.sourceforge.net/index.ja.html) を見たときは, わたしはなんとも愚かにも, 単に elisp ハッカーのてなぐさみだと感じていたのだった. Common Lisp による Web Application Server, Allegro Serve のチュートリアルを見て (http://opensource.franz.com/aserve/aserve-dist/doc/tutorial.html), 認識を改めた. 高度なものを学ばなければ, そうでないものの制限にすら気付かない, というのは本当のようだ.
Apache では, 設定ファイル(XML) とファイルの階層構造で Website を管理する. ファイルの操作はシェル, つまり Web Server の外部で行う. Allegro Serve の場合, Web Server 自身が lisp で書かれているために, より動的で, 自由な処理が行なえる. たとえば, コンテンツの公開が, publish する, という手続きとして抽象化されているようだ. publish する対象は, 静的ファイルでも関数でも(当然無名関数でも)良く, 動的に実行できる, ようである.
あまりに面白そうなので, 近々無料のセミナーに参加する予定.
Lisp のマクロについて, elisp を書きながら学んでいる.
わたしには, いまだ, マクロを使う場所と関数で良い場所との区別が曖昧だ. ただ, 同じ処理を関数で書いたりマクロで書いたり, また元に戻したりしているうちに, マクロによってコード量を減らす事は, コードをより簡潔に, そして抽象化する意味合いがある, ということが分かってきた. 普通の言語では, せいぜいクラス化で抽象化するが, マクロなら, 構文自体を変更して抽象化できる.
わたしが作るような小さな規模のプログラムでは, なかなかマクロが使える場所が無い, というのも 正しいようではあるが, どこかマクロを使ってやれるところは無いか, と目をこらしていると, 結構コードが重複していたり, 抽象化がなされていなかったりすることに気付く.
もう少し(沢山, かも)訓練を積めば, 自然にマクロを使うべきところが浮かびあがってくるようになるに違いない, と 思うと楽しみだ.
Lisp のクロージャーについて, なんとなく分かった気分になったのでリンクをまとめておく.
「プログラミング言語 SCHEME」 では, 2.9 節, および 3.5 節「内部定義」でもモジュール化の方法として「さらり」 と書かれていて, ずっと引っかかっていた. Schemer には当然の代物, なのだろうか. R5RS の Primitive expression types の Procedures の説明の所に以下のように書かれてある.
A lambda expression evaluates to a procedure. The environment in effect when the lambda expression was evaluated is remembered as part of the procedure.
簡潔... さすが... 「ANSI Common Lisp」 6.5 節も分かりやすい. いわく, 「関数と環境を一緒にしたもの」.
Web 上では, (Scheme)(Lisp) の「クロージャの使い方」が簡潔で, 素晴しい説明. Common Lisp 入門 も分かりやすくクロージャについて説明してくれている. そして なんでもλ にも関数についての説明のなかで書かれている.
この, 関数と呼ばれる環境, という概念をはっきり理解しておくと, 継続ももっとすっきり頭に入る, はず.
なお, elisp の info によれば, elisp に 「クロージャーは無い」 .
追記. Debian なのでとりあえず GNU clisp をインストール. (C-u) M-x run-lisp で起動.
しばらく前から考えていた elisp.
日誌は物を作る人間にとって必要不可欠なものなので, ちゃんと書く必要がある. 日々の日誌を, 週や月の単位でまとめなおすと, 単なる作業記録から, より価値のある情報に生まれかわる. わたし自身は大分前から planner.el を日誌がわりに使用しているため, (さぼっていなければ)日毎にファイルができているわけである. この日誌のまとめ作業では, 複数のファイルを容易に参照しつつ, まとめファイルに記述できると嬉しい.
別の問題. planner emacs-wiki では簡単にハイパーリンクを生成できる. しかし, 素朴にハイパーリンクを辿っていると, 元のバッファが隠れてしまい, 自分の作ったリンク間でさえ迷子になってしまう. emacs-wiki のファイル内のハイパーリンクを別の場所に表示し, ハイパーリンク先の内容は別バッファに出せると, 迷子にならずに 関連する情報を眺められて嬉しい.
多分上の二つは同じ elisp で実現できるだろうと思い, pebble.el というものをでっちあげた. 当然まだ「アルファ版」なので注意. 日々更新.
pebble.el は, 画面をメインとサブに分割し, さらにそれぞれに インデックスを表示する領域を付け, 全体を四分割する. メインインデックスは planner のファイルリストを表示し, 移動キーでメイン画面に表示する内容を選択できる. サブインデックスは, メイン画面の内容が含むハイパーリンクを表示し, 同じく移動キーでサブ画面に表示する内容を選択できる.
追記. サブインデックスには, メインのファイルからのハイパーリンクの他に, 特定のバッファやファイルを入れられるようにする予定. ハイパーリンクは単に URL の場合もあるが, 素朴に emacs-w3m を呼びだすと, 同時に w3m を起動してしまって まずい場合があることが判明. うーむ.
HTML に PHP のロジックを埋めこむのは, ちょっと複雑なページを複数作ろうとするとすぐに破綻するので, 部品化する. 一般的に HTML のような文字列を生成する際, 関数の戻り値を単なる文字列にせず, 木構造にすると 良いようなので PHP でもやってみた (http://www.shiro.dreamhost.com/scheme/gauche/man/gauche-refj_305.html).
葉は入れ子になった木構造か, 文字列である. PHP では, array を容易に作成でき, その要素は「何でも」良いので, 入れ子にして木を簡単に表現できる. 速度的な面は未調査だが, 文字列を延々と結合する記述よりは, 木という構造を持たせたほうが読みやすいソースになるようだ. array(List) が簡単に書けるのは最近の言語の良い特徴だと思う.
Lisp に思いをはせながら List をがんがん作成する日々だ.
追記. 「きっと早いに違いない」と思っていたが, 実験したところ予想に反して遅いようだ. 実際上は他のファクターが大きいのでほとんど気にすることは無いが, PHP の文字列連結が高速なのか, array が遅いのか, 使い方が悪いのか. 実装に依存する話だとはおもうが, まずは scheme で本当に早いか試してみよう.
プログラミング言語は色々あるが, 最近仕事で使っている PHP について. 以下雑感. 長所はシンプルな Perl とでも言うべきその簡単さである. 宣言無しに変数を使えること, POST/GET のパラメータを何も考えずに 簡単に使えること, などは, 素晴しいことだ. データベースとの接続も(一応)容易なので, プロトタイピングには向いている.
しかし, 仕事で使うにあたっては, 実にストレスの溜まる言語である.
まず, 言語の能力として, 開発中にエラーが発生してもそのエラー内容が分かりにくく, デバッグに無用の時間がかかる. またその玩具的 OO 拡張は, あまりコーディングの際の負担を 減らしてはくれないので, 実用上の意味が薄い. PHP ではクラスによる部品化は, あまり期待できない. エラーハンドリングも不十分であるため, 堅牢なコードを書くには自分で注意しなくてはならない. 公式のドキュメントが貧弱な点も不満点である. 仕事で調べものをするのに Google だけで情報を得たくはないのだ. 公式のライブラリも, ドキュメントを調べてもエラーになるので ソースを調べるとあるはずの機能が実装されていなかったりする, ので 一々注意を払わなくてはならない.
個人的には, 「HTML にちょっとしたロジックを埋めこめる機能」 というのは, JSP だろうが PHP だろうが ASP だろうが PSP だろうが, ある程度の規模の開発ではあまり意味が無いと思う. そもそもの HTML がけっして良い言語ではないので, そのプレゼンテーションを簡単に利用できたところで嬉しくはないのだ.
wiliki.scm 学習の続き.
Gauche では parameter なる手続きのように利用できるクラスがあり, グローバル変数のかわりに使用できる. info の説明が簡潔で分かりやすい. なんとなく Scheme らしいと感じる代物. Object 指向と関連している ?
wiliki.scm では, wiliki や db が parameter で, (wiliki) や (db) などと多用される. wiliki の方は wiliki.cgi で作成された wiliki クラスのインスタンス? が, wiliki-main に渡され, parameterize される. db の方は wiliki-main で使用する with-db 手続きの中で parameterize されている様子.
追記. WiLiKi:アプリケーションを参照. ここらの情報を使うと, 簡単に WiLiKi から静的ファイルを生成できる, と思う. ただし, 上記の parameter がくせもので, wiliki モジュール内でグローバルなので, 外から wiliki.scm はやや使いにくい気がする. Gauche 流のモジュール, オブジェクト拡張部分が全く分かっていないせい, という気もとてもする.
format-page は, HTML のツリー構造を作る. cgi-main を良く読まないと分からないが, とりあえず text/tree モジュールの write-tree で HTML として出力できた.
TODO: WikiName の処理部分. そりゃあ静的ファイルにするつもりなので, リンクを変更しなくてはならないのだが, 日本語の WikiName がある.
雑感. 手続き内の手続きとか, named let とか, map とか, 抽象化とか, 変数名の付けかただとか, を本当のソースで見るのはなかなか勉強になる. もうちょっと前提知識があればなお楽に読めるはず.
追記の追記. パラメーターを使わないようにして中身を追うことで, WikiName を作っているところが判明. format-wiki-name, wikiname-anchor と url-local と %url-format-local. このなかで WikiName を cgi へのパラメータとして渡すハイパーリンクを作っている. 従って, ここをいじると静的ファイルに出力してもリンクを保持できそう.
wiliki.scm 続き. ちょっと以下の用語は不正確なので注意. だいたい何をやっているかは分かってきた.
まず dbm-open 手続きで自分の dbm ファイルを開き, dbm クラスのインスタンス(?)を取得する. wiliki.scm の wdb-get 手続きによって, 特定の wikiname を page クラスのインスタンス(?)として取りだすことができる. page クラスのアクセサを用いると中身を取りだすことができる. format-content 手続きによって, page を HTML の部分に変換できる. format-page は, html-page 手続きを用いて, content-type やタイトルや編集ボタンなどのおまけを HTML に付けくわえる.
Gauche(0.7) で書かれた Wiki clone, WiLiki (0.3)を導入した.
WiLiKi は, Gauche のライブラリ wiliki.scm と, 実行用の Scheme スクリプト wiliki.cgi と, Wiki ページの格納されるデータファイルから成る. gdbm は, データベースというより Gauche の info に説明されているとおり単なる永続的ハッシュ, という感じのもの. Gauche ではデータベース層が抽象化されているので, 簡単にアクセスできる. WiLiKi では, キーが Wiki Name で, 値がコンテンツとなっているようである. このコンテンツを, page なるクラスで処理しているようす. ただし, まだ Gauche のオブジェクト拡張部分をまったく理解していないのでかなり怪しい.
Gauche も WiLiKi も普通はインストールは容易のはずだが, わたしの環境では多少ひっかかったので記録しておく. gdbm を使用するには Gauche コンパイル時に, libgdbmg1-dev が必要であるが, 素の Woody では, 依存関係がおかしくインストールできなかった. Testing の sarge からファイルを借りてくることで 対応できた. config.log を見ると良い. Gauche/WiLiKi はとても配布に気を使ってくれているので, make test などをちゃんと行なってみること. ファイルとして /プレフィックス/share/gauche/バージョン/lib/dbm/gdbm.scm などが出来ていれば 問題無い. わたしの環境では gdbm.scm と odbm.scm が作られている. WiLiKi のインストール時にも, make test によって確認できる. WiLiKi も普通の cgi と変わらないので, 直接 wiliki.cgi を実行して動作を見ても良い. なお, WiLiKi が使用している cgi.scm はとても親切なので, 直接実行するとインタラクティブにパラメータを渡すことができる.
特別企画 「使って遊ぶ! Gauche による Scheme スクリプトプログラミング」, UNIX USER 2003/7 より.
この文章自体がとても面白い Scheme の文書なのだが, Lisper のスタイルが少しかいま見える点でも とても面白い.
わたしは Emacs を使って随分になるし, elisp の編集も M-x run-scheme による Scheme プログラム編集も 少しはやっていた積もりだったが, まったく使いこなせていなかった.
この最強の Lisp 編集環境である Emacs を, 色付けとインデントと f1 キーによる便利なヘルプ, M-tab による便利な補完, edebug によるデバッグ, ぐらいしか使いこなせていなかった. これだけでも十分便利なのだが, その S 式認識能力の利用がまったく足りなかったのである.
特に, 地味ではあるが, C-M-SPC (mark-sexp) で S 式をまるごとマークして, C-M-\ (indent-region) むちゃくちゃ便利だ. (ちなみに M-x run-scheme で C-x C-e (scheme-send-last-sexp) がとても便利に使えることすら知らなかった もちろん elisp mode では使っていたけど).
なんというか, Lisp に少しなれていた積りが, その Lisp 故の編集スタイルが 身についていなかった. タッチタイプ(+SKK) が自然な文章執筆にもはや欠かせないように, Lisp 用のショートカットを自在に使いこなせるようにならなければなるまい. 真の Lisper への道はまだまだ険しいのである.
ある対話的なプログラムを使用することになった. このプログラムは FTP クライアントに似たインターフェースを持ち, コマンドによってさまざまな処理を行なうことができる. しかし, このプログラムは引数をまったく取らず, 手でコマンドを打ち込む以外のことが出来なかった.
幸い標準入力は受けつけたので, まず Here Documents を使用した bash script のラッパーを書いた. これによって, 手入力処理が無くなり, また script への引数によって処理が変わるため 使いやすくなった.
次に, コマンドの処理結果を整形するためフィルタを書いた. フィルタとしてはごく単純で, 標準入力から 1行ずつ読み込み, あるキーワードが見つかったら処理を開始し, また別のキーワードが見つかったら処理を終える, というもので良い. 最初はフィルタのスクリプトを別ファイルに書いて, 先のコマンドのラッパーとなる script とパイプによって結合し処理を行なわせた. これは私がパイプ処理に捕われすぎて勘違いしていた所で, 処理をシェル関数に分割すればスクリプトのファイルは一つで良い. フィルタとして再利用できるほどの内容ではなかったため, そのように修正した.
このフィルタでは, 組み込みコマンドの read で 読み込み, echo コマンドと grep コマンドを使ってキーワードの処理を行なった. この方法は, 耐えられないほどではないが高速ではなかったので, フィルタ部分を awk を使って書きなおした. 本来は one-liner(気の利いた一節, の意だが awk では一行で書かれた洒落た処理)として すぐに書くところだが, 一旦はファイルにし, 結局は shell script に組み入れた.
実際には, わたしは元の対話的プログラムにそれほどの不満は感じておらず, なかばトレーニングのつもりで上記のような処理をする script を書いた. しかし, できあがってみるとその script による自動化の効果に自分で驚いた. たとえ少しのコスト--プロンプトに拘束されて手入力を行うコスト-- でも, 自動化されてほとんど0のコストとは, まったく意味が違う.
優れた小冊子である「UNIX という考え方」(Mike Gancarz, 芳尾訳)を読み返し, その正しさを再確認した.
elisp での Unit Test に関して調べてみた. あまり情報が無いのが不思議ではあるが, 以下の情報を見つけた.
http://www.emacswiki.org/cgi-bin/wiki.pl?UnitTesting
eval-when-compile macro を使うと コンパイル時のみ評価されて良いらしい, なるほど, と思っていたが, その定義をみてうなってしまった. ともかく自分がまだ lisp の評価の仕組, そして macro を理解していないことだけは分かったが.
こんにちは bash(GNU Bourne-Again SHell 2.05b). 今迄ディレクトリ移動の際の bash の補完動作がどうしても気にいらなかったが, man コマンドで調べて解決した.
~/.inputrc に,
set show-all-if-ambiguous on set visible-stats on set bell-style visible
を追加. これによって, 補完のたびにベルなどならず(bell-style), 補完候補が複数個あった場合にすぐに全部表示され(show-all-if-ambiguous), 補完時にコマンドかディレクトリか見て分かる(visible-stats).
なお tcsh では set matchbeep = nomatch, set autolist としていた.
ついでだが ~/.bashrc に,
set -o ignoreeof complete -d cd complete -d pushd
などを追加.
仕事で shell プログラムを多用することになりそうなので, これを機会に tcsh からプログラムに適している sh 系の bash に乗りかえようと思う. zsh はもう少し先, まずは bash になれてから考える.
alias の移植. もちろん環境変数も. まあプロンプトさえ替えてしまえば気分的にはなにも変わらない, と 自分に言い聞かせて頑張ろう.
仕事先で HHK US キーボードを与えられて数日. かたかたと結構うるさいが, 決して悪くはない. 確かに机の上が広い.
ところでわたしは US キーボードを本格的に使うのは始めてである. 自分で思っていたよりはタッチタイプをやっていたようで, 無意識的にクォートや括弧やチルダ記号を打つたびに混乱する. この際 US 配列に統一してしまいたい. 例えば, 「:」 を打つのに Shift キーが必要なことが, 「:」 が特別な意味を持つ vi エディタに良く馴染んでいる, と思う.
HHK 自体に関して. 矢印キーを打つたび fn キーを押す. 心のなかでプロが矢印キーなんて使ってちゃだめだ, と自分を責めるのであるが. (Web ブラウザの URL 入力欄など矢印キーが仕方がないときもある, と書こうとして, 念のため試してみると普通に Ctrl-b, Ctrl-f, Ctrl-a, Ctrl-e で移動できてしまった. 知らなかった, やっぱり矢印なんていらないかも.) まあカスタマイズできるのだろうが, emacs 使いとしてはやや 辛い位置に alt キーがある. emacs では f1 キーも多用するが, fn キーを押さないといけない.
HHK の元となった共同研究を行なった和田氏(http://member.wide.ad.jp/~wada/index-j.html) は, やはり lisper であった.
Emacs-wiki に張れるインラインイメージ, 以前使ってみたような気もするが忘却していた. せっかく最新の画像の使える emacs なので, 使わない手はない, か?
meadow では, 自作の elisp がちゃんと動かないことが発覚. マーカーの行の内容を minibuffer に表示する regadhoc.el は, minibuffer の大きさが変化しない? meadow ではあまり役に立たない. emacs-wiki.el はどこかで拾った advice か何かで動作するようになったのだが, planner-browser.el は, いくかの地味だが便利な関数が無いため, 数行削る必要がある.
立派な elisper への道はあまりにも遠い. planner-browser のプロジェクト切替機能も何だかイマイチさが露呈. ちゃんと調べよう. それしかない.
いまさらながら, だが, PHP(PHP: Hypertext Preprocessor)(http://www.php.net/) を(再)学習. 勿論 debian なので簡単に環境を構築できる. php4, php4-cgi, php4-ming, php4-pgsql, phpdoc を apt-get で入手した.
公式サイトの情報(FAQ など), メーリングリスト(http://www.php.gr.jp/), 有用な Web サイト(http://www.php-j.com/, http://www.pat.hi-ho.ne.jp/dimension/), 書籍, 雑誌記事を軽く参照し, 最近の状況を把握した. 開発環境としては, php-mode(emacs), PHP プラグイン(eclipse http://phpeclipse.sourceforge.net/) をテスト. 上記情報源からいくつかの話題, 他の Web アプリケーションとの比較(http://www.atmarkit.co.jp/flinux/rensai/mysql06/mysql06.html), 日本語エンコードの問題, セキュリティに関する情報, 最新のバージョンでの変更内容, 高速化, デザインパターンとの関連(http://www.phppatterns.com/, http://www.pat.hi-ho.ne.jp/dimension/), テンプレートに関して, PHPUnit (http://phpunit.sourceforge.net/)等をざっと理解.
雑感. 基本的にはやはり小規模開発向けである. 確かに簡易で自由度が大きい. form から値を受けとるインタラクティブなものが簡単に作成できる. 逆にいくらでも容易にろくでもないモノが作れる. エラー処理に細心の注意を. 一応クラスが使えるので, ある程度の Model/View の分離はできる. 関数が膨大, そして逆に整理されていない. 勿論 Unit テストを行い, 経験を生かさなくてはならない.
ming は, やっぱり ruby からより PHP からの方が使いやすい気がする. 日本の PHP メーリングリストのレベルはちょっと問題あり. 2ch でネタにされている..
いま気付いたが, emacs 21.3.50 では日本語が綺麗にイタリックになるようだ. 良い.
planner-browser 更新. current-window-configuration を使えば, 簡単に window の状態が保存できる. きちんとこの機能を用いている lookup.el や, window-configuration を賢く管理する elscreen を常用してながら, いまごろこの関数を理解した.
某研究機関にて. わたしの感覚が遅れているのだが, 巨大なクラスターを組んだ計算機は, とても生物系の研究室とは思えない. 学問は全て物理であるので, そこでの手法が世界を席巻している, と 思うこともできる.
最近の生物学は, またあらたなモノのみかたを 与えてくれる気がする. とりあえず例によって辞書入手.
planner-browser.el のバグを一部修正. 存在しない buffer を bury しようとしていた. やっぱりオプションをつけると分岐が増えるなあ, などと, たかだか一つのオプションでなげいてはいけない.
カウンター(2002/05/11)より