From tomo ＠ m17n.org Tue Sep 4 20:32:53 2007 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 04 Sep 2007 20:32:53 +0900 Subject: backquotes In-Reply-To: Katsumi Yamaoka's message of "Tue, 04 Sep 2007 18:35:55 +0900" References: Message-ID: >>>>> In [apel-ja : No.01441] >>>>> Katsumi Yamaoka wrote: > cvs.m17n,org に APEL の no-backquotes という枝を作りました。 > > 最近の Emacs は (` (foo (, bar))) のような旧式の backquote に > 対して次の警告を発します。 > > Warning: !! The file uses old-style backquotes !! > This functionality has been obsolete for more than 10 years already > and will be removed soon. See (elisp)Backquote in the manual. > > どのくらい `soon' なのか知りませんが、現在 Emacs の幹で旧式の > backquote を使っているモジュールはわずかなので、遠くない将来に > APEL と FLIM が使えなくなる可能性があります。対策としては > > 1. 新形式の backquote を使うようにする。 > 2. backquote を使わないようにする。 > のふた通りが考えられますが、ダウト！(^_^) 理論的には、旧形式の backquote は所詮マクロですから、なくなったとしてもマクロとして実装可能であると思います。 policy 上の是非は別問題として。 ;; 少なくとも FLIM ではやらない方が良いような気はします。 ;; また、以前、提案したように、Emacs 19 以降を対象とした ;; APEL-lite を作るというのは良いかも知れないですね。個人的には、少なくとも、APEL においては、現状維持で良いんじゃないかと思います。また、仮に直すとしても、将来の Emacs での評価対象にならない code に関してまで直すことには反対します（よって、現状の no-backquotes 枝の実装は良くないと思います）。 FLIM に関しては直しても良いと思いますが（実際の評価対象にならない code まで機械的に直すのは良くないと思いますが）、簡単なことだし、慌てなくても良いような気も。(^_^; -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yamaoka ＠ jpl.org Tue Sep 4 21:45:39 2007 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 04 Sep 2007 21:45:39 +0900 Subject: backquotes References:

Message-ID: >>>>> In [apel-ja : No.01442] 守岡知彦 / MORIOKA Tomohikoさん wrote: >>>>>> In [apel-ja : No.01441] >>>>>> Katsumi Yamaoka wrote: >> 1. 新形式の backquote を使うようにする。 >> 2. backquote を使わないようにする。 > ダウト！(^_^) > 理論的には、旧形式の backquote は所詮マクロですから、なくなったとして > もマクロとして実装可能であると思います。わかりました。将来 Emacs が ` というマクロを提供しなくなったら、 APEL が backquote.el そのものか、または似たものを提供するということですね? ただ、本来の Emacs に無い機能がある環境にいると、それが無い環境の利用者を対象にしたプログラムを書くときに、つい使ってしまいそうなのが気になるので、ぼくは APEL においては compiler macro として実装するか、必要なときだけ手作業で load するようにすることを希望します。もっともそれはソースレベルでデバッグする場合などに不便なのですが、今後はその種のコードをいじることはあまり無いでしょう。 > policy 上の是非は別問題として。 > ;; 少なくとも FLIM ではやらない方が良いような気はします。 > ;; また、以前、提案したように、Emacs 19 以降を対象とした > ;; APEL-lite を作るというのは良いかも知れないですね。 ;; うーむ、さすがに Emacs 19 と 20 はもう要らないんじゃないでしょ ;; うか。;-) どこで線を引くかは結構やっかいな問題で、こうしてい ;; る間にも変化していくでしょう。頭の体操のネタとして APEL はお ;; もしろいのですけれど、このごろは個々のプログラムで局所的に ;; Emacs の版の違いを吸収してしまうことが多くなって、APEL のよう ;; なものにまとめる意欲は下がってしまいました。単に Emacs-w3m が ;; APEL を必要とする構成なので、今でも使っているのですけれど。 > 個人的には、少なくとも、APEL においては、現状維持で良いんじゃないかと > 思います。 > また、仮に直すとしても、将来の Emacs での評価対象にならない code に関 > してまで直すことには反対します（よって、現状の no-backquotes 枝の実装 > は良くないと思います）。ある版の Emacs が使わないコードを確実に load しないようにすれば良いのでしょうけれど、それは大変そうです。実際、今では要らないものがたくさんありますね。それらが一斉に火を吹いた感じです。 > FLIM に関しては直しても良いと思いますが（実際の評価対象にならない code > まで機械的に直すのは良くないと思いますが）、簡単なことだし、慌てなくて > も良いような気も。(^_^; 今般の Emacs で warning が非常にうるさくなったので、それらを黙らせたいのが実は一番の動機でした。でも実質的には当分は問題にはならないでしょうから、理性では「慌てなくても良い」に同意します。 ;; ですが、個人的な感想としては warning がたくさん出るプログラム ;; には、手厚く管理されていない印象を持ちます。あるいは設計者の ;; 品性が低く見られるんじゃないかという心配です。というわけで、APEL 幹の変更は当分はしません。FLIM の変更については、もし問題があれば具体的にご指摘下さい。 -- 山岡 From tomo ＠ m17n.org Tue Sep 4 23:21:57 2007 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 04 Sep 2007 23:21:57 +0900 Subject: backquotes In-Reply-To: Katsumi Yamaoka's message of "Tue, 04 Sep 2007 21:45:39 +0900" References:

Message-ID: >>>>> In [apel-ja : No.01443] >>>>> Katsumi Yamaoka wrote: > >> 1. 新形式の backquote を使うようにする。 > >> 2. backquote を使わないようにする。 > > > ダウト！(^_^) > > > 理論的には、旧形式の backquote は所詮マクロですから、なくなったと > > してもマクロとして実装可能であると思います。 > > わかりました。将来 Emacs が ` というマクロを提供しなくなったら、 > APEL が backquote.el そのものか、または似たものを提供するという > ことですね? そういうことは可能ですね。ちなみに、私はそうした方が良いとかそうすべきだという風に主張している訳ではなくて、「のふた通りが考えられますが、」という主張に対して、３つ目の選択肢があるということを指摘しただけです。(^_^; > ただ、本来の Emacs に無い機能がある環境にいると、それが無い環境 > の利用者を対象にしたプログラムを書くときに、つい使ってしまいそう > なのが気になるので、そうですね（ただ、ある意味、APEL はそういうのの塊ではあります。(^_^;） > ぼくは APEL においては compiler macro として実装するか、必要なときだ > け手作業で load するようにすることを希望します。そういうのも良いでしょうし、それこそ、warning を出せば良い気がします。 ;; ただ、個人的には、APEL-lite を用意するのが良いような気はします。 > ある版の Emacs が使わないコードを確実に load しないようにすれば > 良いのでしょうけれど、それは大変そうです。実際、今では要らないも > のがたくさんありますね。それらが一斉に火を吹いた感じです。 eval されることなく、error が起こらなければそれで十分だと思うのですが。それとも何か実害が起こったのでしょうか？ > > FLIM に関しては直しても良いと思いますが（実際の評価対象にならない > > codeまで機械的に直すのは良くないと思いますが）、簡単なことだし、慌 > > てなくても良いような気も。(^_^; > 今般の Emacs で warning が非常にうるさくなったので、それらを黙ら > せたいのが実は一番の動機でした。でも実質的には当分は問題にはなら > ないでしょうから、理性では「慌てなくても良い」に同意します。 > ;; ですが、個人的な感想としては warning がたくさん出るプログラム > ;; には、手厚く管理されていない印象を持ちます。あるいは設計者の > ;; 品性が低く見られるんじゃないかという心配です。 ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってしまう ;; ので。あくまで、個人的印象なので、人それぞれだとは思いますが。 ;; それから、良くも悪くも枯れているのは事実で、それは多分、設計とは別 ;; 問題ではないかと。むしろ、個人的には、長期間大きな改変無しに動いて ;; きた（枯れることができた）ということとか、ソフトウェアとしての構造 ;; を評価して欲しいとは思います。また、設計と設計者、あるいは、設計者 ;; の品性は別物だと思います。 ;; むしろ、問題は、しっかりしたメインテナーがいなくて、code review の ;; 体制が崩壊していることだと思います（この点、申し訳なく思います。た ;; だ、残念ながら、当分、私としては CHISE Project の方に開発リソースを ;; 振り分けてしまうと思うので、後継メインテナーを引続き募集中です）。 > というわけで、APEL 幹の変更は当分はしません。FLIM の変更について > は、もし問題があれば具体的にご指摘下さい。とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論してからやるのが良いんじゃないでしょうか？ ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。 ;; また、短期間のうちに機械的に commit しちゃうのを見てると、十分にテ ;; ストされているのか不安になります。 (^_^; 実装面に関しては、私自身として review できてない部分も少なくないのですが、eword-encode.el の該当個所に関しては luna で書き換えるのが良いかなと思います（あるいは、関数でも良いかも）。 ;; これは、やってみようと思います。 P.S. たまに出てきてでしゃばって申し訳ないです（mail 環境がすっかり崩壊しているので、普段、記事も読めてないもので(^_^;）。ただ、枯れたソフトウェアにおける品質維持のための手続き上の懸念を少し持ったもので。動機の点ではおそらく同様だと思うので、プロセス上の問題点に関してご配慮して頂ければ幸いです。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yamaoka ＠ jpl.org Wed Sep 5 09:25:07 2007 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 05 Sep 2007 09:25:07 +0900 Subject: backquotes References:

Message-ID: >>>>> In [apel-ja : No.01444] 守岡知彦 / MORIOKA Tomohikoさん wrote: >>>>>> In [apel-ja : No.01443] >>>>>> Katsumi Yamaoka wrote: >> ある版の Emacs が使わないコードを確実に load しないようにすれば >> 良いのでしょうけれど、それは大変そうです。実際、今では要らないも >> のがたくさんありますね。それらが一斉に火を吹いた感じです。 > eval されることなく、error が起こらなければそれで十分だと思うのですが。国内外を問わずそれが主流の考え方のようですね。一方ぼくを含めた少数派は、明らかに害の無いコードに対して発せられる警告を気にします。これは単に見栄えだけの問題ではなくて、コンパイル時にわんさか警告が出るプログラムの場合、真にバグに対して出された警告をも見なくなる害があると思っています。 > それとも何か実害が起こったのでしょうか？いいえ。将来実害になる可能性があり、その予防が性能の劣化を伴わないならば、問題が起きる前に実施することは意義があると考えました。ただし、今回の APEL における変更 (backquote を使わないでマクロを書き直すこと) はソースコードの可読性を著しく下げたので、たとえ今後いじることが無いコードだとしても実施には躊躇があったので、いきなり幹にインストールする前にご意見を募ることにした次第です。 >>> FLIM に関しては直しても良いと思いますが（実際の評価対象にならない >>> codeまで機械的に直すのは良くないと思いますが）、簡単なことだし、慌 >>> てなくても良いような気も。(^_^; >> 今般の Emacs で warning が非常にうるさくなったので、それらを黙ら >> せたいのが実は一番の動機でした。でも実質的には当分は問題にはなら >> ないでしょうから、理性では「慌てなくても良い」に同意します。 >> ;; ですが、個人的な感想としては warning がたくさん出るプログラム >> ;; には、手厚く管理されていない印象を持ちます。あるいは設計者の >> ;; 品性が低く見られるんじゃないかという心配です。 > ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってしまう > ;; ので。あくまで、個人的印象なので、人それぞれだとは思いますが。機械的書き換えには違いありませんが、変更の大半はいろんな角度から検証済みです。「機械的」の意味は、例えば macroexpand の新旧の結果を比較することです。 > ;; むしろ、問題は、しっかりしたメインテナーがいなくて、code review の > ;; 体制が崩壊していることだと思います（この点、申し訳なく思います。た > ;; だ、残念ながら、当分、私としては CHISE Project の方に開発リソースを > ;; 振り分けてしまうと思うので、後継メインテナーを引続き募集中です）。守岡さんが申し訳なく思うことはまったくありませんよ。これらをみんなで改良して、それぞれが責任を持つことは当然の合意事項だと理解しています。 > とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論して > からやるのが良いんじゃないでしょうか？ > ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。変更に際しては提案し、評決を経て実施するというルールを忘れたわけではないのですが、それはすでに崩壊していると思います。いったい、有益な議論が行なわれたことが何回あるでしょうか? そもそも何か変更を行なう人は、その人の尺度で十分に煮詰めたものであろうし、それを他者が詳細に検証するのを待って実施するのでは非常に効率が悪いでしょう。ぼくもそうですが、そのとき興味が無ければ「それでいいんじゃない」すら言わないし、唐突に出てきた提案をすぐにみんなが検証してくれることを期待するのは無理があります。特に、深刻な問題提起を繰り返すユーザーに対してすら誰も反応しない現状では、そんな手順に意味があるとは思えません。cf. [emacs-mime-ja : No.02148] ;; 正直なところ、生活の道具としてはあまり活用していない APEL な ;; どからは足を洗いたいという気持ちもあります。それに、守岡さん ;; などの足下にも及ばない技量しか持ち合わせていませんしね。それ ;; でも「だれもやらないだろうなあ」と思うと手が出てしまうのです。 CVS のような道具を使うことが、開発と検証を開発者とユーザーが共有して、良いプログラムを効率良く作り上げていくことが目的ならば、いきなり変更をインストールしてしまうことは、むしろ推奨すべきことではありませんか? 実際ぼくはそれを頻繁にやっていたわけですが、有意義でない変更が静かに消されたりしているのを見るに、それはそれで機能しているように思えます。 > ;; また、短期間のうちに機械的に commit しちゃうのを見てると、十分にテ > ;; ストされているのか不安になります。 (^_^; むしろ、そういうことで発生した問題に対して異義が発せられるなら、良質な開発体制が維持されていると考えることができますね。ぼくは特におっちょこちょいかもしれないのですが、何もしないで放っておくよりマシだと思っていますし、自分がやったことに最後まで責任を持つつもりでいます。 -- 山岡 From yoichi ＠ geiin.org Wed Sep 5 08:36:17 2007 From: yoichi ＠ geiin.org (Yoichi NAKAYAMA) Date: Wed, 05 Sep 2007 08:36:17 +0900 Subject: backquotes In-Reply-To: References:

Message-ID: <87hcma57gu.wl%yoichi@geiin.org> なかやまです別の話になりますが、いい機会だと思うので。 At 04 Sep 2007 23:21:57 +0900, 守岡知彦 / MORIOKA Tomohiko wrote: > とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論して > からやるのが良いんじゃないでしょうか？ > > ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。 > > ;; また、短期間のうちに機械的に commit しちゃうのを見てると、十分にテ > ;; ストされているのか不安になります。 (^_^; > > 実装面に関しては、私自身として review できてない部分も少なくないのです > が、eword-encode.el の該当個所に関しては luna で書き換えるのが良いかな > と思います（あるいは、関数でも良いかも）。 > > ;; これは、やってみようと思います。 > > P.S. > > たまに出てきてでしゃばって申し訳ないです（mail 環境がすっかり崩壊して > いるので、普段、記事も読めてないもので(^_^;）。ただ、枯れたソフトウェ > アにおける品質維持のための手続き上の懸念を少し持ったもので。動機の点で > はおそらく同様だと思うので、プロセス上の問題点に関してご配慮して頂けれ > ば幸いです。ここで許可をとったわけではないですが、過去数年にわたり flim-1_14-rfc2231-encoder 枝に対して flim-1_14 の変更のマージ作業を行ってきました。(e.g. [emacs-mime-ja:02029]) RFC2231対応は将来的には flim-1_14 への導入の可能性もあると考えており、枝の変更分だけを区別できるように個別の修正をマージするのではなくリリースタグから一気にマージするように進めてきています。今後もそのように進めても問題ないでしょうか。 P.S. (というかこちらが本題) 最近はRFC2231ってどうなんでしょうか？少し(だいぶ？)前にMew方面で話題にあがっていた気がしますがちゃんと追ってていません。 # 職場では相変わらずlimit-1_14使ってますが。 -- Yoichi NAKAYAMA From yamaoka ＠ jpl.org Wed Sep 5 18:03:50 2007 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 05 Sep 2007 18:03:50 +0900 Subject: rfc2231 (was Re: backquotes) References:

<87hcma57gu.wl%yoichi@geiin.org> Message-ID: >>>>> In [apel-ja : No.01445] 中山さん wrote: > 最近はRFC2231ってどうなんでしょうか？少し(だいぶ？)前にMew方面で話題に > あがっていた気がしますがちゃんと追ってていません。 > # 職場では相変わらずlimit-1_14使ってますが。ぼくの知るかぎり Thunderbird と Gnus はデフォルトで RFC2231 エンコーディングを使います。でも、実際のところ相手の多くが対応していないのが困ったものです。双方ともに対策があったりしますが: http://www.mozilla-japan.org/kb/solution/3067 (info "(emacs-mime-ja)rfc2047") の最後 -- 山岡 From tomo ＠ m17n.org Wed Sep 5 23:51:06 2007 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 05 Sep 2007 23:51:06 +0900 Subject: backquotes In-Reply-To: Yoichi NAKAYAMA's message of "Wed, 05 Sep 2007 08:36:17 +0900" References:

<87hcma57gu.wl%yoichi@geiin.org> Message-ID: >>>>> In [emacs-mime-ja : No.02186] >>>>> Yoichi NAKAYAMA wrote: > > 実装面に関しては、私自身として review できてない部分も少なくないの > > ですが、eword-encode.el の該当個所に関しては luna で書き換えるのが > > 良いかなと思います（あるいは、関数でも良いかも）。 > > ;; これは、やってみようと思います。これ、手を付けてみたんですが、十分に抽象されてない場所がいっぱいあることが判りまして、ちょっと中断しました。ただ、逆にいえば、code を奇麗にするという観点では、luna 化は是非すべきだと思いました（多分、可読性が向上します）。ただ、いきなりするのは危険なので、その前に、一旦、リリースした方が良いと思います。できれば、昨日の山岡さんによる修正の前の状態で 1.14.9 をリリースしたいと思うのですが、いかがでしょうか？その後、現状を再度取り込むということで。 > ここで許可をとったわけではないですが、過去数年にわたり > flim-1_14-rfc2231-encoder枝に対して flim-1_14 の変更のマージ作業を行っ > てきました。(e.g. [emacs-mime-ja:02029]) RFC2231対応は将来的には > flim-1_14 への導入の可能性もあると考えており、枝の変更分だけを区別で > きるように個別の修正をマージするのではなくリリースタグから一気にマー > ジするように進めてきています。今後もそのように進めても問題ないでしょ > うか。 RFC2231 対応は長年の懸案の１つでもある重要な作業であり、感謝しております（また、貢献できておらず、申し訳ないです）。おそらく、どこかの時点で、 flim-1_14 枝に merge すべきものだと思います。また、flim-1_14 枝以外に関しては私の管轄外で、枝毎に自由にポリシーを決めて頂いて良いと思います。個人的には、上記方針は合理的に思えます。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ====================== Email: ====== From tomo ＠ m17n.org Thu Sep 6 00:24:53 2007 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 06 Sep 2007 00:24:53 +0900 Subject: backquotes In-Reply-To: Katsumi Yamaoka's message of "Wed, 05 Sep 2007 09:25:07 +0900" References:

Message-ID: >>>>> In [emacs-mime-ja : No.02187] >>>>> Katsumi Yamaoka wrote: > >> ある版の Emacs が使わないコードを確実に load しないようにすれば > >> 良いのでしょうけれど、それは大変そうです。実際、今では要らないも > >> のがたくさんありますね。それらが一斉に火を吹いた感じです。 > > eval されることなく、error が起こらなければそれで十分だと思うので > > すが。 > 国内外を問わずそれが主流の考え方のようですね。一方ぼくを含めた少 > 数派は、明らかに害の無いコードに対して発せられる警告を気にします。 > これは単に見栄えだけの問題ではなくて、コンパイル時にわんさか警告 > が出るプログラムの場合、真にバグに対して出された警告をも見なくな > る害があると思っています。 grep を使うとか、log を filtering するのはいかがでしょうか？ > > ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってし > > ;; まうので。あくまで、個人的印象なので、人それぞれだとは思います > > ;; が。 > 機械的書き換えには違いありませんが、変更の大半はいろんな角度から > 検証済みです。「機械的」の意味は、例えば macroexpand の新旧の結 > 果を比較することです。実装前（書き換え前）に検証することは当然のことですが、それとは別に、書き換えた code 自体もチェックした方が良いと思います。トリビアルな変更であっても、思わぬミス（あるいは、事故）はありうる訳ですから、code を書き換えたら cvs commit する前に必ず diff を見ることは必要ですし、動作をチェックすることもなるべくやった方が良いと思います。 ;; 本当はテストスイートがあれば良いんですけども。 ;; ちなみに、CHISE の文字データベースを書き換える時は、どんなわずかな ;; 修正であっても、コンパイラなんかと同様な不動点チェックを通過するま ;; で cvs commit しないという方針を取ってたりします。その上で、差分も ;; チェックします。 > > とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論 > > してからやるのが良いんじゃないでしょうか？ > > ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。 > 変更に際しては提案し、評決を経て実施するというルールを忘れたわけ > ではないのですが、それはすでに崩壊していると思います。いったい、 > 有益な議論が行なわれたことが何回あるでしょうか? > そもそも何か変更を行なう人は、その人の尺度で十分に煮詰めたものであろ > うし、それを他者が詳細に検証するのを待って実施するのでは非常に効率が > 悪いでしょう。ぼくもそうですが、そのとき興味が無ければ「それでいいん > じゃない」すら言わないし、唐突に出てきた提案をすぐにみんなが検証して > くれることを期待するのは無理があります。特に、深刻な問題提起を繰り返 > すユーザーに対してすら誰も反応しない現状では、そんな手順に意味がある > とは思えません。cf. [emacs-mime-ja : No.02148] emacs-mime-{ja|en} に投稿するのは、第一義的には『有益な議論』をするためではなくて、記録を残すためです。これは、現在の私のように、すぐに反応できない人にとって、極めて重要なことです。これをやらないと「cf. [emacs-mime-ja : No.02148]」というように、指し示すこともできません。反論がなければ実施すれば良い訳ですし、time out の期間は自分で決めることもできます。cvs commit しなくても開発はできます。さらにいえば、自由に自分の枝を作ることだってできます。flim-1_14 枝に commit する前に一言その意図を書くというのはそんなに非効率なものでしょうか？重要だったり深刻だったりするなら、なおのこと記録に残すべきじゃないでしょうか？ ;; また、『その人の尺度で十分に煮詰めたものであろう』から良いとするの ;; は、ソフトウェア工学的にはちょっとまずい主張ではないかと思います。 ;; それから、信頼性よりも開発を優先するフェーズ（例えば、開発用の枝） ;; では、効率を重視した方が良いと思いますが、枯れたソフトウェアでは信 ;; 頼性を重視した方が良いと思います。そして、それは工学的には、プロセ ;; スによって保証するものではないかと思います。少なくとも、flim-1_14 枝および将来の（開発枝 (status = alpha) ではない）『公式枝』に関しては、従来の方針通り、（メインテナー以外の人が）事前の宣言なしに cvs commit するのは止めて欲しいです。 ;; もっとも、私以外の誰かがメインテナーを引き受けて、方針を変えるなら ;; ば、その限りではないですが。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From nakaji ＠ kankyo-u.ac.jp Thu Sep 6 08:36:33 2007 From: nakaji ＠ kankyo-u.ac.jp (NAKAJI Hiroyuki) Date: Thu, 06 Sep 2007 08:36:33 +0900 Subject: backquotes In-Reply-To: (=?iso-2022-jp?B?IhskQjxpMixDTkknGyhC?= / MORIOKA Tomohiko"'s message of "05 Sep 2007 23:51:06 +0900") References:

<87hcma57gu.wl%yoichi@geiin.org> Message-ID: <86tzq8vg5a.fsf@ra333.heimat.gr.jp> 中治です。 >>>>> In [emacs-mime-ja : No.02189] >>>>> tomo ＠ m17n.org (守岡知彦 / MORIOKA Tomohiko) wrote: > ただ、いきなりするのは危険なので、その前に、一旦、リリースした方が良い > と思います。できれば、昨日の山岡さんによる修正の前の状態で 1.14.9 をリ > リースしたいと思うのですが、いかがでしょうか？その後、現状を再度取り込 > むということで。開発には「使う」ことでしか貢献していないユーザとして、一旦リリースバージョンとすることに賛成します。 -- NAKAJI Hiroyuki (中治弘行) From yamaoka ＠ jpl.org Thu Sep 6 08:40:06 2007 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Thu, 06 Sep 2007 08:40:06 +0900 Subject: backquotes References:

<87hcma57gu.wl%yoichi@geiin.org> Message-ID: >>>>> In [emacs-mime-ja : No.02189] >>>>> 守岡知彦 / MORIOKA Tomohikoさん wrote: >>> 実装面に関しては、私自身として review できてない部分も少なくないの >>> ですが、eword-encode.el の該当個所に関しては luna で書き換えるのが >>> 良いかなと思います（あるいは、関数でも良いかも）。 >>> ;; これは、やってみようと思います。 > これ、手を付けてみたんですが、十分に抽象されてない場所がいっぱいあるこ > とが判りまして、ちょっと中断しました。ただ、逆にいえば、code を奇麗に > するという観点では、luna 化は是非すべきだと思いました（多分、可読性が > 向上します）。うーむ、可読性ですか。luna は emacs-w3m の shimbun で利用しているので、最近はようやく読めるようになったもののいまだに苦手です。それは関数や変数がデフォルトの obarray ではない場所に隠蔽されてしまうことと、あまたの luna-* マクロの展開結果を頭の中で容易に思い浮かべることができないことにあります。何か問題が起きると、ぼくは 2重 3重に入れ子になったマクロをすべて展開して確認するのが常で、どうにも効率が悪い。少数の人たちが自在に使いこなしているのを見ると、単にぼくの能力の問題なのでしょうが。Gnus の nnoo.el にはあまり抵抗を感じないのですけれどね。 > ただ、いきなりするのは危険なので、その前に、一旦、リリースした方が良い > と思います。できれば、昨日の山岡さんによる修正の前の状態で 1.14.9 をリ > リースしたいと思うのですが、いかがでしょうか？その後、現状を再度取り込 > むということで。最近の変更を取り下げました。ChangeLog までも消してしまうのは良くないと思うので、逆にごみを増やしてしまいましたが、ご容赦。リリースするしないに関して意見はありません。 -- 山岡 From yamaoka ＠ jpl.org Thu Sep 6 09:37:46 2007 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Thu, 06 Sep 2007 09:37:46 +0900 Subject: backquotes References:

Message-ID: >>>>> In [apel-ja : No.01447] 守岡知彦 / MORIOKA Tomohikoさん wrote: >> これは単に見栄えだけの問題ではなくて、コンパイル時にわんさか警告 >> が出るプログラムの場合、真にバグに対して出された警告をも見なくな >> る害があると思っています。 > grep を使うとか、log を filtering するのはいかがでしょうか？警告を隠すという行為が、大事なものまで出力されないようにしてしまう恐れがあるという点では、どちらも同じですね。で、プログラムの側で隠蔽してしまうのはより責任が重いですから、ぼくは Gnus に仕込んだその手のものを不定期にチェックして、不要になった隠蔽を取り除くなどしています。 >>> ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってし >>> ;; まうので。あくまで、個人的印象なので、人それぞれだとは思います >>> ;; が。 >> 機械的書き換えには違いありませんが、変更の大半はいろんな角度から >> 検証済みです。「機械的」の意味は、例えば macroexpand の新旧の結 >> 果を比較することです。 > 実装前（書き換え前）に検証することは当然のことですが、それとは別に、書 > き換えた code 自体もチェックした方が良いと思います。トリビアルな変更で > あっても、思わぬミス（あるいは、事故）はありうる訳ですから、code を書 > き換えたら cvs commit する前に必ず diff を見ることは必要ですし、動作を > チェックすることもなるべくやった方が良いと思います。 > ;; 本当はテストスイートがあれば良いんですけども。 > ;; ちなみに、CHISE の文字データベースを書き換える時は、どんなわずかな > ;; 修正であっても、コンパイラなんかと同様な不動点チェックを通過するま > ;; で cvs commit しないという方針を取ってたりします。その上で、差分も > ;; チェックします。ぼくも必ず ediff を使って確認するようにしています。問題は動作チェックで、特に入力されるデータによって切り替わる機能の膨大な組合せのすべてを想定できなかった場合に、想定できなかったこと自体が後でわかることはありますね。そのためにも過去に起きた問題を対象にしたテスト治具があるのは良いことだと思いますし、dgnushack.el には実際の例がいくつかあります。もっとも今回の変更に関しては、マクロの展開結果が変更後でも同一であれば良しとしました。 >>> とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論 >>> してからやるのが良いんじゃないでしょうか？ >>> ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。 >> 変更に際しては提案し、評決を経て実施するというルールを忘れたわけ >> ではないのですが、それはすでに崩壊していると思います。いったい、 >> 有益な議論が行なわれたことが何回あるでしょうか? >> そもそも何か変更を行なう人は、その人の尺度で十分に煮詰めたものであろ >> うし、それを他者が詳細に検証するのを待って実施するのでは非常に効率が >> 悪いでしょう。ぼくもそうですが、そのとき興味が無ければ「それでいいん >> じゃない」すら言わないし、唐突に出てきた提案をすぐにみんなが検証して >> くれることを期待するのは無理があります。特に、深刻な問題提起を繰り返 >> すユーザーに対してすら誰も反応しない現状では、そんな手順に意味がある >> とは思えません。cf. [emacs-mime-ja : No.02148] > emacs-mime-{ja|en} に投稿するのは、第一義的には『有益な議論』をするた > めではなくて、記録を残すためです。これは、現在の私のように、すぐに反応 > できない人にとって、極めて重要なことです。これをやらないと > 「cf. [emacs-mime-ja : No.02148]」というように、指し示すこともできませ > ん。はい、emacs-mime-ja ではなく apel-ja だけで変更の予告を行ない、変更したことの報告をメールでしなかったのは問題でした。FLIM のリリースの話もあったので、今回の変更は取り下げました。 > 反論がなければ実施すれば良い訳ですし、time out の期間は自分で決めるこ > ともできます。cvs commit しなくても開発はできます。さらにいえば、自由 > に自分の枝を作ることだってできます。flim-1_14 枝に commit する前に一言 > その意図を書くというのはそんなに非効率なものでしょうか？重要だったり > 深刻だったりするなら、なおのこと記録に残すべきじゃないでしょうか？枝を作る必要は感じなかったのですが、そもそもぼくが無意味だと思っているルールがまだ活きていることを尊重しなかったのはすみませんでした。 > ;; また、『その人の尺度で十分に煮詰めたものであろう』から良いとするの > ;; は、ソフトウェア工学的にはちょっとまずい主張ではないかと思います。確かに完成度は人それぞれ状況それぞれなので、CVS commit という行為が、さらに客観的に検証して煮詰めるために俎上に載せることと同義だと思っています。おそらく守岡さんの基準に依れば、ぼくは Gnus を、ひいては Emacs を alpha 化しているのでしょう。Emacs 22.1 のリリース直前に RMS の求めに応じて小規模でない変更を行ないましたし、リリース後に発覚したバグをいくつか修正しています。 > ;; それから、信頼性よりも開発を優先するフェーズ（例えば、開発用の枝） > ;; では、効率を重視した方が良いと思いますが、枯れたソフトウェアでは信 > ;; 頼性を重視した方が良いと思います。そして、それは工学的には、プロセ > ;; スによって保証するものではないかと思います。 > 少なくとも、flim-1_14 枝および将来の（開発枝 (status = alpha) ではない） > 『公式枝』に関しては、従来の方針通り、（メインテナー以外の人が）事前の > 宣言なしに cvs commit するのは止めて欲しいです。わかりました。どうも意見の違いから、同じ話を何度もしているようですね。守岡さんにはたくさんの字数を尽くして相手をさせてしまい、申し訳なく思っています。 -- 山岡