Internal error: lstream not open
23 years, 7 months
にしたま / NISHIDA Masakazu
にしたま / NISHIDA Masakazu
こんにちは、にしたま＠こまつし です。
;; To: semi-gnus-ja(a)meadow.scphys.kyoto-u.ac.jp
;; Cc: xemacs-beta-ja(a)xemacs.org
;; です。
User-Agent: Nana-gnus/6.13.9 SEMI/1.13.7 (Awazu) PGPGPG FLIM/1.13.2
(Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku)
(i386-unknown-freebsd3.2)
X-Gnus-Offline-Backend: Gnus offline backend utiliy v2.10b1 -
"Ahhhhhhh!!" with nnagent 1.0
な環境で、*Group* バッファから "1g" でメールのみを取得しようとすると
Internal error: lstream not open: #<INTERNAL OBJECT (XEmacs bug?)
(filedesc lstream) 0x8d21a80>
というエラーがでます。
その時の " *Message-Log*" は
Getting mail from the post office po:m_nisida＠pop.ca2.so-net.ne.jp...
Retrieving message 1 of 2 from pop.ca2.so-net.ne.jp...
Retrieving message 2 of 2 from pop.ca2.so-net.ne.jp...
Getting mail from po:m_nisida＠pop.ca2.so-net.ne.jp...done
Wrote /home/m_nisida/Mail/ml/mule-win32/1176
Wrote /home/m_nisida/Mail/ml/semi-gnus/1830
nnml: Reading incoming mail...done
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
nnml: Reading incoming mail...
Checking new news...done
Sending mails in spool ...
No messages in spool(/home/m_nisida/News/agent/nntp/news01.so-net.ne.jp/mail.out)
Sending mails in spool ... done.
Posting news in spool ...
No articles in spool(/home/m_nisida/News/agent/nntp/news01.so-net.ne.jp/news.out)
Posting news in spool ... done.
Finished fetching articles into the Gnus agent
Hang up line ...
Hang up line ... done.
Internal error: lstream not open: #<INTERNAL OBJECT (XEmacs bug?) (filedesc lstream) 0x8d21a80>
となっています。
再現性は、4回やって 3回エラーです。
エラーにならなかったのは、Nana-gnus を起動した直後に "1g" した時で、
{メール, ニュース}を読んだり書いたりした後に "1g" した時は必ずエラー
になってます。
このエラーを回避するには、どうしたら良いのでしょうか？
よろしく、お願いします。m(__)m
最後に *Backtrace* を付けます。
Signaling: (error "Internal error: lstream not open" #<INTERNAL OBJECT (XEmacs bug?) (filedesc lstream) 0x8f0b680>)
kill-buffer(#<buffer " *server news01.so-net.ne.jp nntp *nntpd**">)
nntp-close-server("news01.so-net.ne.jp")
gnus-close-server((nntp "news01.so-net.ne.jp"))
gnus-agent-close-connections()
gnus-agent-toggle-plugged(nil)
gnus-offline-set-unplugged-state()
gnus-offline-after-get-new-news()
run-hooks(gnus-offline-after-get-new-news)
apply(run-hooks gnus-offline-after-get-new-news)
gnus-run-hooks(gnus-after-getting-new-news-hook)
gnus-group-get-new-news(1)
gnus-offline-gnus-get-new-news(1)
call-interactively(gnus-offline-gnus-get-new-news)
--
NISHIDA Masakazu
E-mail : m_nisida(a)ca2.so-net.ne.jp
- 2 participants
- 2 comments
Re: Cannot open load file: static
23 years, 7 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
>>>>> In <yosu1zanamv3.fsf(a)jpl.org>
>>>>> "山岡" = Katsumi Yamaoka <yamaoka(a)jpl.org> wrote:
山岡> えと、守岡さんがおっしゃっているのはおそらく 21.1 と 21.2 で共用 (*)
山岡> できる APEL を作ることだと思います。
はい。それは必要条件です。
山岡> (*) 現在の APEL 9.22 を install-package して、21.1 と 21.2 で共用する
山岡> ことはできません。
やっぱそうなんですね。(;_;)
山岡> 問題は今まで sumo 付属の APEL を使っていた人の環境で問題が起きな
山岡> いかどうかですが、そういう方に検証していただかないとだめですよね。
それが望ましいですね。
山岡> ;; package を作るだけならそう難しくないんですが。
まったく。
ややこしいのが、
・alist.el は package じゃなくて kernel（他にもありましたっけ？）
・XEmacs 21.1/21.2 で使わない module は削る
・Mule と非 Mule で package を共有しなければならない
・非 Mule でかつ file-coding 付の場合に coding-system 機能がちゃんと使
えなければならない
つまり、
21.1 without Mule
21.1 with file-coding
21.1 with Mule
21.2 without Mule
21.2 with file-coding
21.2 with Mule
の６通りの環境で動かないといけないのです（21.2 with UTF-2000 も含め
ると７通り）。
;; pces 化はこれを考慮して行ったんです。
あと、tm で動かないといけないなんてのもあります（tm 8.* をXEmacs の
package にして、tm 7.108 を追い出し、FLIM に置き換えられれば少しは楽
になります）。
ということです。
package の場合、*.elc の互換性が要求されるので、頭が痛い訳です。
--
===『幾千億の分子に分かれても ========================================
決して忘れない。
この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo(a)etl.go.jp> =====
- 1 participants
- 0 comments
Re: Cannot open load file: static
23 years, 7 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
>>>>> <876700b83r.fsf(a)nakaji.tutrp.tut.ac.jp> にて
>>>>> “中治”= nakaji(a)nakaji.tutrp.tut.ac.jp (中治 弘行) さま曰く:
中治> static.el は APEL の一部です。それに、最新の APEL, FLIM, SEMI を
中治> 使うなら、xemacs-sumo package に入っている apel は消してしまうの
中治> が良いと思います。
多分、この状況は良くないと思うので、最新の APEL に対応する apel
package を作成して xemacs-patches に送って頂ける奇特な方はいらっしゃい
ませんか？
;; あるいは、Steve 好みの XEmacs に特化した APEL 実装を作ってくださる
;; のでも OK です。
--
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┓
┃『開ける価値の無い ┃守岡 知彦 (MORIOKA Tomohiko) ┃
┃ 衣裳ダンスの扉は無い』┃ E-mail: <tomo(a)etl.go.xn--jp>-ls4a
┗━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━┛
- 3 participants
- 2 comments
Re: XEmacs 21.1.7 auto coding-system detection
23 years, 8 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
>>>>> <87puyjesir.fsf_-_(a)dp50.ecc.u-tokyo.ac.jp> にて
>>>>> “Yoshiki”= Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> さま曰く:
Yoshiki> > これを当てる前は setup-japansese-environment() か
Yoshiki> > set-language-environment() を呼んだときに endless loop に陥っ
Yoshiki> > ていました。
Yoshiki> >
Yoshiki> > これを当ててからというもの、euc-jp や shift_jis な file は
Yoshiki> > コード判別ができないようです。autoconv-xmas を使えば OK の
Yoshiki> > ようです。
（略）
Yoshiki> を評価すれば判別は普通に行われるようになると思います。
Yoshiki> たぶん、他の言語環境でも壊れていると思いますので、それを修正
Yoshiki> してから xemacs-patches に送ります。
多分、元凶は私だと思うので、とりあえず
皆さんごめんなさい。
と謝らせて頂きます。(^_^;;;
補足すると、従来の language environment は Emacs 20.1/20.2 相当のもの
で、基本的に各言語毎の設定用関数で設定していました。しかしながら、
XEmacs のタイ語化に際し、code 流用の都合から、language environment を
Emacs 20.4 相当にしました。この時、CD-ROM の締め切りが迫っていたため、
過去との互換性とかに気を配る余裕がなかったのです（他の締め切りもあった
し）。patch を死蔵するよりはとりあえず xemacs-patches に送って、各開発
者の方々の御判断に任せるといったつもりだったんですが…。
さて、Emacs 20.4 相当の language environment ですが、
Yoshiki> # language-info-alist を使って設定しているのがなかなかわから
Yoshiki> # なかった。(^^;;
のように基本的に language-info-alist に設定した属性で各種設定が表現さ
れており、各言語毎の設定用関数で hard coding する必要がなくなりました。
このことは明らかに前進だと思われます。
問題の根本は Mule の kernel の一部まで mule-base という package に分け
られていて、XEmacs 21.1 と 21.2 という異なる Mule 実装間で共有しなけれ
ばならないことだと思います。１つの解は XEmacs Mule の進化を止めること
ですが、これは私としては残念な解です。
まあ、頑張れば何とかなるとは思いますが、そういうことを今後もやらないと
いけないんだとしたらなかなか面倒なことではあります。
今回の場合、私は XEmacs 21.1 にも新しい language environment の枠組を
入れるのが良いと思うのですが、反対意見も理解できます。
現在、kernel か mule-base かは dump するか autoload されるかで分けてい
ますが、もう少し論理的な単位で分け、現在 mule-base に入っている module
の大半を kernel に戻すのが良いのではないかと思います。
;; あるいは、従来 dump していた部分を、mule-base に移すという方向も考
;; えられます。但し、起動時に既に言語環境の設定がないと困るので、各
;; module を起動時に load するための枠組を考える必要があります。（拡張
;; 性の観点では、多分、この方法が優れていると思います。但し、Emacs と
;; の sync はしにくくなります）
ところで、今回の問題を現在の枠組の中で解決するなら、
(a) XEmacs 21.2 に対して行った修正の内、XEmacs-UCS などを除く部分を
21.1 にも施す
(b) mule-base の setup-*-environment の定義を 21.1 と 21.2 で分け、
21.1 用の互換 module 群を設け、21.1 では互換 module で定義した従来
型設定用関数を呼ぶ
ということになりましょうか。多分、(a) 案が良いと思いますが、(b) 案を採
らざるを得ないかも知れません。この場合、完全なものを作るのはそんなに容
易ではなく（というか、言語が沢山あるので面倒）、かえって不安定になるよ
うな気もしますが…。
;; 時間と国際人間競争力が足りないので、具体的な行動を起こせず申し訳あ
;; りません。(^_^;
--
感じてたことさ ; 守岡 知彦 (MORIOKA Tomohiko)
ずっとずっと前から ; Email: <tomo(a)m17n.org>
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- 2 participants
- 1 comments