[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00643] Re: High-speed and improved MHC
>> On Tue, 30 May 2000 21:57:48 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari Nomura) said as follows:
nom> いい忘れましたが、速いですねぇ。TSU_SPEED
nom> 最初、byte-compile 忘れてた。
そりゃあ、全ての面において速度を重視した coding をしてありますから…。
nom> 2038年過ぎまでローン抱えている人にも、辛いかも。:-)
土> これ、どこが原因で発生しますか? 経過日数は 2038 年くらいでは overflow
土> しないと思うんですけど。
nom> C-cg で 2039/05 で error が出ます。多分 decode-time です。
確認しました。decode-time が文句を言ってますね。
Signaling: (error "Invalid time specification")
decode-time((33383 32512 0))
mhc-db/eval-for-duration(25322 25352)
nom> gemcal のような elisp でないクライアントが header を dump する場合、
nom> 順番に並べて出力してもらう必要があります。
MUA / MTA は、ヘッダの追加はしても、既存のヘッダを書き換えるべきではな
いと思うのですが…。
nom> あと Mew が バッファ上で Header の順番を変えることはよくありますね。
これには同意します。Gnus も表示順序を変えてくれるので、ちょっと変な感
じになります。
あ、ひょっとして import する時に問題になるってことですか? だったらやだ
なぁ。Semi-gnus だと表示用のデータは順序が変りますが、引用のために準備
したバッファでは、元の順序が保存されているので、考えもしなかったのです。
nom> メールの header は順番が代わっても意味を変えないと、
nom> みんなは思っているので、その作法から逸脱すると、あまりいいことは
nom> ないというのが僕の意見です。
そうすると、最初に私が考えていたていた X-SC-Begin: ように、構造を持つ
ようなヘッダ設計は全て駄目と言うことになりますね…。
こんなのかな?
X-SC-Subjcet: 研究会
X-SC-Cond: Wed
X-SC-Complex:
X-SC-Day: 20000531
X-SC-Subjcet: 研究会発表
つまり、複合条件節は継続行として書くと。
でもって、1行で書きたい場合はセミコロンで区切る。
X-SC-Subjcet: 研究会
X-SC-Cond: Wed
X-SC-Complex: X-SC-Day: 20000531; X-SC-Subject: 研究会発表
もっと徹底するなら、X-SC- が省略できることにして、
X-SC-Subjcet: 研究会
X-SC-Cond: Wed
X-SC-Complex: Day: 20000531; Subject: 研究会発表
という記法を許すことにする。この記法ならば、X-SC-Complex: によってまと
められていない部分が default を表すと考えれば分かりやすそうです。例え
ば、
X-SC-Subjcet: 班別会議
X-SC-Cond: Thu
X-SC-Location: 大会議室
X-SC-Complex: Day: 20000601; Location: 第2会議室
というような書き方が出来るでしょう。
## ということは条件判定の優先順位としては、逆に X-SC-Complex: を先に評
## 価した方が、直感に適合しそう。
更に徹底すると、
X-SC-Sexp: (if (day 20000531) (subject "研究会発表"))
‥‥というのはやり過ぎですね。
あ、それから、書き忘れていましたが、拡張版 MHC は、空白の部分に現れた
カンマを構文糖として安全に読み飛ばします。ですから、
X-SC-Day: 20000501, 20000504
X-SC-Cond: Wed, Mon
というような書き方が可能です。
土> つまり、1つのヘッダが、内容によって AND を表したり OR を表したりする
土> という複雑なことを行っているわけです。
nom> これは僕も承知しています。こういう規則が裏にあるというのは、
nom> 分かり辛いですよね。でも、規則を知らなくても、理性で正しく書けませんか?
同意します。parser を書くのは面倒でしたが…。
土> 個人的には、こういうものは、『1つのヘッダの中では常に OR 条件とし、AND
土> の場合は複数に分けて書く』というような和積標準形とした方が分かりやすい
土> と思うのですが。
土> X-SC-Cond: 1st
土> X-SC-Cond: Wed
nom> 美しいかもしれませんが、頻出する
nom> X-SC-Cond: 1st Wed
nom> を 2つに分けて書かないといけないのは、苦痛ですし、避けたくないですか?
でしたら、積和標準形に直すのはどうでしょう? つまり、1つのヘッダの中で
は AND 条件、並置されたヘッダは OR 条件とします。
ただまあ、こうすると予想されるのは、「第1、第3水曜日」という指定が面倒
じゃないか、ということなんです。
X-SC-Cond: 1st Wed
X-SC-Cond: 3rd Wed
積和標準形のもう1つの欠点としては、X-SC-Duration: との関係が分かりづら
くなってしまうという点があります。X-SC-Cond: と X-SC-Duration: の関係
は必ず AND なので、
X-SC-Cond: Wed
X-SC-Duration: 20000501-20000630
と書いたときの統一感がありません。まあ、この点に関しては、
X-SC-Cond: Wed, 20000501-20000630
という記法を許すことにすれば解決可能ですが。
と、よく考えてみると、X-SC-Duration: が導入されている理由が分からなく
なってきますね。X-SC-Cond: で指定される他の構文要素と判別可能なので、
統一できるのではないでしょうか。
積和標準形、和積標準形どちらであっても、これに更に否定演算子を追加する
ことによって、あらゆる条件が記述可能となることが絶対に保証されている枠
組みなので、想定外の制限が存在しないという意味では非常に優れていると思
います。
例えば、「第2以外の水曜日」はこんな感じ。
X-SC-Cond: ! 2nd Wed
否定演算子は通例通りにもっとも結合順位が高く、AND よりも先に解釈される
ことにします。
nom> ただ、このへん、もう少し考え所だと思います。
nom> 毎月の月末に発生する TODO とかは、直感的にどう書けばいいのだろう?
えっと、毎月月末に発生するんですか。そういうのはスケジュールに記入して
欲しいなぁ…。
## 弱気モード。
X-SC-Cond: Last
X-SC-Subject: 月末決算書の整理
X-SC-ToDo: 100
という指定が出来るのですが、どうでしょう?
nom> とか、
nom> 「論文提出」、「カメラレディ提出」 とか、2つの Deadline を
nom> Day: に書きたくなるのが人情かな、とか。。
X-SC-Duration: 20001201-20001205
X-SC-Subject: 1st MHC International Conferenece
X-SC-Location: 九大
X-SC-Next:
X-SC-Duration: 20000601-20000630
X-SC-Subject: 論文執筆
X-SC-ToDo: 100
X-SC-Next:
X-SC-Day: 200000630
X-SC-Subject: 論文提出
X-SC-Next:
X-SC-Duration: 20000901-20000930
X-SC-Subject: カメラレディ準備
X-SC-ToDo: 100
X-SC-Next:
X-SC-Day: 20000930
X-SC-Subject: カメラレディ提出
というのでは、十分に直感的ではないでしょうか。こうすると、スケジュール
帳に締切日が表示されるのと同時に、下の TODO リストにも表示されるように
なるんですけど。
nom> X-SC-NEXT: でばんばん書くようになると。
nom> そうすると、何でも intersect/ に入る率が高くなって、
nom> intersect/ を rescan するのが非常に重くなるんではないかという
nom> 危惧が。
それは私も思いました。
2000/intersect/
2000/01
2000/02
...
2001/intersect/
...
intersect/
というような階層構造にすると、ちょっとマシかも知れません。
nom> cache のチェックを slot 単位ではなくて、file 単位の粒度にする必
nom> 要がありそうですね。
MHC の内部では、file 単位での cache 制御が有効になっています。gemcal
などの外部プログラムと連携する場合に限って、slot が作り直されます。
なお、(setq mhc-use-cache 0) という設定をすると、外部プログラムによる
書き換えの検査を省略するようになるので、更に高速になります。
nom> 3. .schedule もその方式で書くと、特別扱いしなくてすむ。
nom> 編集もできるようになる。
はい、編集できるようにはしていませんが、私の手元では既に X-SC-Next: を
使って書き直したものを使っています。このように変更すると、更に速くなり
ます。
その気になれば、~/.schedule を捨てて、schedule/intersect/ 下の一般スケ
ジュールファイルの1つとして扱うことも可能です。
nom> 4. todo はやっぱり Duration: より Day: や Cond: で指定したい。
誤解させてしまいましたが、上述のように Day: も Cond: も使えます。しか
し、
X-SC-Day: 20000531
X-SC-ToDo: 1
という指定をすると、5月31日にスケジュールを確認したときだけ TODO リス
トに掲載されることになるので、あまり意味がないと思います。
# X-SC-Day: の意味からすると、これが自然だと思うのですけれど。
nom> 僕は、TODO は、schedule/todo/ を作って
nom> 管理するつもりでした。
土> その案も考えたんですけど…。例えばですね、学会発表なんかで、準備の
土> TODO を登録する場合には、学会のスケジュール管理のファイルと TODO のファ
土> イルが一緒の方が分かり良いだろうと思ったものですから。
nom> ごめんなさい。この心が分かりません。
えっと、私が言いたかったのは、「論文提出/カメラレディ提出」の例で書い
たように、学会日程と論文の提出締め切り、執筆TODOを1つのファイルで書き
たいだろうな、というだけのことです。
nom> todo/ は、スケジュール的には intersect/ と同じ扱いで、
nom> X-SC-TODO: がある場合は todo に refile されるというだけでは
nom> ダメでしょうか? DONE マークを付けても、スケジュールには影響しないし。
いえ、別にそれでも構いませんが、そのようにすると結局 schedule/todo/ に
ついても schedule/intersect/ と同じように検索をかけなければいけないと
言うことには変わりありませんから、ディレクトリが増えるだけで、プログラ
ム的に嬉しいことはないような気がするのですけれど、どうでしょうか?
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/