|
From: <Bil...@pe...> - 2003-12-07 23:52:38
|
I also had this problem on MS Windows. I can notice no difference in the
concatenated ilisp-all.elc performance compared to having the individual
files and have not used ilisp-all.elc since before v5.12 was released. In
fact, I changed the icompile.bat file in CVS some time back to make it the
default to not build ilisp-all.elc under Windows. I agree with Bob that it
would be better to drop ilisp-all.elc altogether (or at least change the
default in the make file).
--
Bill Clementson
"Bob Rogers"
<rog...@rg.... To: ed...@ag...
org> cc: ili...@li...
Sent by: Subject: [Ilisp-help] Garbled documentation
ili...@li...
ceforge.net
12/07/2003 03:56 PM
From: Edi Weitz <ed...@ag...>
Date: Sun, 07 Dec 2003 21:07:36 +0100
With a very recent ILISP from CVS and FSF Emacs 21.2 on Linux I can
reproduce the following behaviour . . .
Now the contents of the *Help* buffer look rather strange:
M-q runs the command reindent-lisp
which is an interactive compiled Lisp function in
`ilisp-all.elc'.
(reindent-lisp)
fvar lisp-wait-p nil (#$ . -2260))
#@301 *T if all output goes to the inferior LISP rather than in a
pop-up window.
'(quote message) if you want output of one line to go to the echo area
(usually the Minibuffer) or to a pop-up window if more. You should
probably also set comint-always-scroll to T as well so that output is
always visible.
I see garbled documentation with ILISP functions, too. Is anybody else
having this problem?
Cheers,
Edi.
I can reproduce this, on essentially the identical configuration. The
output looks like an offset problem with the documentation strings; the
byte compiler replaces inline documentation strings with an integer
offset into the .elc file, and the elisp 'documentation' function
converts this back to the original string by reading the file starting
at that offset. The way ilisp-all.elc is made (concatenating all the
binaries) probably screws this up, though why it worked before is beyond
me.
For the time being, it should work to delete ilisp-all.elc, and then
do "make compile" again. "(require 'ilisp)" will then load the
individual .elc files.
This seems to undermine the whole point of having an ilisp-all.elc in
the first place. The idea (as I understand it) was to make ilisp load
faster by cutting down the overhead of opening separate .elc files. But
shutting off the byte-compile-dynamic-docstrings feature means that
emacs has to read and store all doc strings. I would argue for dropping
ilisp-all.elc altogether, rather than trying to make it work well both
ways. (FWIW, I don't use ilisp-all.elc on my ancient 300MHz system, and
I can't say I notice the difference.)
Comments?
-- Bob Rogers
http://rgrjr.dyndns.org/
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Ilisp-help mailing list
Ili...@li...
https://lists.sourceforge.net/lists/listinfo/ilisp-help
|