nDiki : プラグイン

2004年2月10日 (火)

[ WiKicker ] WiKicker脚注機能追加

WiKicker スタイルで日記を記述するにあたり欠けている機能として「脚注」がある。 Wiki としては必須でないので WiKicker には導入していないのだが、日記としては無いと困る。 脚注が使えると文を書く時に正直手を抜ける。 またハイパー日記システム上の旧記事をコンバートする時にも無いといろいろ面倒だし。

ということで実装

インラインブロック

さてどうしたものか。 WiKickerWRI (BracketName 等を含む識別子)としての実装なら、parser の変更もなく新しいWRI scheme の追加と対応するクラスを書くだけですむ。 しかし WRI は終端記号なので、そうすると脚注の中でWRIを使えなくなる。 それは困る。

ということで、やはり非終端記号が必要。 悩んだあげく、

 {{scheme: ... }}

という「インラインブロック非終端記号」を導入。 {{..}} というのは確かいくつかの WikiEngineプラグイン呼び出しで使っている記法だったような。

  • 一般的な文章中には現れず、
  • かといって文章中に混ぜてもそれほど違和感なく(wiki ではこれが重要)
  • これ以上文法を追加したくないので、今後機能追加の際に利用できるように scheme 指定できる

といった点から、このようにしてみた。 2番目の点で合格点の出せる記法かどうかは微妙だが、まぁ許せる範囲かな。

{{ }} は、1行中に現れる必要有り。 「...」は scheme specific part だが、今のところ scheme によらず、InlineParser で解析されて部分木になるため、WRI とか ... とかも書ける。 InlineParser では正規表現を使っていて括弧の数は数えないので、今のところ {{ }} の中に {{ }} は書けないが、まぁ問題ないでしょう。

脚注記法

脚注は、

 {{fn: ...}}

となる。 普通。

実装

  • InlineParser の拡張
  • InlineBlockNode クラスの追加
  • 各 Visitor に visit_InlineBlockNode を追加。
  • HtmlFragmentVisitor に fn: の処理を追加。

いざ実装してみると、ちょこっとのコードで実現。 脚注番号の降り方とか、今後改良する点はあるけど、大枠は完成。

スポンサード リンク

Wiki文法の標準化

今まで触れなかったが、やはり文法拡張する際は気になる存在。

各方面で出ている賛否どちらの意見もうなずける点が多く、自分の思いつく点もだいたいどこかで語られている感じ。

私が最初に Wiki の存在を知ったのは、やまだ君からだった。 当然「記法(文法)は?」というのがまず気になった点だったが、その時すでに「Wiki文法WikiEngine毎に異なる」という事だった。

WiKicker という新しい WikiEngine を作る際には、もちろん各 Wiki文法を調べたのだが、それはもう様々で。 「見出し」記号など単純に流派的なものと、ブロックプラグインなど設計思想に依存するものがあって、特に後者はどれかを統一して選択するのは難しいと感じた。

WiKicker では(もともと利用していた) YukiWiki2 に emacs-wiki の [[A][B]] を加え、その他の文法要素と表記は、

  • 見やすさ
  • メジャー度
  • WiKicker のベースの文法と衝突しない
  • 行指向を採用(行を越えた、開始・終了を利用者が明記しないで済むように)
  • 構文解析しやすい (実装の容易性は、高速化・独自ツール作成時に重要)

あたりをポイントに決めた。

将来標準(ができたとして)に準拠する?

多分しないな。 面倒だし。

[ 2月10日全て ]

2004年5月21日 (金)

AWStats 6.0

www.naney.orgアクセスログをローカルにもってきて統計解析をするのに、今回は analog ではなく AWStats を使うことに。

以前 www.naney.org に入れてみた時より、随分使いやすくなった感じ。

セットアップ

Debian パッケージを入れた後、awstats.naney.org というバーチャルドメインをローカルのApacheに用意(/var/www/awstats.naney.org)。

 Alias /icon/ "/usr/share/awstats/icon/"

も設定に追加しておく。

ファイルレイアウト:

 /var/www/awstats.naney.org/
  |
  +-- .htaccess
  |
  +-- awstats.conf  <-- 作成
  |
  +-- awstats.pl    <-- コピーしてきて一部修正
  |
  +-- cache         <-- DNSキャッシュ用 (まだ未使用)
  |
  +-- data          <-- データを保存
  |
  +-- plugins       <-- プラグイン
       |
       +-- wikicker.pm <-- /wiki/(.*).html を $1 で表示するプラグイン(自作)

awstats.pl はパッケージのものをコピー。DecodeEncodedString の中で Jcode.pm を使って文字列を UTF-8 に変換するように修正。

ローカル用なのであまり気にせず DocumentRoot の下にもりっとファイルを置いておく。

awstats.conf はこんな感じ。

 LogFile="/path/to/downloaded-log/access.log"
 LogType=W
 LogFormat=1
 LogSeparator=" "
 DNSLookup=2
 DirData="./data"
 SiteDomain="www.naney.org"
 HostAliases="localhost"
 DNSStaticCacheFile="cache/dnscache.txt"
 DNSLastUpdateCacheFile="cache/dnscachelastupdate.txt"
 URLWithQuery=1
 URLReferrerWithQuery=1
 LevelForWormsDetection=2
 ShowWormsStats=1
 LoadPlugin="wikicker"
 ValidHTTPCodes="200 304 -"

ValidHTTPCodes の '-' というのは、本来不要。自前のSSIで似非 Combined Log を生成する際に '-' を出力する事があるので追加。

日本語もきちんと出るしいい感じ。 指定した月ではなく、指定した日のログを見れるといいのだが設定すればできるようにならないかな。

analog と違ってプラグインが使えるのが良い。 Perlスクリプトだから、その気になれば簡単に awstats.pl 自体を変更する事もできるし。

今回は ShowInfoURL 用プラグインを書いて、/wiki 以下のURLの際は unescape して PageName を表示するようにしてみた。

その他いろいろ遊べそう。

[ 5月21日全て ]

2004年9月9日 (木)

ANTLR

やっぱり手でYAMLのパーサを作成するのが面倒なので(FIRSTとかFOLLOWとか入力バッファ処理とか)、やっぱりジェネレータを使う事を検討。 Java だと ANTLR あたりか。

YAMLだと文脈に応じて、インデント用空白列トークンの長さをかえて認識しなければならないのでそれがうまくできるかどうかがポイント。

まずはインストール(Eclipse 用のプラグインも入れておく)。 ちょっとずつマニュアルも読み始める。

[ 9月9日全て ]

2004年10月16日 (土)

Template Toolkit のテンプレート上で対話的入力

ちょっとしたプログラムパッケージや LaTeX ドキュメントを作成する時に、Makefile やその他ファイルのスケルトンをまとめて生成する算段を検討中。 例えば Perlh2xs のような感じ。

基本的には Template Toolkit ベースでいってみたい。 ttree あたりを使えばだいたいできそうだ。 ここで --define var=value で全て間違えずに指定するのは大変になってくるだろう。 ということでテンプレート変数定義をまとめたテンプレートファイルを作成し、各テンプレート処理をする際にプリプロセスするようにする。

でこのテンプレート変数定義のテンプレートファイルは対話的に作成できるようにしたい。 テンプレートファイルのテンプレートファイルを処理して。

で対話的入力の方法なのだが、探してもそのようなディレクティブもプラグインもみつからない。ありそうなもんだけどなぁ。

しょうがないので、PERL ディレクィブ内で Term::ReadLineを使って入力。 こんな感じ。

 [% TAGS [- -] -%]
 [- PERL -]
 use Term::ReadLine;
 my $term = new Term::ReadLine('template');
 $stash->set('readline' => sub {
   my $prompt = shift || 'input:';
   my $text = $term->readline($prompt);
   if (defined $text) {
     $term->addhistory($text);
   }
   return $text;
 });
 [- END --]
 [% project.name = '[- readline('project name:') -]' -%]
 [% project.author = '[- readline('author:') -]' -%]

tpage でこのテンプレートファイルを処理すると、対話的に値を入力しながらテンプレートファイルを生成できる。 実際は文字列のエスケープなどもうちょっと工夫が必要。

ちなみに Debian GNU/Linux sid の libtemplate-perl は 2.10-1 で、このバージョンの Template Toolkittpage だと EVAL_PERL が有効になっておらずうまく動かない。 手元にコピーして Template オブジェクトの初期化部分に EVAL_PERL => 1 を追加する必要あり (2.14 の tpage は --eval_perl オプションで有効にできる)。

[ 10月16日全て ]

2005年9月13日 (火)

[ WiKicker ] hell mode - HTMLタグ付けブロックの導入

WiKicker では、直接 WikiPageHTMLタグを記述して表示に反映させる機能を提供していない。

HTMLタグ付けを許すのは嫌だ

HTMLタグ付けを許すと

  • 入力ミスによるトラブル
  • 悪意ある入力によるトラブル

が起きやすくなるし、ページのソースの単純さが大きく失われてしまう。 レンダリングしてHTMLにした時に、正しいHTMLを出力されることを保証することが困難になるとともに、HTML以外へのレンダリング/コンバートもかなり難しくなる。

この機能を導入すると、Wiki の良さの半分(あるいはもうちょっと沢山か、もうちょっと少なめ)が失われてしまう。

でも

とはいえ欲しいという声があることも事実。 オープンな WikiForum では全くお勧めできないが、閉じたユーザグループの中ではまぁ必要悪なのかもしれぬ。

また正直ちょっとした表現を追加したい時に、WiKicker 用のプラグインを書くのも面倒だというのは確かにある。

WiKicker では開始・終了マーカによる複数行にまたがるブロックを表すための文法は(閉じ忘れを避けるため)意図的に排除してある。 このため、複数行にわけて書きたいような長いデータを扱うような拡張も導入しにくい。

ちょっと手抜きして「生HTML書けちゃえば」という誘惑はなくはない。

大人の事情

ということでまあ自分に言い訳をしつつ、標準ではオフというかたちで HTMLタグ付けブロックを導入することにした。 スイッチは hell mode とかにしたい (今回は syntax.html というプロパティ名にしたけれど)。

記法は単純に、

 normal wiki syntax text...
 <html>
 html tagged text...
 ...
 </html>
 normal wiki syntax text...

のように行頭が <html> である行から、行頭が </html>である行までをHTMLタグ付けブロックとすることに。 このため、<html>ではじまる段落が書けなくなるという小さな非互換が発生するが、いたしかたない。

サニタイズ

HTMLタグを直接使えるようにするとはいえ、全てを許してしまうのはあまりに危険で非人道的すぎる。 有効なHTMLタグや属性は限定的であるべきだ。

このあたりの処理は面倒だが、幸いにしてCPANにモジュールがある。 今回は HTML::Scrubber を使うことにした。 HTML::Parserを使って parse し、指定したルールに従ってサニタイズしてくれる。

ちょっと使ってみた範囲では日本語(UTF-8UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。

ということで、これを採用することに。

どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。

[ 9月13日全て ]

2006年1月29日 (日)

Last.fm に登録してみる

Last.fm は利用者の音楽プロファイル(好み)をもとに、お薦めの曲をインターネットラジオその他の形式で紹介してくれるというサービスらしい。

様々なミュージックプレーヤー用のプラグインが提供されており、これを利用すること自分が再生したトラックの情報をサーバへ submit していってくれる。 これにより、どんどん自分の好みを設定していけるようになっている。

amaroK にはビルトインでこの機能が実装されている。 設定で Last.fm でのユーザ名とパスワードを入力し、この機能を使うように設定しておくことで再生した曲情報をサーバへ送るようにできる。

面白そうなので早速ユーザ登録し、設定してみた。

で、再生、再生。また再生。

……あれ、Last.fm の自分のユーザページを見ても Recent Tracks は「No recently played tracks to display.」のままだ。

うーん。amaroK の debug 出力をみたり、接続を Proxy 経由にしてそのログで通信状況をチェックしたりしてみたりした範囲では、通信はしているようなのだが。

ちょっと様子見。

[ 1月29日全て ]

2006年2月3日 (金)

amaroK から Last.fm へ送信できるようになった

iTunesプラグイン iScrobbler For Windows 1.1.0 をインストールして、曲を再生してみたところ Last.fm へ曲情報をうまく送信できた。 アカウントの方は特に問題ないらしい。

やはり amaroK 側の問題か。

何度か amaroKsvn 版をコンパイルして試してみるうちに、そういえば configure した際にいくつか optional なライブラリが無くてそれらの機能が外されている旨の表示が出ていたことを思い出した。 apt-get build-dep amarok では全部入らないらしい。

README をみて必要なライブラリを確認。 libmp4v2 あたりが怪しい。ということで libmp4-dev パッケージをインストール。 また前回インストールされていなくて configure に --without-akode していたので aKode 関係のライブラリもあわせていれておく。

で再インストール

で再生してみたら、あっさりうまくいった。

よし。

[ 2月3日全て ]

2006年4月7日 (金)

長年使っていた Window Maker を捨てて KWin

大学で NEXTSTEP に慣れ親しんだこともあって X のウィンドウマネージャ は AfterStepWindow Maker とずっと NEXTSTEP の look and feel を持つものを使ってきた。

しかし昨年秋ぐらいに Konqueror をちょっと使うようになったり、KNewsTicker を使うために KDE パネル (kicker) を表示するようになったりするようになってから、だんだん KDE 臭くなってきた。

KDE パネルを表示していると Window Makerアイコン列とのおさまりが悪いし*1ノート PC の狭い画面を効率的にも使っていない感じになってきた。

ということで、おもいきってウィンドウマネージャも KWin にしてみた。 現時点で使っていた dock app (wmclock、wmbutton、wmtop) は同等の機能をもつ GKrellM プラグインで代替。 GKrellM 用の asclock /wmclock ライクな時計が見つかっていないのがちょっと残念だが、画面すっきり。

KWin への切り換えであるが、てっきり .xinitrc で wmaker を起動するかわりに kwin を起動すれば良いのかと思ったらそれではうまく動かず。かわりに .xinitrc で startkde するようにしたら動くようになった。 そういうものなのか。

*1ちゃんと KDE パネルとは被らないように並ぶのではあるが

[ 4月7日全て ]

2006年4月15日 (土)

sid の CinePaint がプラグイン読み込みでエラー

10枚の「ゴッサム・シティ東京 」を見て HDR イメージに興味を持った。

で早速日中に、手持ちのデジカメで段階露出をした写真を取りためて、家に帰って HDRI 作成に入る。 Linux だと CinePaint あたりが王道か。 CinePaint 0.21 には

  • "Bracketing to HDR" Plugin for CinePaint (Version 0.4.1)

が最初から入っており、段階露出で撮影したデジタル画像から HDR イメージを作成できるのである。

が。

Debian GNU/Linux sid で cinepaint 0.21-1 をインストールして起動してみると、

 /usr/lib/cinepaint/0.20-1/plug-ins/bracketing_to_hdr: symbol lookup error: /usr/lib/libcinepaint.so.0: undefined symbol: gtk_marshal_NONE__NONE
 wire_read: unexpected EOF (plug-in crashed?)

と出てしまうではないが。CinePaint 自体は起動するのだが、プラグインが読みこみ失敗してしまっているようだ。全てのプラグインの読み込みに失敗している様子である。

環境依存かと思いソースパッケージからビルドし直してみてもやっぱり同様。

そんな。

[ 4月15日全て ]

2006年4月16日 (日)

CinePaint で HDR イメージを作れるようになった

昨日の CinePaint のプラグイン読み込みエラーの問題であるが、CinePaint 公式サイトから RPM パッケージを取ってきて alien で deb パッケージに変換しインストールしてみたところうまく動くようになった。

早速使えるようになった Bracketing to HDR プラグインを試す。

[File] -> [New From] -> [Bracketing to HDR] とメニューを選択し段階露出したデジカメ画像を選択、パラメータを調整した後 HDRI xを生成する。

ちなみに昨日外で撮影してきた画像は、露出を変えた各画像がそれぞれ数ドットずれていて使いものにならなかった。 マンフロットの頑丈な奴とはいえやはり卓上三脚FinePix F10 で段階露出するには、メニューをいじって露出補正を変更していかなければならないこともあって、十分固定しておけなかったようだ。

ということであらためて適当に -2EV から +2EV まで 1EV 刻みに段階露出して5枚撮影し CinePaint で処理。

……うーん、いちおうちょっとコントラストがあがった感じの画像になったけれど他の人が作っているようなアーティスティックな感じに仕上らないなぁ。 ここに載せられるような面白そうなものにはならず。

段階露出の幅が足りないのか? FinePix F10 で露出補正だと±2EVまで、マニュアル露出モードはないしどうするか。

広いダイナミックレンジをうまく取れるような景色を探してみればよいのか?

[ 4月16日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.058975s / load averages: 0.66, 0.83, 0.68
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker