2:50 p.m.
Hi,
In the 21.5 beta series the elc-files are distributed in the
tar-ball. Is there some rational for that?
I haven't analyzed all tar-balls but it seems like 21.5.32 and 21.5.33
have elc-files that refuses to load under a no mule XEmacs. Is this
because of a change in the byte compilation or that a mule XEmacs was
used when the distribution was prepared?
This breaks the build for a user who wants a no mule version in maybe
not an obvious way. The workaround isn't hard but you need to remove
the elc files before the build either by using a shell command or
doing "make beta", which I believe performs the proper cleaning
without damaging anything.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:43 p.m.
Mats Lidell writes:
In the 21.5 beta series the elc-files are distributed in the
tar-ball. Is there some rational for that?
It's been that way for 20 years. I just haven't bothered to change
it. It's never been reported as a problem until very recently, not
even 13 years ago when most people built --no-mule.
If you go through the archives in the last year or so, ISTR a similar
thread, but don't know when offhand.
I haven't analyzed all tar-balls but it seems like 21.5.32 and
21.5.33
have elc-files that refuses to load under a no mule XEmacs.
Which ones, and in what way do they refuse to load?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:27 p.m.
On Sun, 09 Jun 2013 02:43:17 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Mats Lidell writes:
> In the 21.5 beta series the elc-files are distributed in the
> tar-ball. Is there some rational for that?
It's been that way for 20 years. I just haven't bothered to change
it. It's never been reported as a problem until very recently, not
even 13 years ago when most people built --no-mule.
It is relatively new. 21.5.30 builds "normally" for me.
If you go through the archives in the last year or so, ISTR a similar
thread, but don't know when offhand.
> I haven't analyzed all tar-balls but it seems like 21.5.32 and
> 21.5.33 have elc-files that refuses to load under a no mule XEmacs.
Which ones, and in what way do they refuse to load?
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/fontl-hooks.elc...
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/auto-show.elc...
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/paragraphs.elc...
*** Error in XEmacs initialization
(error "Loading this file requires xemacs, mule")
*** Backtrace
really-early-error-handler((error "Loading this file requires xemacs,
mule")) signal(error ("Loading this file requires xemacs, mule"))
# bind (args datum)
cerror("Loading this file requires xemacs, mule")
apply(cerror "Loading this file requires xemacs, mule" nil)
# bind (args datum)
error("Loading this file requires xemacs, mule")
(or (and (featurep (quote xemacs)) (featurep (quote mule))) (error
"Loading this file requires xemacs, mule"))
The error seems to be in bytecomp.el.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
midnight
>>>> Sean MacLennan <seanm(a)seanm.ca> writes:
It is relatively new. 21.5.30 builds "normally" for me.
Yes, that is in sync with my limited investigation. The offending elc
files are in 21.5.32 and 21.5.33.
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/paragraphs.elc...
*** Error in XEmacs initialization
(error "Loading this file requires xemacs, mule")
[...]
Yes, this exactly the problem. The elc files checks on load whether
the binary is mule enabled and if not exits.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:18 a.m.
Sean MacLennan writes:
The error seems to be in bytecomp.el.
Oh, that's our resident Mule Nazi, then. He believes it's OK to cause
pain for non-Mule users (he prefers the interpretation that they have
elected to feel pain, so it's not his fault if his changes seem to be
associated with their pain).
I'm not comfortable messing with bytecomp.el, and he is unlikely to
have either the time or the inclination to fix this. So I think for
the next beta I'm just going to go ahead and change to --with-mule=yes
by default, and insert a warning about the .elcs in Installation for
--without-mule builds, and note it in PROBLEMS.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:41 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Oh, that's our resident Mule Nazi, then. He believes it's OK
to cause
pain for non-Mule users [...]
pun aside - What is the story?
I'm not comfortable messing with bytecomp.el, and he is unlikely
to
have either the time or the inclination to fix this. So I think for
the next beta I'm just going to go ahead and change to --with-mule=yes
by default, and insert a warning about the .elcs in Installation for
--without-mule builds, and note it in PROBLEMS.
Why not just not include them and let them be built as part of the
build process? It takes a little more time but it will always be
right. This is what I intend to do for Gentoo anyway. I can't see any
other good option.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:44 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Oh, that's our resident Mule Nazi, then. He believes it's OK to cause
> pain for non-Mule users [...]
pun aside - What is the story?
Because no-Mule XEmacs has no facilities for dealing with multibyte or
widechar charsets, no-Mule XEmacs can (Aidan would say "is likely to")
corrupt files encoded that way. Aidan takes the extreme position that
therefore no-mule XEmacs is fundamentally broken by design, and he has
no obligation to support it when he makes changes.
I disagree; on the one hand, no-mule XEmacs is a perfectly good binary
editor, and that works fine for some important special cases in text
editing. On the other, the fact that the changes he makes in Mule
affect the no-Mule build indicates to me that Mule assumptions about
implementation are leaking into more and more parts of XEmacs. I
think that is only going to make it harder to change the internal
encoding to Unicode, and harder in general to maintain XEmacs.
> I'm not comfortable messing with bytecomp.el, and he is
unlikely to
> have either the time or the inclination to fix this. So I think for
> the next beta I'm just going to go ahead and change to --with-mule=yes
> by default, and insert a warning about the .elcs in Installation for
> --without-mule builds, and note it in PROBLEMS.
Why not just not include them and let them be built as part of the
build process?
For several reasons. First:
It takes a little more time but it will always be right.
is actually false for repeated builds from the same source. If you do
a Mule build in-tree, then a no-Mule build, the same thing will
happen. If you have srcdir Mule builds and no-Mule builds using the
same source tree, either the Mule build will be buggy because no-Mule
can't compile those files correctly but there's no indication of the
problem, or the no-Mule build will fail in the same way. A warning
needs to be issued, or the no-Mule build should force "make beta"
somehow.
This is what I intend to do for Gentoo anyway. I can't see any
other good option.
That's the best option for distro builds, of course, and some distros
(Debian) require it as policy. But if (like Debian) you try to have
Mule and no-Mule binary package installations co-exist in the same
system, now you have to distribute separate Mule and no-Mule
"xemacs-common" packages; you can't just build a suite of binaries
with different features if the feature is Mule.
The other reasons for fixing this bug is that it *is* a bug.
1. Lisp should degrade gracefully in the presence of missing
features, with a "no such function" error. It shouldn't refuse to
work entirely.
2. Lisp should not behave differently when interpreted and compiled.
It's true that Mule is a special case: no other configurable feature
pervades all of XEmacs in that way. But special cases aren't special
enough to break these rules. It really should not be harmful to
distribute pre-built Lisp and Info, and that has been the traditional
format. Finally:
3. Completely removing no-Mule is still not really an option. There
are some use cases (processing gigabyte log files, for example)
where no-Mule is much faster. It's even possible to use a no-Mule
XEmacs to edit non-ASCII characters in UTF-8 files in a UTF-8
terminal window. It's about as pleasant as using say nano, and
the risk of corruption is high, but it's possible.
Regards,
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:49 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
is actually false for repeated builds from the same source. If you
do
a Mule build in-tree, then a no-Mule build, the same thing will
happen. [...]
Agreed. Removing the elc-files is just fix that does not solve the
general problem that the you should be able to reconfigure and just
make and get a proper result.
I don't know if there is some way to tie a (re)configure to some
action or if some state-file with whether last build was a mule-build
or not is the way to go. Suggestions are welcome.
That's the best option for distro builds, of course, [...]
I'm afraid that the problem is worse than that. It seems like that
during the build the load of startup.el changes the path so that the
build after that starts to load from
/usr/share/xemacs-21.5-b33/lisp/... ouch!
Excerpt from build log:
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/modeline.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/cus-file.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/startup.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/misc.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/loadhist.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/files.elc...
...
Scary isn't it. During the build of the binary we should only load
files from the sources and not look around in what is installed
on the machine, right?
Suggestions are welcome on how to solve this.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:20 p.m.
>>>> Mats Lidell <matsl(a)xemacs.org> writes:
Sorry for following up on my own post but I really need som help on
this one.
I'm afraid that the problem is worse than that. [...]
Excerpt from build log:
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/modeline.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/cus-file.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/startup.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/misc.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/loadhist.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/files.elc...
...
When we are busy loading elc-files for the creating a dump the load of
startup change the path(!?) and we start loading files from the file
file system that might not be related to this build as all.
I guess stopping the path change in startup might cause other problems
like we end up with a bad load-path. Maybe startup shouldn't be dumped
or something? Hmm... Help is really, really appreciated on this one.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:09 p.m.
New subject: Loading startup changes load-path? [was: elc-files ... break build]
Mats Lidell writes:
>>>>> Mats Lidell <matsl(a)xemacs.org> writes:
Sorry for following up on my own post but I really need som help on
this one.
> I'm afraid that the problem is worse than that. [...]
> Excerpt from build log:
> Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/modeline.elc...
> Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/cus-file.elc...
> Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/startup.elc...
> Loading /usr/share/xemacs-21.5-b33/lisp/misc.elc...
> Loading /usr/share/xemacs-21.5-b33/lisp/loadhist.elc...
> Loading /usr/share/xemacs-21.5-b33/lisp/files.elc...
What's happening is that merely loading "startup" changes load-path.
I see that in my build, but for me it changes load-path to something
harmless (it adds the symlink $blddir/lisp -> $srcdir/lisp).
Resetting load-path at dump time is apparently intentional; see the
comment on the call to `startup-setup-paths' around line 1710 in
startup.el. I don't have time to look into it further today, and
probably not until the weekend. You could try pinging Mike.
Did you post your Installation file? If not, would you do so? I
suspect you have an explicit setting for lisp-directory. Try to avoid
that; setting --datarootdir=PARENT-OF-LISP should be sufficient, and
probably would work around this problem.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:33 p.m.
New subject: Loading startup changes load-path?
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Did you post your Installation file? If not, would you do so? I
suspect you have an explicit setting for lisp-directory. Try to avoid
that; setting --datarootdir=PARENT-OF-LISP should be sufficient, and
probably would work around this problem.
Yes datadir is set to /usr/share. I guess that is why I don't see the
problem in my in my own builds when I switch between mule and
no-mule.
The error is in the gentoo ebuild which sets these things for the
install. I haven't looked into how these variables like datadir works
for us so I'll have to do that. Thanks for spotting this. Now I have
something to go on.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:44 p.m.
New subject: Loading startup changes load-path?
Mats Lidell writes:
The error is in the gentoo ebuild which sets these things for the
install. I haven't looked into how these variables like datadir works
for us so I'll have to do that. Thanks for spotting this. Now I have
something to go on.
--datarootdir=${prefix}/share/xemacs-${version} should be all you need
for runtime resources, except that modules of course need to be in
${prefix}/lib or perhaps ${prefix}/libexec. You may need to specify
--infodir and --mandir, though.
All the information you need about how these variables work is in
xemacs --help. Note that the GNU standard directory stuff is not in
the same place as the XEmacs-specific stuff like --lispdir.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:21 a.m.
New subject: Loading startup changes load-path?
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Mats Lidell writes:
> The error is in the gentoo ebuild which sets these things for the
> install.
I was wrong. It seems that the problem occurs already in the link
phase. I didn't read the log properly.
The odd thing is that I can't reproduce it in the development
structure "/src/xemacs/..." although I have
"/src/xemacs/share/xemacs-21.5.33/" there as well of course. So it
should likewise start to load from there unless there is something
special about "/usr/share/...". I'm obviously missing something here.
When I'm on a stable line I'll try to upload the build log so you can
have a look!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:56 a.m.
New subject: Loading startup changes load-path?
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Mats Lidell writes:
>> The error is in the gentoo ebuild which sets these things for the
>> install.
I was wrong. It seems that the problem occurs already in the link
phase. I didn't read the log properly.
The odd thing is that I can't reproduce it in the development
structure "/src/xemacs/..." although I have
"/src/xemacs/share/xemacs-21.5.33/" there as well of course. So it
should likewise start to load from there unless there is something
special about "/usr/share/...". I'm obviously missing something here.
When I'm on a stable line I'll try to upload the build log so you can
have a look!
Well, the most recent Gentoo didn't build correctly for me. I'm
pretty sure it's because I haven't pushed the change I recommended
yet; fixing that fixed the build. Maybe assumed I did, or you forgot
the patch on Gentoo? Anyway, I'll push soon (hours).
The build logs are probably useful, but I'd also like to see
both Installations (the one configured for /usr and the one configured
for /src/xemacs) as a quick summary.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:38 a.m.
New subject: Loading startup changes load-path?
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Well, the most recent Gentoo didn't build correctly for me.
If you are talking about the 21.5.33 version in gentoo that is the one
I'm trying to fix. The problem has been around from 21.5.31 I guess
and the cause is probably the "bug" you are talking about. (If I
follow this thread correctly) you mean loading mule vs non mule elc
files in either version of the binary.)
[...]
However IMHO it is not correct to load files outside of the source
tree while building the binary and the dump. The build process should
not use /usr/share, only install there.
The build logs are probably useful, but I'd also like to see
both Installations (the one configured for /usr and the one configured
for /src/xemacs) as a quick summary.
When I'm back on a stable wire I can supply them.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:13 p.m.
New subject: Loading startup changes load-path?
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Well, the most recent Gentoo didn't build correctly for me.
If you are talking about the 21.5.33 version in gentoo that is the one
I'm trying to fix.
Yes.
However IMHO it is not correct to load files outside of the source
tree while building the binary and the dump. The build process should
not use /usr/share, only install there.
Agreed, we need to fix that, but it's not clear to me yet how to do so
since I haven't reproduced yet.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:56 a.m.
New subject: Loading startup changes load-path?
Stephen J. Turnbull writes:
I'm pretty sure it's because I haven't pushed the change
I
recommended yet; fixing that fixed the build. Anyway, I'll push
soon (hours).
Done.
I'll try to release a beta this weekend, so let's not break anything
badly before then. ;-)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:46 p.m.
New subject: Loading startup changes load-path?
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I'll try to release a beta this weekend, so let's not break
anything
badly before then. ;-)
Great. Then I might be able just to bump to 21.5.34 and claim 21.5.33
is fixed by that! (But maybe I'll provide a fix for 21.5.33 anyway,
based on your commit, just for getting up to speed as maintainer.)
The buildbot failes in two cases though so you might want to take a
look at it.
http://www.lidell.nu/xemacs-buildbot/grid
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:10 p.m.
New subject: Loading startup changes load-path?
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Done.
When switching from no-mule to mule I now get this problem with
defsetf not being defined.
[...]
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/modeline.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/cus-file.elc...
Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/startup.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/misc.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/loadhist.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/files.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/lib-complete.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/format.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/indent.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/isearch-mode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/buffer.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/buff-menu.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/paths.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/lisp.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/page.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/register.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/iso8859-1.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/easy-mmode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/help.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/easymenu.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/special-mode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/lisp-mode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/text-mode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/fill.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/auto-save.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/movemail.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/float-sup.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/itimer.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/itimer-autosave.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/printer.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/behavior.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/behavior-defs.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/diagnose.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/gui.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/mouse.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/mode-motion.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/toolbar.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/scrollbar.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/menubar.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/dialog.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/gutter.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/select.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/menubar-items.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/gutter-items.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/toolbar-items.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/dialog-items.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/coding.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/code-files.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/code-process.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/code-cmds.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/unicode.elc...
Loading /usr/share/xemacs-21.5-b33/lisp/mule/mule-charset.el...
*** Error in XEmacs initialization
(void-function defsetf)
*** Backtrace
really-early-error-handler((void-function defsetf))
(defsetf charset-registry set-charset-registry)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
(load-internal "[internal]")
load-internal("/usr/share/xemacs-21.5-b33/lisp/mule/mule-charset.el"
nil nil nil nil)
# bind (handler path nosuffix nomessage noerror filename)
load("/usr/share/xemacs-21.5-b33/lisp/mule/mule-charset.el")
(prog1 (load full-path) (unless (memq (quote quick-build)
internal-error-checking) (garbage-collect)))
(if full-path (prog1 (load full-path) (unless (memq (quote
quick-build) internal-error-checking) (garbage-collect)))
(external-debugging-output (format "\nLoad file %s: not found\n"
file)) nil)
# bind (full-path)
(let ((full-path (locate-file file load-path (if
load-ignore-elc-files (quote (".el" "")) (quote (".elc"
".el"
"")))))) (if full-path (prog1 (load full-path) (unless (memq (quote
quick-build) internal-error-checking) (garbage-collect)))
(external-debugging-output (format "\nLoad file %s: not found\n"
file)) nil))
# bind (file)
pureload("mule/mule-charset")
[...]
Ideas/Comments on this one?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:30 a.m.
New subject: Loading startup changes load-path?
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Done.
When switching from no-mule to mule I now get this problem with
defsetf not being defined.
Clean tree? Try "make beta". If that doesn't help, this may be more
of Aidan's Common Lisp work showing up in corner cases.
Note that the smoke test builds all fine.
pureload("mule/mule-charset")
This is more for Mike and any other oldtime core hackers who may be
listening: WTF? We don't have pure space anymore, and I thought all
the "pureload" stuff went away ages ago.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:45 a.m.
New subject: Loading startup changes load-path?
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Clean tree? Try "make beta".
This is a clean tree. It is an xemacs gentoo ebuild with emerge, with
source prepared by deleting all elc-files and your patch applied.
Note that files in /usr/share is being loaded. No "make beta" will
ever clean those away.
Note that the smoke test builds all fine.
I know and that is an interesting observation. I think that the
difference is that the buildbot configures with default prefix, ie
prefix=/usr/local, but the gentoo ebuild sets prefix to /usr.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:55 p.m.
New subject: Loading startup changes load-path?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Mats Lidell writes:
> >>>>> Mats Lidell <matsl(a)xemacs.org> writes:
>
> Sorry for following up on my own post but I really need som help on
> this one.
>
> > I'm afraid that the problem is worse than that. [...]
>
> > Excerpt from build log:
>
> > Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/modeline.elc...
> > Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/cus-file.elc...
> > Loading
/var/tmp/portage/app-editors/xemacs-21.5.33/work/xemacs-21.5.33/lisp/startup.elc...
> > Loading /usr/share/xemacs-21.5-b33/lisp/misc.elc...
> > Loading /usr/share/xemacs-21.5-b33/lisp/loadhist.elc...
> > Loading /usr/share/xemacs-21.5-b33/lisp/files.elc...
What's happening is that merely loading "startup" changes load-path.
I see that in my build, but for me it changes load-path to something
harmless (it adds the symlink $blddir/lisp -> $srcdir/lisp).
Resetting load-path at dump time is apparently intentional; see the
comment on the call to `startup-setup-paths' around line 1710 in
startup.el. I don't have time to look into it further today, and
probably not until the weekend. You could try pinging Mike.
It is intentional, to some degree: A long time ago, people screamed
bloody murder at me when the startup paths didn't give configure'd
paths precedence over those determined at run time. startup.el is just
the first file that knows about those paths. So there's no good
solution here that will make everybody happy, I'm afraid.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:58 p.m.
New subject: Loading startup changes load-path?
Michael Sperber writes:
> Resetting load-path at dump time is apparently intentional; see
the
It is intentional, to some degree: [...]. So there's no good
solution here that will make everybody happy, I'm afraid.
Thanks for the information. But this is software; there's always a
solution.:-) I'll think about it. If we don't find a good solution,
I tend to favor Mats' position: we need clean builds.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:56 p.m.
New subject: Loading startup changes load-path?
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
It is intentional, to some degree: A long time ago, people screamed
bloody murder at me when the startup paths didn't give configure'd
paths precedence over those determined at run time. startup.el is just
the first file that knows about those paths. So there's no good
solution here that will make everybody happy, I'm afraid.
But this happens while building the dump. What ever happens when you
start your xemacs is another thing I think. Couldn't this behavior be
controlled some how so that when building the dump we don't do this?
I'm not sure why we actually have the elc-files that we dump with
xemacs also available in the load-path. I understand that it might be
convenient in a lot of ways but since they are dumped they should
never have to be loaded again.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:33 a.m.
New subject: Loading startup changes load-path?
Mats Lidell writes:
I'm not sure why we actually have the elc-files that we dump
with
xemacs also available in the load-path. I understand that it might be
convenient in a lot of ways but since they are dumped they should
never have to be loaded again.
Because XEmacs takes "open source" seriously. That is, if the
libraries are edited, the .elc needs to be compiled and loaded.
People still do that in-place because of find-library. People also
will load the .el for debugging, and when things are working again,
reload the .elc.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:33 p.m.
Ar an t-ochtú lá de mí Meitheamh, scríobh Sean MacLennan:
On Sun, 09 Jun 2013 02:43:17 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
> Mats Lidell writes:
>
> > I haven't analyzed all tar-balls but it seems like 21.5.32 and
> > 21.5.33 have elc-files that refuses to load under a no mule XEmacs.
>
> Which ones, and in what way do they refuse to load?
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/fontl-hooks.elc...
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/auto-show.elc...
Loading /usr/src/xemacs/xemacs-21.5.33/lisp/paragraphs.elc...
*** Error in XEmacs initialization
(error "Loading this file requires xemacs, mule")
[...]
The error seems to be in bytecomp.el.
This isn’t an error in bytecomp.el. The variable sentence-end-base, added by
Ben to paragraphs.el in 2010 and first included in 21.5.30, includes U+201D,
which non-Mule cannot represent. It’s correct and helpful for the file to
refuse to load.
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3958
days inactive
3974
days old
25 comments
5 participants
participants (5)
-
Aidan Kehoe -
Michael Sperber -
Sean MacLennan -
Stephen J. Turnbull -
The XEmacs Package Smoketest