cuspy memo

Mediawiki の編集ツールとして cvs の様に記事を commit したりチェックアウトしたり出来る mvs がとっても便利なんだけど、幾つか気にくわないところがあったので弄った。

* commit する時に必ずコメントを要求される
コメント無しで commit しようとすると

No commit message specified See .mediawiki.errors for details.

こんな感じで怒られるけど、自分用のメモを編集する時とかコメントなんか必要ない場合もあるので。

@@ -1018,9 +1018,6 @@

 sub do_commit {
     my ($self, $filename) = @_;
-    WWW::Mediawiki::Client::CommitMessageException->throw(
-            "No commit message specified")
-        unless $self->{commit_message};
     # Perform the actual upload:
     my ($res, $text) = $self->_upload_file($filename, 1);
     # save the local version as the reference version

* ci 出来ない
cvs を日常的に使っている人なら commit する時に cvs ci ってするはず。
mvs にはその省略が使えないので使える様にした。

@@ -1042,6 +1039,16 @@
     do_commit(@_);
 }

+=head2 do_ci
+
+This is an alias for C<do_commit>.
+
+=cut
+
+sub do_ci {
+    do_commit(@_);
+}
+

* mediawiki のページタイトルの先頭文字を強制的に大文字にしないための設定 $wgCapitalLinks をしている時に困ったことになるので困らないようにした。

@@ -1353,7 +1360,7 @@
     $self->{escape_filenames} and $name = decode('UTF-8', URI::Escape::uri_unescape($name));

     $name =~ s/_/ /g;
-    return ucfirst $name;
+    return $name;
 }

昨日のグラフは螺旋なのか螺旋じゃないのか解りにくかったけど、入力のレンジを[-5, 5] にしてみると

おおー、ぐるんぐるんしてる。負の方向だと虚数の振幅が大きくなっていくんだな。
あと、

複素数の入力 x + yi を取って出力の絶対値を z にプロットしてもおもしろいかもしれない。

てのは

あんまり面白いものじゃ無かった。ついでなので実数成分と虚数成分を分けてみた。

赤が実数成分で青が虚数成分。
この角度からだと見えないんだけど、虚数成分で山が出来ているところは実数成分でマイナス方向に山が出来ている感じ。

フィボナッチ数列の一般化については数学ガールで

こんな式に一般化出来ることを知ってすげーなー実数にも拡張出来るのかぁ、と驚かされたものだけどよくよく考えると負の数を整数じゃない実数でべき乗すると虚数が出てくるんだな。

フィボナッチ数列の一般化が複素関数な件

フィボナッチ数列が一見実数上にある簡単なものに見えて、連続的な関数として捉えるとやつは複素関数に居て、その関数のごくごく一部分(入力が整数の場合のみ、と考えればこれは実数上の点点でしかない)のみを切り取って、「なんだこいつら全部整数じゃん」と思っているにすぎないと思うとなかなか身が震えてくる。

たしかに、自称 gnuploter としてはこれはもうプロットせざるを得ないな。
実数入力をz軸にとって、出力の実部をx軸、虚部をy軸でプロットしてみた。

あれ、これは螺旋なのかな? と思って。入力を(0, 5)までにしてみたら

確かに螺旋だった。

複素数の入力 x + yi を取って出力の絶対値を z にプロットしてもおもしろいかもしれない。

追記：
ソースコード

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <complex.h>

#define THETA 1.618034
double complex cfib(double i)
{
    double complex c = cpow(-THETA, -i);
    return (pow(THETA, i) - creal(c)) / sqrt(5) - cimag(c) / sqrt(5) * I;
}

int main(int argc, char *args[]){
    double d;
    double complex c;
    for(d=0; d<10; d+=0.1){
        c = cfib(d);
        printf("%lf\t%lf\t%lf\n", creal(c), cimag(c), d);
    }
    return EXIT_SUCCESS;
}

まずいな、このペースで翻訳してると完成するのが来年になりそう。
でもペースを上げると誤訳を量産しそう。(既に誤訳だらけだったり)
Entity を「実体」って訳すのは違和感があるなぁ、エンティティで良っか。
同様に、Roster も「名簿」と訳さずにロスターにした。

以下の用語はこのドキュメントの中で使用される pubsub サービスのコンテキストに登場する要素、オブジェクト、動作を参照するために使用します。(ノート: これらの用語の幾つかはこのドキュメントの本文の中でより詳しく定義されています。)

テーブル 1: Publish-Subscribe 用語

権限アクセスモデル

購読要求がノードの所有者によって許可された場合にのみエンティティが購読することが出来るノードアクセスモデル(購読要求は一時的に受け入れられます)そして購読者のみがアイテムを取得することが出来るでしょう。

アドレス

(1) XMPP Core で定義された JID[2], or (2) JID の集まりとサービスディスカバリー [3] ノード.

コレクションノード

ノードや他のコレクションを含んでいますが公開アイテムは含んでいないノードの一種。コレクションは階層ノード構造を表現することが出来ます。

エンティティ

JIDアドレス化された Jabber エンティティ(クライアント、サービス、アプリケーション、など。)

イベント

ノードの状態の変化

インスタントノード

ノードID が pubsubサービスによって自動的に生成されたノード

アイテム

公開されたノードの XML断片、それによってイベントが生成されます。

アイテムID

固有ノードのコンテキストにあるアイテムのユーニークな識別子。

末端ノード

公開されたアイテムのみを含むノードタイプ。それは他のノードを含みません。

ノード

情報を公開することが出来、イベント通知やペイロードを受信することが出来る架空の場所(他の pubsubシステムにおいて、これは “トピック” と呼ばれるかもしれません)。

ノードID

pubsubサービスに関するノードのためのユニークな識別子。ノードIDはノード作成者によって与えられるか pubsub サービスによって生成されます(ノード生成者がインスタントノードをリクエストする場合)。ノードIDはセマンティックな意味を持つかもしれませんがそのような意味は任意です。

通知

イベントの加入者に知らせるためのメッセージの送信。

追放

購読やノードへの公開を禁止されたエンティティ。

オーナー

ノードの管理者、一つ以上あるかもしれません。ノード生成者であるとは限りません。

ペイロード

イベント通知自身、というよりもイベントに関連した全てのデータ。

オープンアクセスモデル

どのエンティティでも承認なしで購読したりアイテムを読み出すことの出来るノードアクセスモデル。

Personal Eventing

インスタントメッセージングとプレゼンスアプリケーションに関する Publish-Subscribe の単純なサブセット、それによって各 IMユーザーの JID は仮想の pubsubサービスです。詳細は Personal Eventing via Pubsub [4]を見て下さい。

プレゼンスアクセスモデル

所有者のプレゼンスを購読タイプ “from” か “both” (see RFC 3921 [5])で購読しているエンティティがノードを購読したりノードからアイテムを取得することが出来るノードアクセスモデルです。このアクセスモデルは主にインスタントメッセージングシステムに適用されます。

公開者

アイテムをノードへ公開することを許可されたエンティティ。

Pubsubサービス

XMPP サーバー、あるいはここに定義されるプロトコル付随するコンポーネント。

ロースターアクセスモデル

所有者のプレゼンスとロスターグループに定義されたエンティティがノードを購読したりノードからアイテムを取得することが出来るノードアクセスモデルです。このアクセスモデルは主にインスタントメッセージングシステムに適用されます。

購読者

ノードを購読しているエンティティ。

ホワイトリストアクセスモデル

ノードの所有者によって明示的に許可されているエンティティのみ購読やアイテムを取得することが出来るアクセスモデル(許可されていないエンティティからの購読申請は拒否されます)。

続き。

== How It Works ==

この仕様は大きいです、しかし pubsub の背後にある基本的なアイディアはとてもシンプルです。(see Publish an Item to a Node)

1. 公開情報の実体を publish-subscribe サービスのノードへ送ります
2. pubsub サービスはその公開情報を知ることを許可されたエンティティへ送信します。

恐らく、最も pubsub に似たコンテンツ配信機能を持ったアプリケーションはブログやニュースサイト、その他のインターネットで頻繁に更新さる情報に有効でよく知られるようになった RSS と Atom(RFC 4287) フィードです。<hamlet@denmark.lit> さんがブログを配信する例を考えてみましょう。Hamlet さんが新しいブログのエントリを書く時、ブログソフトウェアは <pubsub.shakespeare.lit> でホストする pubsub ノードへ配信を行います。

例1. Publisher Publishes a New Weblog Entry

<iq type='set'
    from='hamlet@denmark.lit/blogbot'
    to='pubsub.shakespeare.lit'
    id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item>
        <entry xmlns='http://www.w3.org/2005/Atom'>

          <title>Soliloquy</title>
          <summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
          </summary>
          <link rel='alternate' type='text/html'
                href='http://denmark.lit/2003/12/13/atom03'/>
          <id>tag:denmark.lit,2003:entry-32397</id>

          <published>2003-12-13T18:30:02Z</published>
          <updated>2003-12-13T18:30:02Z</updated>
        </entry>
      </item>
    </publish>

  </pubsub>
</iq>

つまりこれが publish-subscribe の “pub” の部分です。

この時 pubsub サービスは全ての購読者に新しいブログエントリを通知します。

例2. Service Notifies Subscribers

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>

      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

<message from='pubsub.shakespeare.lit' to='bernardo@denmark.lit' id='bar'>

  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>

  </event>
</message>

<message from='pubsub.shakespeare.lit' to='horatio@denmark.lit' id='baz'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>

        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

<message from='pubsub.shakespeare.lit' to='bard@shakespeare.lit' id='fez'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>

    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

これは一時的なノードが本文のない通知だけを行う簡単なサンプルです。

例3. A Transient Notification

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='elsinore/doorbell'/>
  </event>
</message>

もちろん、これに関連した実体で全ての pubsub 機能を有効する為にはその他のユースケースを完全にする必要があるかもしれません。たとえば、配信者はノードを作成するが必要になるかもしれません(see Create a Node)、そして購読者は通知の為にサインアップする必要があるかもしれません(see Subscribe to a Node)。これらのユースケースはドキュメントの残りの部分で全て記載されています。(どの機能が必須で、どの機能が推奨か任意であるといった情報は Feature Summary を参考にして下さい。)