Tag: SHIORI’

\![embed,...]の使い方がわかった

 - by Don

今更ながら\![embed,…]の使い方を把握したので覚書です。

基本

単純な例

里々でやろうとするときは\![embed,…]の呼び出し先イベントは\eで閉じないよう留意しないといけない。

*
:あいうえお\![embed,OnHoge]さしすせそ

*OnHoge
:かきくけこ

#これを実行すると以下のようになって「あいうえおかきくけこ」と表示された時点で再生が終わる
#\0\s[0]\1\s[10]\0あいうえお\0\s[0]\1\s[10]\0かきくけこ\eさしすせそ\e

単語群なら前後に余計なスクリプトは付かない。

*
:あいうえお\![embed,OnHoge]さしすせそ

@OnHoge
かきくけこ

#これを実行すると以下のようになる
#\0\s[0]\1\s[10]\0あいうえおかきくけこさしすせそ\e

里々であれば以下のように書いても同じ結果が得られる。

*
:あいうえお(OnHoge)さしすせそ

@OnHoge
かきくけこ

#これを実行すると以下のようになる
#\0\s[0]\1\s[10]\0あいうえおかきくけこさしすせそ\e

これでは面白くないので、同じ結果が得られない例を挙げる。

SakuraScriptの再生と同期して呼び出しが実行される例

*
:時計の秒針を一秒おきに数えてみよう!
(現在秒)、\_w[1000](現在秒)、\_w[1000](現在秒)…。

これは期待した動作にならない。「13、14、15…。」みたいになってほしいが、「13、13、13…。」となってしまう。里々が全ての括弧を展開した結果のSakuraScriptをSSPに渡しているだけなので、SSPに届く頃にはすべて13になっている。

しかし、\![embed,…]を使えば期待した動作が可能となる。

*
:時計の秒針を一秒おきに数えてみよう!
\![embed,OnGetSecond]、\_w[1000]\![embed,OnGetSecond]、\_w[1000]\![embed,OnGetSecond]…。

@OnGetSecond
(現在秒)

この例だと「13、14、15…。」みたいに再生される。SakuraScriptの再生と同期してイベント呼び出しが実行され、返されたScriptをその場で埋め込みながら再生を続ける。すごい。

応用

複雑な例

\![embed,…]とはどんなものか、ということについては上述の例さえわかれば十分である。それ以上でもそれ以下でもない。\![embed,…]はそんなに難しいものではない。

\![embed,…]ワカラナイ、というのは往々にして\![embed,…]以外のところに原因がある。例えば、UKADOCの説明には以下のように書いてある。

プロパティシステムの内容によって分岐など、イベントを実行して情報を取得する仕様を、1回のスクリプト実行で有効に使用するための仕様。

何言ってるかワカラナイ。

プロパティシステムというのは、SSPが知っている情報を教えてもらうための仕様だ。例えば現在時を教えてもらうには以下のように書く。

*
\![get,property,OnGetHour,system.hour]

*OnGetHour
:現在(R0)時です。

里々なら里々自身の力で(現在時)と書けば取得できるけど、簡単な例として。

ここで重要なのが、情報を取得するためには別イベントをコールする必要があるということだ。(R0)に入っている情報を(またはそれを使用/加工した文字列を)\![get,property]を実行した直後に埋め込んで再生したい場合もあるのかもしれない。そういうことができますよ、と\![embed,…]の説明には書いてある。

例えば以下のように書いてもkero側のScriptは再生されない。

*
:\![get,property,OnGetHour,system.hour]
:もうそんな時間か。#←これは再生されない

*OnGetHour
:現在(R0)時です。

イベントを呼び出す系のSakuraScriptは、それが実行された時点でそのイベントにおける再生は強制終了されるのが特徴である。

…と思っていた。昨日までは。例外があったのだ。知らなかった。

\![get,property]した後もScriptの再生が続く例

答えを言ってしまうと、以下のように書けばUKADOCの説明にあるようなことが可能となる。

*
:現在\![get,property,OnGetHour,system.hour]\![embed,OnShowHour]時です。
:もうそんな時間か。#←これが再生される!

*OnGetHour
$現在の時間【タブ】(R0)

@OnShowHour
(現在の時間)

\![get,property]した後もScriptの再生が続く条件は、呼び出したイベントで「何も返さない」ことである。

上記の例では(R0)の情報を変数に保存してはいるものの、再生するScriptは何もない。この場合、例外的に呼び出し元のScriptは再生を続けるのだ。知らなかった。

変数に保存したは良いが、再びSSPに処理が戻ってScriptの再生中である。保存した情報を再びSHIORI側で処理し、Scriptを生成し、呼び出し元に埋め込みたい。そこで\![embed,…]の登場だ。

\![embed,…]は極めて単純な仕様であり難しいことはない。\![get,property]の仕様が謎すぎるんだ。「何も返さない」場合のみScriptの再生を続けるとか誰が知ってるんだ。

補足

イベントを呼び出す系のSakuraScriptの代表と言えば\![raise,...]だ。きっと\![get,property]と同様な仕様となっているに違いない。

*
:艦隊のアイドル、\![raise,OnNakachan1]那珂ちゃんだよー!\![raise,OnNakachan2]よっろしくー!

*OnNakachan1
#何も返さない

*OnNakachan2
カーン...カーン...カーン...

予想通りOnNakachan2でScript再生が中断され、カーンカーンとなる。

ちなみに\![raise,...]はMateriaでもサポートされており、Materiaで実行しても同じ結果となった。なので、SSPは本家の仕様を忠実に再現しているものといえる。

複数のゴーストとコミュニケートする

 - by Don

うかべん 横浜#8の発表資料とヒノハルさんのテキスト実況を拝読しているところです。今回もためになる発表が多数行われたようで、こうした資料が公開されることはとてもありがたいことであると感じます。関係者の皆様、大変お疲れ様でした。

コミュニケートとraiseother

もっしょくしさんの発表資料「ゴースト間の交流について ~暦にしき宣伝添え~」は、ゴースト間での情報送受信を含む「絡み」について、利用できそうな現状の仕様をまとめた素敵な資料になっています。複数ゴーストの連携に関して興味のあるゴーストマスタさんは是非ご一読を。

その中で触れられていたコミュニケートとraiseotherの相違点の項目で、以下のように触れられていました。

コミュニケート
送信対象は一度に一人まで
raiseother
その場にいる全員に同時に発信できる(__SYSTEM_ALL_GHOST__)

実は現在(2013-11-03)、最新のSSP(2.3.12)では送信対象に関してコミュニケートもraiseotherと同等の仕様となっています。

via Satori/里々の小技 – PukiWiki

複数のゴーストに同時に話しかける

*AとBとCに話しかける
$Value0【タブ】A(sprintf,%c,1)B(sprintf,%c,1)C
:4人でマージャンしよー!

同時起動中のゴースト全員に話しかける

*全員に話しかける
$Value0【タブ】__SYSTEM_ALL_GHOST__
:みんなでじゃんけんしよー!

「複数の送信相手」を指定する場合はバイト値1区切り、「その場にいる全員」に送信する場合は「__SYSTEM_ALL_GHOST__」を使います。これはコミュニケートの場合はValue0ヘッダに、raiseotherの場合は第一引数に指定することができ、両者の送信対象に関する仕様の差はなくなっています(私がぽなさんの背中を優しくツンツンしてそうして頂きました)。

もしかしたら発表会場でぽなさんが指摘されたかもしれないですが念のため、現状の仕様はこのようになっていますので複数相手のコミュニケートも利用可能です。

里々は何故遅いのか

 - by Don

「loop関数は毎回呼び出し先の名前探してるから遅いのでは」的な見解を目にしたので、それなら名前参照せず処理直打ちのtimesなどの関数は早かろう、と思って計測してみました。

実験

*loopテスト
:[開始](現在分):(現在秒)(loop,my_loop,1000000)
[終了](現在分):(現在秒)
@my_loop
【処理】

*timesテスト
:[開始](現在分):(現在秒)(times,1000000,【処理】)
[終了](現在分):(現在秒)

*whileテスト
:[開始](現在分):(現在秒)(while,(C0)< 1000000,【処理】)
[終了](現在分):(現在秒)

*forテスト
:[開始](現在分):(現在秒)(for,1,1000000,【処理】)
[終了](現在分):(現在秒)

【処理】のところは以下の3パターンを試しました。

  • 空白(空回し)
  • (nop,)
  • (set,hoge,)

結果がこちら。1000000ループ処理にかかった秒数。

ループ関数 空回し nop set
loop 0 86 140
times 0 35 87
while 104 138 191
for 0 36 88

考察

whileは空回し中もカウンタのインクリメントや条件式判定を行なっているので時間がかかっています。nopやsetは隣同士の差を見ると純粋な関数自身の処理コストが読み取れるっぽいですね。平均してnopは処理コスト35、setは処理コスト88くらい?

loopは空回しでは名前参照しないようですが処理が存在すれば名前参照のコストも含んでいるようです。大体50程度。

timesやforを使えばループ自体のコストはほぼ0と言えそうです。ただ内部関数の呼び出しにかかるコストそのものがloopで浪費していた名前参照のコストに比べて大きなウェイトを占めている印象を受けます。括弧の展開と内部関数のコールは同じくらいのコストと考えても良いのかもしれません。

それから通常ループでカウンタを使わないということはほぼあり得ないので結局はwhileと同じ程度の処理を自前で行うことになるでしょうし、1回のsetで済む単純なループ処理なども実用上は少ないでしょうから結局は内部関数の呼び出しコストが積もり積もって遅くなる、という結論です。塵も積もれば山となる。

里々は重い処理に向かないという今更なお話でした。

ファイル読み書きはどれくらい遅いのか(追記あり)

 - by Don

YAYAで測定

ファイルの読み書きは遅いというのは体感的に何となく知っているのですが、どのくらい遅いのか調べてみようと思いました。

実験で使用するSHIORIはYAYA。関数のFREADFWRITEをそれぞれ1,000,000回実行して掛かった時間を測定します。ループ自体に掛かる時間や代入処理に掛かる時間なども比較のために測定します。

ループだけの処理//2秒
{
  _n = 1000000

  _start = GETTIME[6]
  for _i = 0; _i < _n; _i++ {
    //何もしない
  }
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}

代入処理//4秒
{
  _n = 1000000

  _start = GETTIME[6]
  for _i = 0; _i < _n; _i++ {
    _hoge = _i //代入
  }
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}

読み//10秒
{
  _filename = 'xxx'
  _n = 1000000

  _start = GETTIME[6]
  if !FOPEN(_filename, 'r')
    return
  for _i = 0; _i < _n; _i++ {
    _line = FREAD(_filename) //読む
  }
  FCLOSE(_filename)
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}

書き//10秒
{
  _filename = 'xxx'
  _n = 1000000

  _start = GETTIME[6]
  if !FOPEN(_filename, 'w')
    return
  for _i = 0; _i < _n; _i++ {
    FWRITE(_filename, 'hoge') //書く
  }
  FCLOSE(_filename)
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}

ループだけでもカウンタ_iがインクリメントされるのでその処理時間が掛かっているように見受けられます(代入処理を加えるとちょうど2倍の時間になっています)。ファイルのオープン/クローズのオーバーヘッドの影響がこの例ではほぼ無視されてしまいますがそれでもそれなりに時間が掛かっているようです(ファイルの開け閉めを同じ回数だけ回すとさらに2倍くらいかかります)(←勘違い)

追記

やっぱりFOPEN/FCLOSEまで含めての実験が必要ですね。ということで

読み//202秒
{
  _filename = 'xxx'
  _n = 1000000

  _start = GETTIME[6]
  for _i = 0; _i < _n; _i++ {
    if !FOPEN(_filename, 'r')
      return
    _line = FREAD(_filename) //読む
    FCLOSE(_filename)
  }
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}
書き//1510秒?(100,000回ループの値を10倍しました)
{
  _filename = 'xxx'
  _n = 1000000

  _start = GETTIME[6]
  for _i = 0; _i < _n; _i++ {
    if !FOPEN(_filename, 'w')
      return
    FWRITE(_filename, 'hoge') //書く
    FCLOSE(_filename)
  }
  _end = GETTIME[6]

  '\0\s[0]\_qstart: ' + _start + '\nend: ' + _end
}

他のSHIORIとの比較

前回の里々での実験においてループ回数を揃えて並べれば、SHIORIの処理能力の比較ができそうな気がします。

*nop関数
:[開始](現在秒)(loop,loop_nop,1000000)
[終了](現在秒)#82秒

*set関数
:[開始](現在秒)(loop,loop_set,1000000)
[終了](現在秒)#138秒

@loop_nop
(nop,)

@loop_set
(set,hoge,)

遅いですね。びっくりです。

ついでに華和梨でも調べてみます。

# ループのみ(1秒)
sample1: \0\s[0]\_qstart: $(date %S)$(loop 1000000 "")\nend: $(date %S)\e

# エコー関数(6秒)
sample2: \0\s[0]\_qstart: $(date %S)$(loop 1000000 $(echo ""))\nend: $(date %S)\e

# 代入関数(8秒)
sample3: \0\s[0]\_qstart: $(date %S)$(loop 1000000 $(setstr foo bar))\nend: $(date %S)\e

ループ自体では関数呼び出し1回のみで他の関数呼び出しが無い分高速のようです。代入などの関数をコールすればそれなりの時間を要するみたいです。

まとめ

表にすると見やすいかもしれない。

処理内容(1,000,000回) 時間(秒)
YAYA ループのみ(for) 2
YAYA 代入 4
YAYA ファイル読み(FREAD) 10
YAYA ファイル書き(FWRITE) 10
YAYA ファイル読み(FOPEN,FREAD,FCLOSE) 202
YAYA ファイル書き(FOPEN,FWRITE,FCLOSE) 1510(?)
里々 何もしない関数(nop) 82
里々 代入関数(set) 138
華和梨 ループのみ 1
華和梨 エコー関数(echo) 6
華和梨 代入関数(setstr) 8

ファイル読み書きの遅さの検証のはずが里々の遅さにびっくりする結果となりました。ファイル読み書きが逆に高速に見えてしまいます。こんなはずでは。

複数のファイルを開け閉めするのはそれなりに時間がかかるようですが、1つのファイルに何万行読み書きしてもそれ自体はあまり時間はかからないようです。

でも実用上1,000,000回もループする処理なんて普通のゴースト開発ではまずあり得ないですね。

SAORI呼び出しはどれくらい遅いのか

 - by Don

里々で測定

内部関数 V.S. SAORI

SAORI呼び出しは遅いというのは体感的に何となく知っているのですが、どのくらい遅いのか調べてみようと思いました。

実験で使用するSHIORIは里々。内部関数のwhenとSAORIであるssu.dllのifをそれぞれ同じ回数実行して掛かった時間を測定します。里々で時間を取得するために(現在秒)を使います。本当はミリ秒まで見たいけど仕方ない。

*
:[開始](現在秒)(loop,loop_when,100000)
[終了](現在秒)#9秒

*
:[開始](現在秒)(loop,loop_if,100000)
[終了](現在秒)#17秒

@loop_when
(when,1,)

@loop_if
(if,1,)

環境にもよるのでしょうが100000回だとwhenで9秒、ifで17秒ということで大体2倍程度の違いが見られます。

ssu.dll V.S. YAYA as SAORI with ssu.aym

応答速度はSAORIにもよります。ssu.dllのsplitとssu.aymのsplitで比較してみます。

*
:[開始](現在秒)(loop,loop_split,30000)
[終了](現在秒)#6秒

*
:[開始](現在秒)(loop,loop_split_yaya,30000)
[終了](現在秒)#77秒

@loop_split
(nop,(split,))

@loop_split_yaya
(nop,(aya,split,))

nopが含まれているので正確ではないですが30000回だとssu.dllで6秒、ssu.aymで77秒と10倍近く違います。

10回程度のループ処理をYAYAに投げるくらいならssu.dllを10回呼び出してもさほど変わらないようです。

他に時間のかかることとの比較

HTTPリクエストやファイルの読み書きとの比較も面白そうですが、また今度。

れしばを作った

 - by Don

とある事情により、「れしば」の.NET版「れしば.NET」を作りました。Worksからダウンロードできます。

表示制限とかも無いので、若干使いやすいかも使いづらいかもしれません。

YAYAからPLUGINを呼び出す

 - by Don

SAORIみたいに呼ぶ

YAYAからSAORIを呼び出す関数(FUNCTIONEX)は大抵システム辞書(yaya_shiori3.dic)に書いてあります。

そこでPLUGINを呼び出す関数も書いてみました。

https://gist.github.com/1048890

はろーYAYAわーるど」のシステム辞書に追加する形で利用できます。

PLUGINは通常ユーザが実行する、もしくは![raiseplugin]などを使ってSSP経由でゴーストが呼び出すものですが、何らかの事情でゴーストに同梱してSHIORIから直接呼び出したい場合もあるかもしれません。usage.txtの例にある通り、SwissArmyKnifeなど多機能なPLUGINもありますし、ユーザがPLUGINを無効化していた場合などでもゴーストに同梱しておけばいつでも使えて安心です。(メジャーな機能を持つSAORIは各ゴーストに積むよりもPLUGINにしてみんなで利用しよう、という精神に反しますが。)

里々からPLUGINを呼び出したい場合は、satori.dll =(SAORI)=> yaya.dll =(PLUGIN)=> SAKNIFE.DLL といった具合にYAYA as SAORI経由で二段重ねで呼び出せます。

もちろん、SAORIのように単一機能を呼び出すだけの単純な構成のPLUGINに限られます。PLUGINはGHOSTと一緒で、常にSSPからイベントを受信しているので、通常は複雑な機能を実現する場合が多いです。

何故こんなものを

gomi.dllがバグってると聞いたので、SAORIでないとダメなのかなと思って書いてみました。でもやはりPLUGINは![raiseplugin]で利用した方がいいですね。

YAYA as SAORI 修正

 - by Don

YAYA as SAORI が最新のYAYA(Tc537-2以降)で正常に動かなくなっていたので、修正してみました。

https://gist.github.com/1007538

2011-06-05 追記

ダウンロードする場合はファイルの文字コードがUTF-8になっていると思いますので、Shift_JISに直してご利用下さい。(YAYAのテンプレートでは大抵デフォルトで辞書ファイルをShift_JISで書くように設定されています)

クローラ&ロダが起動しない方へ

 - by Don

クローラ&ロダ」が起動しない場合の対処法

.NET Framework 2.0が入っていない場合

microsoftからもらってきてインストールしてください。

.NET Framework 2.0が入っている場合

D.N.Proxyのバージョンが2.0になる前にそのサンプルゴーストをインストールされた方はSSPのルートディレクトリにUkagaka.NET.Interfaces.dllが存在する可能性があります。それを削除してください。

user.dllが見つかりませんと言われた場合

手元で再現できないのでまだ解決法はわかりません。

とりあえず私の環境で作られたuser.dllを指定の場所に置くためのサプリメントZIPファイルを以下のサイトから入手して追加でインストールしてください。

https://github.com/nikolat/supplement_crawler