APEL 問題、再燃?
守岡 知彦 / MORIOKA Tomohiko
tomo @ etl.go.jp
1999年 11月 4日 (木) 15:37:18 JST
>>>>> In [apel-ja : No.00008]
>>>>> "中島" = Mikio Nakajima <minakaji @ osaka.email.ne.jp> wrote:
中島> 多分、まだ only member can post 状態だと思うので、forward して
中島> おきます。
;; もうすぐ直ると思うので、もうしばらくお待ちください。
;;; たくさんまたせてごめんなさい。:-P
中島> At Wed, 03 Nov 1999 23:55:24 +0900,
中島> Makoto MATSUSHITA wrote:
minakaji>>> 一方で APEL のversion 情報をポータブルに判断する方法が提供
minakaji>>> されていないので、少し面倒な気がします。
中島> >
中島> > 以前からの疑問の 1 つなのですが,特定の version 以降のものを使っ
中島> > て欲しい,というような代物でありながら,program 側で version
中島> > を特定できない(つまり,SKK が現在使える APEL の version を知る
中島> > ことができない),というのはとっても不便だと思うのですが,どう
中島> > して APEL は自分自身の version がいくつなのかを教えてくれない
中島> > のでしょう?
個人的にはどうして不便なのかが判らないですが、理由はないと思います。必
要なら付ければ良いんじゃないでしょうか?
;; 敢えて理由を考えれば、どこに何を付けるかに関して良い案が思い付かな
;; かったからかも知れません。
;;; code-name に関しては、APEL に問題を起こす元凶の1つが存在する AIST
;;; 最寄りの駅がある JR 常盤線を検討してましたが(^_^;;;
ただ個人的には version 名による判定は信用できないです。
むしろ、各機能が実際に存在しているかを判定した方が良いでしょう。
中島> > 過去に存在していた library (file)が消滅したりするのは,まさし
中島> > く互換性問題の 1 つだと思います.特定の奴を require しようとし
中島> > たらすでに新しいAPEL では存在していない(違う filename に mv,
中島> > あるいは rm されて違うファイルに含まれる等)事例は過去にいろい
中島> > ろあったと記憶しています.
中島> >
中島> > そういうとき,APEL がどういう実装をしているかまでさすがに私は
中島> > 知らないので,「同じ APEL という名前なのに全然違うものがある」
中島> > ようにしか見えません.
中島> >
中島> > # もちろん,内部構造の変化からしかたがない点があるのはわかって
中島> > # います.
そういう事例は記憶していません。
特に emu は昔も今も存在しています。
できれば具体例が知りたいです。
また、基本的に分割の方向に進んでいます。
emu-18 のような sub module が消えたり改名されることは今後もあると思い
ますが、それを直接 require するのは保証外ですから、APEL の責任ではない
と思います。
界面の明確化に関しては APEL の責任だと思うので、順次改善すべきでしょう。
中島> > もちろんこれは library の名前(filename)を明示的に指定して
中島> > require しないといけない(という,そもそも Emacs に依存する)問
中島> > 題ではあるわけですが‥‥個人的にはどうしてこういう問題が解決さ
中島> > れないままなのだろうかと,妙に疑問に思っています(何か難しいこ
中島> > とがあるのならばごめんなさい).
うーんと、emu とか poe といった feature は界面の1つであると思うので、
それを require できることは保証すべきでしょう。
;; なお、feature は必ずしも file 名と対応しなければならないということ
;; はなく、両者は別概念です。
個人的な感想を述べれば、APEL という system の技術的な問題が対立点なの
ではなくて、閉鎖指向と共同指向という社会 system 観の対立なんだと思いま
す。特に、日本では『国際競争人間力』、互いに対立したり協調しながら
system を協同して作り上げて行く力、が足りない人や、そういうのにコスト
を払うのを嫌う人が多いように思われます。例えば、assignment や
disclaimer を集めるのを嫌って FSF へ協力するのをいやがったり、GPL より
も BSD licenseを好んだり、意味もなく一体型化したり、patch を送らないと
か、政治面や社会面、人間関係でのコストを払うことをいやがる人が少なくな
いようです。
;; そう、どちらかというと私もめんどくさがりの方で皆様に御迷惑をお掛け
;; してごめんなさい。(^_^;;; もっと国際競争人間力を増やさないと行けな
;; いと思っているのですが、元来の筆不精と英語力のなさでなかなか改善さ
;; れてないです。ごめんなさい。あと、一言多いのもやめようと思ってます。
g新部さんはそういうのは free software community を維持するための「税金」
のようなものだというお話を良くされています。私も同感する所が多いです。
ただ同時に「他人(他の community)とは無関係にただ program だけを書き
たいんだ」という気持もあるし、性格的な得手不得手もあるでしょうから、何
とかいろんな力・嗜好をうまく共存させる道はないかなと思ってはいます(で
も、なかなか system には結び付かないのですが)。
;; また、free software が社会的に無視できないものになって行くにつれ、
;; 権利関係の問題を解決するという難問も無視できなくなって行くと思いま
;; す。上司とか官僚機構とどうつき合って行くかという問題でもあります。
Mule Project のモットー(というか、戸村さんのモットーかな?)なんです
が、おそらく我々にできるのは機会を提供することだけです。APEL に関して
いえば、APEL というような可搬性向上を支援する部品の存在を認めて頂ける
限り、その改善に関する意見を受け入れ、また、開発者として取り込んで行く
ことです。tm/FLIM/SEMI からの独立性を保証するために、まず tm/SEMI から
分離し、mailing list も分けました。また、私の独善性を排するために管理
/release も私から集団指導体制に移行し、既に山岡さんの名前で release さ
れています。このように少なくとも APEL 開発陣は考慮し努力していると思い
ます。
;; こうしたことに積極的に協力してくださった皆様に感謝します。
ところで今後ですが、先日 RMS と会って話した時(*1)、GNU Emacs の
maintainer になった(*3) Gerd Moellmann さん(*4) が Emacs 21.1 に向けて
SEMI の integration を行うということを伺いました。また、実際、Gerd さ
んからの mail を受け取りました。
これが実現すれば何らかの形で APEL が取り込まれる可能性があります。
;; 但し、Emacs 21.1 が release されるのは少なくとも半年先、多分、1年
;; 後ぐらいだと思います。
こうした事情も少し頭に止めておくと良いかも知れません。
(*1) RMS がこけて note-PC が壊れる前の話(*2)
(*2) そのあとひょんなことから g新部さんとともに RMS の環境を修復する羽
目になる。当然、RMS の頭の中からそれ以外のことは消えるし、私は
GNU goods の入った大量の段ボールとともに三菱総研に置き去りにされ
たり、夕食も食べれなかったり、終電に遅れかけたり、いろいろ貴重な
経験をしました。おかげで hack や hacker に関する理解を深められた
気がします。:-) そう、hack とは単に計算機に限らない人間の行動様式
なのです。例えば、部屋が lock out されかけたら椅子を置いて block
したり、note PC を思いきり良く分解したり、とりあえずそこに hack
value を見付けたら、その面白さに集中するという態度です。当然、他
人に迷惑はかけますが、それを許してもらえる人柄も重要です。:-)
;; 戸村さんや半田さんも真の hacker だと思います :-)。でも、私は全
;; 然修行が足りないかな。
(*3) 単に雑用係を押しつけられたという説もあり(^_^;
(*4) New display engine の作者
--
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │ ─ / ─ ┼─ ┬ ─ ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo @ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
More information about the APEL-ja
mailing list