11:51 a.m.
Richard Hubbell writes:
seems like some strange DNS with ftp.xemacs.org
*___________________________________________________________________________*
ping ftp.xemacs.org
PING xemacs.org (207.172.156.133) 56(84) bytes of
data.
What's strange about it? That's the right IP address, and I have no
problems logging in.
There are other issues with FTP, I'm checking with our host.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:44 p.m.
Richard Hubbell writes:
(no debugging symbols found)
*sigh*
0x081c7c30 in x_handle_selection_clear ()
If your distro provides a corresponding debug package for the xemacs
binary, it would help if you could install it and get file name and
line number information. Assuming we can reproduce it, we can get
that easily enough, but there's no guarantee.
XEmacs 21.4.19 "Constant Variable" configured for
`i386-debian-linux'.
Aidan fixed (or at least diagnosed) a bug with symptoms something like
this; I think there is a fix in 21.4.20. I'll check later.
/usr/share/emacs/site-lisp/debian-startup
/etc/emacs/site-start
This is suicidal, at least if there are any compiled libraries in
there. The GNU Emacs bytecompiler now produces bytecode that is
capable of crashing XEmacs, at worst. You really want to avoid having
GNU-compiled byte code anywhere near XEmacs.
(This doesn't have anything to do with the crash you're seeing, I
believe.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:01 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Richard Hubbell writes:
> /usr/share/emacs/site-lisp/debian-startup
> /etc/emacs/site-start
This is suicidal, at least if there are any compiled libraries in
there. The GNU Emacs bytecompiler now produces bytecode that is
capable of crashing XEmacs, at worst.
XEmacs started it... Of course, ongoing development makes
compatibility to everything else under the sun inconvenient at some
point of time.
You really want to avoid having GNU-compiled byte code anywhere near
XEmacs.
And vice versa. I think the idea of the Debian setup is to provide
the lisp sources for all Emacs offspring in a single directory, and
put the compiled versions into a variant-specific directory somewhere
else in the load-path, differently for each variant.
Consequently,
M-x list-load-path-shadows RET
barfs all over the place on Debian systems.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:52 p.m.
Stephen J. Turnbull wrote:
The GNU Emacs bytecompiler now produces bytecode that is
capable of crashing XEmacs, at worst.
Is there somewhere I could find out more about the differences between
the FSF and XEmacs byte compilers and (hopefully) the reasons for
those differences? (Google was unhelpful and I didn't see anything in
the byte-*.el files.)
Thanks.
--- Vladimir
--
Vladimir G. Ivanovic
+1 650 678 8014
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4 a.m.
Vladimir G. Ivanovic writes:
Is there somewhere I could find out more about the differences
between
the FSF and XEmacs byte compilers
Yes. In the source code.
and (hopefully) the reasons for those differences? (Google was
unhelpful and I didn't see anything in the byte-*.el files.)
The reason for the difference is historical and legal. In 1997-1998
XEmacs added Mule which required some changes, and also did a lot of
work on optimizing the byte compiler. Martin Buchholz offered to port
the XEmacs improvements to GNU Emacs (AFAIK copyright is assigned to
the FSF) around 1999 when he was at ETL, but was turned down because
of the Great Redisplay Rewrite; Gerd didn't have time.
Since then GNU has added a very divergent version of Mule and done its
own optimizing. AFAIK they never contacted Martin, and of course it's
very possible that the offer to do the work was no longer open.
Without Martin's personal involvement to testify that the code was not
polluted with unassigned code, it's unlikely that the FSF lawyers
would permit the XEmacs code into GNU Emacs.
Of course we could port GNU improvements in the other direction, but
we have a working, reasonably well-optimized byte compiler and
interpreter. In fact, as of Python 2.0 I think it was, the XEmacs
byte code was about 10% faster on a meaningless benchmark than
Python's VM. But actually there is meaning there: there probably is
very little efficiency improvement that can be squeezed out of the
XEmacs virtual machine without changing Emacs Lisp.
There are also a fair number of minor differences in philosophy, which
you will find oblique references to in comments in the bytecode system
implementation.
All this could be worked out, I suppose, but what is the gain to be
expected from that?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:43 a.m.
Thanks.
--- Vladimir
Stephen J. Turnbull wrote:
Vladimir G. Ivanovic writes:
> Is there somewhere I could find out more about the differences between
> the FSF and XEmacs byte compilers
Yes. In the source code.
> and (hopefully) the reasons for those differences? (Google was
> unhelpful and I didn't see anything in the byte-*.el files.)
The reason for the difference is historical and legal. In 1997-1998
XEmacs added Mule which required some changes, and also did a lot of
work on optimizing the byte compiler. Martin Buchholz offered to port
the XEmacs improvements to GNU Emacs (AFAIK copyright is assigned to
the FSF) around 1999 when he was at ETL, but was turned down because
of the Great Redisplay Rewrite; Gerd didn't have time.
Since then GNU has added a very divergent version of Mule and done its
own optimizing. AFAIK they never contacted Martin, and of course it's
very possible that the offer to do the work was no longer open.
Without Martin's personal involvement to testify that the code was not
polluted with unassigned code, it's unlikely that the FSF lawyers
would permit the XEmacs code into GNU Emacs.
Of course we could port GNU improvements in the other direction, but
we have a working, reasonably well-optimized byte compiler and
interpreter. In fact, as of Python 2.0 I think it was, the XEmacs
byte code was about 10% faster on a meaningless benchmark than
Python's VM. But actually there is meaning there: there probably is
very little efficiency improvement that can be squeezed out of the
XEmacs virtual machine without changing Emacs Lisp.
There are also a fair number of minor differences in philosophy, which
you will find oblique references to in comments in the bytecode system
implementation.
All this could be worked out, I suppose, but what is the gain to be
expected from that?
--
Vladimir G. Ivanovic
+1 650 678 8014
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:47 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
There are also a fair number of minor differences in philosophy,
which you will find oblique references to in comments in the
bytecode system implementation.
All this could be worked out, I suppose, but what is the gain to be
expected from that?
Given that among different versions of either Emacs or XEmacs,
different things get solved using macro expansion, .elc compatibility
is pretty much a myth even between versions with compatible byte code.
So if you want to be on the safe side, byte compile with the installed
binary.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6299
days inactive
6302
days old
7 comments
4 participants
participants (4)
-
David Kastrup -
Richard Hubbell -
Stephen J. Turnbull -
Vladimir G. Ivanovic