Article View: fj.editor.xemacs
Article #164Re: 不可解なバッファと、フレーム分割。
From: Atsushi Shinmura
Date: Fri, 15 Mar 2002 03:18
Date: Fri, 15 Mar 2002 03:18
148 lines
8891 bytes
8891 bytes
新村です。お世話になります、山岡さん。 ご説明の趣旨、良くわかりました。ありがとうございます。ただ、この 場にそぐわないかもしれませんけど、あえてポリシーの問題も入ってき ましたので、個人的な信条として申し述べます。 予め、断っておきますが、たまたま気にかかっていたことを記事にする 機会があっただけで、決して山岡さん個人への誹謗ではありません。そ の点、くどいようですが念を押しておきます。 見ただけで不愉快、関わりたく無いと言うことでしたら、どうぞ皆様、 即座に削除して下さい。 Katsumi Yamaokaさんの<yosubsdqvhg6.fsf@jpl.org>から >新村さん> *Compile-Log* と、*Compile-Log-Show* の2つです。 ---snip >普通は何かのプログラムが、オリジナルの関数機能を少し変えるため >advice ということを行なっているからです。これには byte-compie >が伴います。 釈迦に説法で、はなはだ申し訳ないのですが、山岡さんのページでバッ クトレースの取り方の説明を読んでいても考えさせられたのですけど、 オープンソースだからこそ、(誰が使うかわからない。ソフト製作とは 無縁の方も多いだろうし、そもそも、言語習得の時間があるのなら、や らねばならないことが山積している、官民の諸氏も多いでしょう)、些 細なことでも、(基本機能ではないとしても)困惑することのないよう に、デベロッパー的な情報収集機能は、取り外すことも可能であって欲 しいと思います。 gcc なんかが、デバッグ情報を埋めこめることと、ワーニングのレベ ルも設定できることを考えると、elisp の advice は、バッファではな く core のように外部のファイルに出しておくべきではと思います。 自分で直すなどと言うことは、規模が大きいものならば、とてつもなく 大変なスキルを要求するはずですから。 本旨とは違いますが、C++ で書かれた CJK-LyX という、TeX のフロン トエンドでも、コンパイルが通らない。見ると、ローカライズに必須の はずのメンバ関数が抜けている。g++ では、コンパイルさえ通らない、 string クラスを使っていて、独自のクラスに切り替えてやらねばなら ない。只使いたい人間には、大変な時間と労力を強いる結果になりかね ません。(なりました) 基本的に、開発するということは、ユーザーに負担を強いる、あるいは 使わないことを前提としているはずでは無いと思います。 無論、コンパイラに問題があることもあるでしょう。(gcc 2.96.X は、カーネルのコンパイルが安定するのに、2年近くかかっていたと記 憶しています。)複合した、ハードルがいくつもあるので、ユーザーか らの要望通りに、なるものでも無いとは、当然承知しています。 例の「伽藍とバザール」にも目を通してますが、気に入らないなら自分 で作れとは、書いていなかったと記憶しています。オープンソースのコ ミュニティーであっても、開発に参加してから注文をつけろとは、逆に 閉鎖的ではないでしょうか。 オープンソースだから、無料だとは、絶対言えないはずです。機材が 揃っていたにしても、個人であろうと、どこかの研究者であろうと、通 信費を含め、お互いに、貴重な時間と労力をかけるわけですから。 開発者だけが、奉仕していると言うならば、実際に費用をかけて運用し てみるユーザーは、利便を供与してもらうだけの信奉者というような位 置付けになるのでしょうか。それならば、不毛な関係だと思います。 商用の保証された高価な商品と別物であり、それ故各ディストリビュー ションを含めて、格安で提供しているではないかと言う意見もあるで しょう。以前、linuxconf について、GUI の設定ツールでも、同様の話 しになりました。私は、日本語化も含め、機能の充実を望みましたが、 他人様には、コマンドで処理できるものを、わざわざ使う必要もない し、第一機能面で「危険」だと。こういったシステムツールの GUI 化を否定するわけでは無いし、「作成してみたいぐらいだ」とのことで したが、その方が言葉に見合うツールの作成をしたのを見たことがあり ません。ローカライズも、機能の修正、新しい実装もです。 勿論、間違いのないように、これは、多大な貢献をされている、山岡さ んに対しての話しではありません。誤解のありませんように。 提供されているものを、我慢して使うというのは、かえってオープン ソースの趣旨に反するし、些細なこと(基本機能じゃないから、ギミッ クをメンテする気は無いよ。各個、不具合だと思うのなら、自前で修正 しなさいなら)ならば、一般に、黙って使用を中止する方も沢山いらっ しゃるのではないでしょうか。折角多大な労力を注いで作成されたもの であっても、進化の相乗効果がなければ、いつかは、より配慮あるもの に移行していくでしょう。これも、不毛な話しだと思います。 >(setq ad-default-compilation-action 'never) > >と書いておくと、運良く advice を行なうプログラムが compile する >ことを強制していなければ、それらのバッファは現れません。しかし、 >たぶん不運なことに、compile が行なわれない結果、新村さんが使う何 >かのプログラムの動作が遅くなってしまうでしょう。 この件、ご教示のとおりということでしょうから、絶句しました。バイ トコンパイルだからと言って、例え何かのベータ版を使うにしても、煩 わされるということですか。 個人的には、 UNIXであろうが、Windowsであろうが、Macであろうが、 コンパイル時には、gcc なら -Wall をつけて、ワーニングが全部消え てから、 -O2 ぐらいで最適化します。その時に、デバッグオプション もはずします。異論はあるでしょうけど、ワーニング=エラー である と、長らく言われ続けて来ましたから。周りから見て、機能に関係ない ことに、無駄な労力と時間を使ってと笑われるかもしれませんけど。 でも、何か問題の発生するプログラムは、ほとんどコンパイル時に警告 の出ていたものばかりというのは、あながち偶然では無いでしょう。 C,C++, inline asm はともかく、 Pascal,Fortran,Cobol ... 等は型 チェックも厳しいですから、古い歴史を持つ言語ほど、バグなどの潜在 率は低いように思います。 >あまり深刻ではない問題は、ある特定の個人にとっては障害かもしれま >せんが、それを作った人の常識では useful なのかもしれません。気に >しないというのが一つの解なのではないでしょうか? 基本的な動作と >は関係無いところで仕様変更または仕様を個人の好みによって切り替え >られるようにすることを要求するのは、する方もされる方もお互いに時 >間の無駄です。その時間をもっと有益な、端的に言えば lisp プログラ >ミングを習得して自分で改造すること、に当てましょう。:-) lisp は、亀のように遅くても、ゆっくり、あせらず、慣れていこうと は思います。私の概ねの主張、ポリシーは上記の通りです。 また、仕様変更を強要しているわけでもありません。山岡さんが、どの ように取られたかは判りませんが。 更に、個人の好みなどと取られると、大変残念です。それ故、「抑制」 方法が無いかどうかお聞きしたわけです。XEmacs ほど大規模で複雑な アプリケーションだと、本体の C ソースは勿論、elisp package もと ても高度ですから、手出し、改造ができるには、個人の資質もあって、 出来なくても不思議ではないと思いますけど、いかがでしょう。自分が 出来るから他人も出来て当然だというのは、ある意味、傲慢さが表に出 ていることに他ならないと感じます。 それならば、オープンコミュニティーではなく、クローズドに実質近い ものだと思います。正規のプログラマ経験者であって、lisp にも造詣 が深く、英語も堪能である。一体、そんな方は、PCを使うユーザーの中 に、どの程度いるものなのでしょう。 記事として、山岡さんへのリプライになってしまいましたが、今までの お話しは、全て私の抱く疑義。これについて、「瑣末」な論争をするつ もりも、そんな時間もありませんので、今回限り。 最後屁と取られるのなら、それで結構です。個人メールでも、応答は致 しません。 --- Atsushi Shinmura mail-to:GGB03631@nifty.ne.jp
Technical Details
Message-ID:
<3c9167d5.2571%GGB03631@nifty.ne.jp>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.mesh.ad.jp!newsgate1.web.ad.jp!news501.nifty.com!not-for-mailReferences:
<m0zo1bxibv.wl@nifty.ne.jp> <yosubsdqvhg6.fsf@jpl.org>Show Full Headers
Complete Article Headers
X-Google-Language: Japanese,JIS X-Google-Thread: 1107f7,ead4a2124c9ac90f X-Google-Attributes: gid1107f7,public X-Google-ArrivalTime: 2002-03-14 19:18:43 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.mesh.ad.jp!newsgate1.web.ad.jp!news501.nifty.com!not-for-mail From: Atsushi Shinmura <GGB03631@nifty.ne.jp> Newsgroups: fj.editor.xemacs Subject: Re: 不可解なバッファと、フレーム分割。 Date: Fri, 15 Mar 2002 12:18:16 +0900 Organization: General System Corp. Lines: 148 Message-ID: <3c9167d5.2571%GGB03631@nifty.ne.jp> References: <m0zo1bxibv.wl@nifty.ne.jp> <yosubsdqvhg6.fsf@jpl.org> NNTP-Posting-Host: nara003n019.ppp.infoweb.ne.jp Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Trace: news511.nifty.com 1016162314 8222 211.2.82.179 (15 Mar 2002 03:18:34 GMT) X-Complaints-To: - NNTP-Posting-Date: Fri, 15 Mar 2002 03:18:34 +0000 (UTC) In-Reply-To: <yosubsdqvhg6.fsf@jpl.org> X-Newsreader: Datula version 1.51.08 for Windows