xemacs stuck
16 years, 3 months
Shlomo Tzidkani
Hello,
Environments: Linux Fedora, Xemacs 21.5 + ECB
When activate ecb I got the following errors:
"error in pre-gc-hook", "error in post-gc-hook"
And the Xemacs is stuck
Please advice
Best Regards,
Shlomo
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues
16 years, 3 months
Stephen J. Turnbull
Michael Sperber writes:
> I've running it by default for a few months now, and whenever
> anything connected to encodings comes up, XEmacs screws up royally.
> (Like identifying 8859-1 as Chinese, losing encoding information on
> revert, etc.)
8859-1 == Chinese should be fixed now. There will be more of these
lurking; code identification is a neural-network kind of thing
(unfortunately without the learning part at this point).
If you get a misidentification, send a bug report with the expected
and actual encodings, the file (if you can legally/ethically do so),
and the value of LANG when you started XEmacs. (There are internal
variables that I should add to M-x report-xemacs-bug, but they're all
defaulted from LANG, and it's a pretty safe bet you don't mess with
them directly.)
Losing encoding information on revert? Please be more specific.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
version control and branches
16 years, 3 months
Uwe Brauer
Hello
So far I have used vc, with a rcs backend.
However it seems to easily possible to have branches of versions of a
file. It seems that rcs has that possibility but I don't see how vc
has that incluced
I mean
Foo-v1-->foo-v1a-->foov1b
|
|
^
foo-v2
Is there any other interface supporting branches?
Can somebody point me out some documentation as well?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: byte compiler problem: miscompiling emacs-w3m
16 years, 3 months
Aidan Kehoe
Ar an cúigiú lá déag de mí Eanair, scríobh Stephen J. Turnbull:
> Stephen J. Turnbull writes:
> > Aidan Kehoe writes:
> >
> > > Katsumi, Mike and Dieter: this change
> > > http://hg.debian.org/hg/xemacs/xemacs?cs=e8f448f997ac
> > > fixes the problem for me. I'd appreciate confirmation of this from your end,
> > > if you have the time to check.
> >
> > Aidan, would you please take the time to explain why this DTRTs? A
> > good place would be as a comment in the code, and you should feel free
> > to point that out to a reviewer (probably me ;-) who asks for more
> > explanation.
>
> Oh, I see; I gather this is a follow-on to "bind print-gensym to a cons".
Aye. Relatedly, I’ve just committed a fix to the bug I described in
http://mid.gmane.org/18315.32323.858144.704976＠parhasard.net , with a test
case; see http://hg.debian.org//hg/xemacs/xemacs/?cs=cacc942c0d0f .
> But
>
> > The reason in this case is that byte compiler expertise is now a rare
> > commodity. Even a small thing like explaining why that
> > print-gensym-alist interferes with byte compilation would help raise
> > consciousness (speaking for myself, of course, and possibly others).
>
> still applies. A note that it is conceptually part of that earlier
> patch might be appropriate?
It’s hard to judge how much detail I need to go into, though. If I’m just
writing for you, then I can be a bit more terse and put a bit less effort
into it than if I’m writing for the general case, and writing for the
general case is hard, because I’m still learning this stuff myself. But I
*should* be writing for the general case, if other people are going to be
able to dive in.
Anyway, when it comes to that question in particular:
#'gensym returns an uninterned symbol. This symbol is not in obarray [=
the global name->value map for elisp], and as such does not have a canonical
name. If some existing variable does not refer to it, it will be garbage
collected, like most Lisp objects but unlike most symbols. See footnote
[1] for example code.
When serialising [printing] an interned symbol [= normally one in obarray,
with a canonical name], deciding on a representation for it is trivial; use
its canonical name. This means that the first time you encounter this symbol
on deserialising [reading], you intern the symbol [= create an entry for it
in obarray], and each subsequent time you encounter it, you look it up in
obarray and re-use it.
Deciding on a representation for serialising an uninterned symbol is
harder. For one, it is entirely possible to create two distinct uninterned
symbols with the same name:
(let ((a (make-symbol "hi there"))
(b (make-symbol "hi there")))
(eq a b))
=> nil
So we can’t use only the name, if we’re to preserve the property that the
two are distinct. For another, this property (= that uninterned symbols with
the same name are distinct) is constantly used in Lisp programs--the gensym
counter, which tries to generate distinct names for distinct uninterned
symbols, is dumped, so when byte-compiling one file from a -vanilla start it
will have the same initial value as when byte-compiling another file also
from a -vanilla start. We want the #'gensym calls in Gnus to refer to
different objects than the #'gensym calls in AuCTeX, otherwise using both at
the same time will lead to subtle bugs.
The CL macros make heavy use of #'gensym calls, and there’s nothing wrong
with that; #'gensym is the best way to create temporary variable names at runtime
without polluting the Lisp namespace, or indeed stepping on your own toes if
you’re a heavy macro user.
The really old-school emacs Lisp way to serialise [print] an uninterned
symbol was just to print its name. Then, at deserialisation [read] time it
is interned [= inserted into obarray]. This sucks, and leads to subtle bugs
with large code bases.
The slightly less old-school emacs Lisp way is to bind print-gensym to
t. What this does is, within a single #'print [serialise] call, the first
time an uninterned lisp symbol has to be printed, it’s printed as
#N=#:SYMBOL-NAME, where N is a counter, and SYMBOL-NAME is the name of the
symbol ("hi there" for my two examples above). The symbol and its
corresponding counter value is stored in an table for later retrieval. The
next time that same symbol is to be printed within that #'print call, the
code looks through the table to see if the symbol itself is in that alist;
it finds it, and instead of printing #N=#:SYMBOL-NAME, it just prints #N#.
The Lisp reader interpretes #N=#:SYMBOL-NAME as a directive ‘create an
uninterned symbol with the name SYMBOL-NAME, and store N as its index in a
table of uninterned symbols specific to this top-level form’. It interprets
#N# as a directive ‘look up the Nth entry in the uninterned symbol table for
this form, and use that.’
So, for example, expanding a call to one of the CL macros gives this:
(let ((print-readably t)
(print-gensym t))
(cl-prettyexpand '(loop for i in '(a b c d e f g h)
do (message "hi there %S" i)))
nil)
=> (block nil
(let* ((#1=#:G32994 '(a b c d e f g h))
(i nil))
(while (consp #1#)
(setq i (car #1#))
(message "hi there %S" i)
(setq #1# (cdr #1#)))
nil))
The table used by the printer is called print-gensym-alist. If
print-gensym is bound to t, this is reset on entry to and exit from all
printing functions--pretty much #'prin1-to-string, #'prin1, #'princ and
#'print. With print-gensym bound to t, you can’t byte-compile two different
functions and expect state stored in uninterned symbols to be preserved
across the function boundaries, because the byte compiler uses two separate
calls to #'prin1 when writing the functions to the byte compile output
buffer, and the index decided on when printing the first function is no
longer available when printing the second.
If print-gensym is bound to a cons, then print-gensym-alist is preserved
across calls to the printer functions. It’s not reset. So if you bound
print-gensym-alist to a cons during the entire byte compilation process, you
could re-use state stored in a single uninterned symbol across function
boundaries, except that:
The table used by the reader [deserialiser] is called Vread_objects (it’s
not visible to Lisp) and is reset with each top-level form encountered. So
with two functions and a single uninterned symbol, the use of the uninterned
symbol in the second function will provoke an error when the reader looks
through Vread_objects and doesn’t see any entry with the corresponding
index.
What’s actually done (now) by the byte compiler is it binds print-gensym
to a cons and print-gensym-alist to nil for each top-level form it
outputs. This preserves the identity of uninterned symbols within top level
forms, and does not preserve it across them. This suits the Lisp reader
quite well.
GNU have gone and extended this syntax a little; they now serialise and
deserialise circular objects with it, as well as gensyms. So this:
(read
(let ((thing '(1 2 3 4 5 5))
(print-circle t))
(setf (cddr thing) thing)
(prin1-to-string thing)))
doesn’t error for them, and gives back a circular list. This is something we
should merge, though I hope people will not make active use of it.
Hope that helped a little--I’m not if, at all, it should be committed to the
documentation somewhere.
[1] Code to demonstrate that an uninterned symbol will be garbage collected:
(setq box (make-weak-box (gensym)))
=> #<weak_box>
;; At this point, the only reference to the symbol that #'gensym returned is
;; by means of box, and since box is a weak box, references by means of it
;; do not count for the sake of garbage collection.
(weak-box-ref box)
=> G32999
(garbage-collect)
=> [value omitted]
(weak-box-ref box)
=> nil
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
xemacs 21.5-b28 segfaults on aix 5.2, when setting LDR_CNTRL in any way
16 years, 3 months
Thomas Mittelstädt
Hallo,
I had a problem with a newly built gcc-4.2.2 failing to allocate enough
memory for a particular file.
So I set an environment variable according to
http://www.ibm.com/developerworks/eserver/articles/aix4java1.html:
LDR_CNTRL=MAXDATA=0x80000000
and the file compiled.
But when I restarted xemacs, it would crash with the stack trace below.
(gdb)
#0 0x10244d7c in malloc (size=0) at gmalloc.c:591
#1 0x100065b8 in xmalloc (size=4) at alloc.c:390
#2 0x100026ac in sort_args (argc=1, argv=0x2ff22624) at emacs.c:2777
#3 0x100010d8 in xemacs_21_5_b28_powerpc_ibm_aix5_2_0_0 (argc=1,
argv=0x2ff22624, unused_envp=0x0, restart=0) at emacs.c:958
#4 0x10003610 in main (argc=1, argv=0x2ff22624, unused_envp=0x2ff2262c)
at emacs.c:3172
(gdb)
So I tried to reconfigure and recompile xemacs with LDFLAGS=-Wl,-bmaxdata:0x80000000.
But then the dumped-off xemacs would simply not load:
tmstaedt＠buildaix3$ ./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2 /localbuild/xemacs-21.5.28/src/../lisp
Could not load program ./xemacs:
Error was: Invalid argument
thomas
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
XEmacs Packages have been pre-released (2008-01-15-10)
16 years, 3 months
Norbert Koch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey there everyone.
I have just added the following packages to the 'Pre-Releases'
directory:
New Packages in Pre-Release:
===========================
leim-1.27-pkg.tar.gz upstream version: none
Previously Announced Packages Still in Pre-Release:
==================================================
apel-1.33-pkg.tar.gz upstream version: 10.6
auctex-1.48-pkg.tar.gz upstream version: 11.55
calendar-1.34-pkg.tar.gz upstream version: none
dired-1.19-pkg.tar.gz upstream version: 7.16
easypg-1.01-pkg.tar.gz upstream version: 0.0.15
ediff-1.74-pkg.tar.gz upstream version: 2.75
edit-utils-2.38-pkg.tar.gz upstream version: none
edt-1.14-pkg.tar.gz upstream version: none
efs-1.34-pkg.tar.gz upstream version: 1.24
elib-1.13-pkg.tar.gz upstream version: 1.0
eshell-1.12-pkg.tar.gz upstream version: 2.4.1
eudc-1.40-pkg.tar.gz upstream version: 1.32
general-docs-1.05-pkg.tar.gz upstream version: none
gnus-1.92-pkg.tar.gz upstream version: 5.10.8
guided-tour-0.51-pkg.tar.gz upstream version: none
hm--html-menus-1.24-pkg.tar.gz upstream version: 5.9
hyperbole-1.17-pkg.tar.gz upstream version: 5.0
igrep-1.16-pkg.tar.gz upstream version: 2.111
latin-euro-standards-1.08-pkg.ta upstream version: 1.08
locale-1.27-pkg.tar.gz upstream version: none
mh-e-1.31-pkg.tar.gz upstream version: 7.4.2
mule-base-1.52-pkg.tar.gz upstream version: none
mule-ucs-1.16-pkg.tar.gz upstream version: 0.84
net-utils-1.54-pkg.tar.gz upstream version: N/A
oo-browser-1.05-pkg.tar.gz upstream version: 4.08
os-utils-1.40-pkg.tar.gz upstream version: none
pcl-cvs-1.68-pkg.tar.gz upstream version: R-2_9_9
perl-modes-1.10-pkg.tar.gz upstream version: none
prog-modes-2.15-pkg.tar.gz upstream version: none
psgml-1.45-pkg.tar.gz upstream version: 1.3.2
python-modes-1.09-pkg.tar.gz upstream version: none
scheme-1.17-pkg.tar.gz upstream version: none
skk-1.24-pkg.tar.gz upstream version: 10.62a
text-modes-1.95-pkg.tar.gz upstream version: none
tramp-1.40-pkg.tar.gz upstream version: 2.0.56
vc-1.45-pkg.tar.gz upstream version: none
viper-1.61-pkg.tar.gz upstream version: 3.09
vm-7.26-pkg.tar.gz upstream version: 7.19
w3-1.34-pkg.tar.gz upstream version: 4.0pre47
xemacs-base-2.15-pkg.tar.gz upstream version: none
xemacs-devel-1.77-pkg.tar.gz upstream version: none
Detailed Changes:
================
- ------- ChangeLog Entries from mule-packages/leim/ChangeLog -------
2008-01-15 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 1.27 released.
2008-01-14 Aidan Kehoe <kehoea(a)parhasard.net>
* quail/latin-ltx.el ("TeX2):
Correct the mappings for \v{k} and \vk.
Installing These:
================
Manually:
- --------
1) Download the packages that you want to install from:
/ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/
2) Unpack them to: [1]
/usr/local/lib/xemacs/xemacs-packages/
3) Re-start XEmacs.
Using XEmacs Package Tools (XEmacs 21.[245].x):
- ----------------------------------------------
1) Tools -> Packages -> Add Download Site -> Pre-Releases
2) Tools -> Packages -> List and Install
3) Select the packages you wish to install (there are brief
instructions at the bottom of the packages buffer).
4) Packages -> Install/Remove Selected
5) Re-start XEmacs.
Using XEmacs Package Tools (XEmacs 21.1.14):
- -------------------------------------------
1) Options -> Manage Packages -> Add Download Site -> Pre-Releases
2) Options -> Manage Packages -> List and Install
3 - 5) As per XEmacs 21.[245].x.
norbert - XEmacs Package Release Manager.
Footnotes:
[1] Note: Mule packages should be installed into:
/usr/local/lib/xemacs/mule-packages/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHjHqWgu3ywdHdhM0RAoVbAKCV7ytFGmuymyCUJIphdklKKiupyQCg0ObQ
GtVvCDd5spVElcPDS9pNgkQ=
=8Y2T
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
