5:23 p.m.
>>>> "Paul" == Paul Krause
<pkrause(a)ibelong.com> writes:
Paul> This bug report will be sent to the XEmacs Development Team,
Paul> not to your local site managers!!
Paul> Please write in English, because the XEmacs maintainers do not have
Paul> translators to read other languages for them.
Paul> In XEmacs 21.2 (beta34) "Molpe" [Lucid] (i586-pc-win32) of
Paul> Fri Jun 09 2000 on NEVERYON configured using `configure
Paul> UNKNOWN'
I experienced this too, in (emacs-version)
"XEmacs 21.1 (patch 10) \"Capitol Reef\" [Lucid] (i386-pc-win32) of
Fri Jun 09 2000 on ZJ75T"
I haven't investigated but this requirement doesn't seem right.
Anybody know the story?
Adrian
Paul> Please describe exactly what actions triggered the bug
Paul> and the precise symptoms of the bug:
Paul> In a CVS buffer, type 's' for cvs-status of a file. Attempt to load
Paul> cvs-status library fails with: Cannot open load file: mule
Paul> `pcl-cvs-version' is a variable declared in Lisp.
Paul> -- loaded from "pcl-cvs-defs"
Paul> Value: "v2_9_9"
Paul> Lisp Backtrace:
Paul> Signaling: (file-error "Cannot open load file" "mule")
Paul> signal(file-error ("Cannot open load file" "mule"))
Paul> load("mule" nil t nil)
Paul> require(mule)
Paul> load-internal("cvs-status" nil nil nil binary)
Paul> load("cvs-status" nil nil nil)
Paul> cvs-status-mode()
Paul> cvs-temp-buffer("status")
Paul> cvs-mode-do("status" nil nil :dont-change-disc t :show t
:postproc nil)
Paul> #<compiled-function nil "...(19)" [cvs-mode-do
"status" flags nil :dont-change-disc t :show :postproc cvs-auto-remove-handled
status (...)] 11>()
Paul> #<compiled-function nil "...(15)" [commandp -cvs-mode!-fun
call-interactively] 2>()
Paul> cvs-mode!(#<compiled-function nil "...(19)" [cvs-mode-do
"status" flags nil :dont-change-disc t :show :postproc cvs-auto-remove-handled
status (...)] 11>)
Paul> #<compiled-function (flags) "...(4)" [cvs-mode!
#<compiled-function nil "...(19)" ... 11>] 2 ("c:\\Program
Files\\Xemacs\\xemacs-packages\\lisp\\pcl-cvs\\pcl-cvs.elc" . 49670) (list
(cvs-flags-query ... "cvs status flags"))>(nil)
Paul> call-interactively(cvs-mode-status)
Paul> Recent keystrokes:
Paul> e RET C-x 1 C-n C-n C-n C-n C-n C-n C-p C-k C-k C-k
Paul> C-k C-k C-k C-k C-n C-n C-n C-n C-n C-n C-n C-n C-n
Paul> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p
Paul> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-x k RET q
Paul> M-x s e t SPC v a SPC RET d e b SPC o n SPC e SPC RET
Paul> n i l RET M-x s e t SPC v a SPC RET d e b SPC o n SPC
Paul> e SPC RET t RET s misc-user
Paul> Recent messages (most recent first):
Paul> Entering debugger...
Paul> Loading cvs-status...
Paul> Loading mail-abbrevs...done
Paul> Loading mail-abbrevs...
Paul> Loading emacsbug...done
Paul> Loading emacsbug...
Paul> Loading view-less...done
Paul> Loading view-less...
Paul> ? not defined.
Paul> M-? not defined.
6:06 p.m.
New subject: load cvs-status requires mule
Adrian Aichner writes:
Paul> In a CVS buffer, type 's' for cvs-status of a
file. Attempt to load
Paul> cvs-status library fails with: Cannot open load file: mule
I experienced this too, in (emacs-version)
"XEmacs 21.1 (patch 10) \"Capitol Reef\" [Lucid] (i386-pc-win32) of
Fri Jun 09 2000 on ZJ75T"
I haven't investigated but this requirement doesn't seem right.
Anybody know the story?
I've built the pcl-cvs package from sources and not had this problem
(I run a mule-less XEmacs).
I suspect that the binary-kit packages must have somehow gotten
infected with Mule; I think it has to do with how they were built,
rather than the pcl-cvs code itself, which has no Mule dependencies.
Oops, just after writing that last sentence I did a
"grep mule pcl-cvs/*el" and came up with this:
;; chars sets. Ripped from cvstree
(defvar cvstree-dstr-2byte-ready
(when (featurep 'mule)
(if (boundp 'current-language-environment)
(string= current-language-environment "Japanese")
t)) ; mule/emacs-19
in cvs-status.el... this is the only reference to Mule in the entire
pcl-cvs package. Is this possibly the source of the problem?
7:20 p.m.
New subject: load cvs-status requires mule
>>>> "cgw" == Charles G Waldman
<cgw(a)fnal.gov> writes:
cgw> I suspect that the binary-kit packages must have somehow
cgw> gotten infected with Mule; I think it has to do with how they
cgw> were built, rather than the pcl-cvs code itself, which has no
cgw> Mule dependencies.
No direct dependencies. But it requires lots of stuff, such as cl.el,
which requires cl-macs.el, which has a rather interesting hack that
seems to require a random feature (= (car features)) from the emacs
that loads it. This maybe then gets compiled into the binaries. The
feature that gets required _should_ be a 'cl-xxx, I think, but I don't
know how to check that.
If in fact it can be 'mule, and this is the source of the spurious
require, anything that uses cl.el could suffer from the same problem.
And you really have to trace _all_ the requires and autoloads.
(Somebody started to write a script to do all that tracing at one
time. Do I recall ... ?)
cgw> Oops, just after writing that last sentence I did a "grep
cgw> mule pcl-cvs/*el" and came up with this:
cgw> ;; chars sets. Ripped from cvstree
cgw> (defvar cvstree-dstr-2byte-ready
cgw> (when (featurep 'mule)
cgw> in cvs-status.el... this is the only reference to Mule in
cgw> the entire pcl-cvs package. Is this possibly the source of
cgw> the problem?
I don't see how it could be, it's explicitly conditioning on the
presence of Mule, which is known to required for lots of code to work
at all.
>>>> "APA" == Adrian Aichner
<aichner(a)ecf.teradyne.com> writes:
APA> When should they be BUILD_WITHOUT_MULE = t ?
All that BUILD_WITHOUT_MULE = t does is inhibit building the packages
in the subdirectory mule AFAIK, to prevent a no-mule xemacs from
choking on the stuff in there. I don't see how this would make a
difference to what gets require'd by compiled packages.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:08 p.m.
New subject: load cvs-status requires mule
Stephen J. Turnbull writes:
No direct dependencies. But it requires lots of stuff, such as
cl.el,
which requires cl-macs.el, which has a rather interesting hack that
seems to require a random feature (= (car features)) from the emacs
that loads it.
Fascinating!
And you really have to trace _all_ the requires and autoloads.
(Somebody started to write a script to do all that tracing at one
time. Do I recall ... ?)
I think you may be referring to a project which I started working on
way back when I was a newcomer to the XEmacs project. I was actually
trying to do something a little more ambitious than just tracing
requires and autoloads - I was trying to devise a way to compile a
listing of every symbol which was defined in every file, and a way to
verify that if file X used symbol S defined in file Y, it did a
(require 'Y). This was around the time Steve B. was breaking
everything out into packages, and my work was intended to be a tool to
aid in this work.
I got bogged down and gave up on this, because I ran into
complications. I thought at first I could just scan files for defun,
defvar, defcustom, etc, but eventually realized that since you can
define your own macros which provide new ways to define symbols (e.g.
`defvoo' as used in gnus) simple scanning wasn't good enough. So I
gave up... maybe now that I've learned a lot more about XEmacs and
elisp it's time to scale back the scope of what I was trying to do and
pick this project up again.
8704
days inactive
8704
days old
3 comments
3 participants
participants (3)
-
Adrian Aichner -
Charles G Waldman -
Stephen J. Turnbull