March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

new package system rocks 26 years, 1 month

Andrew Hobson

I just downloaded and installed 21.0.65, and I then used package-get-update-all. It downloaded all of the installed packages and updated them without hitch. I just wanted to send a note of thanks to all of the people that put hard work into the package system. Drew

1 participants
0 comments

Re: BUG REPORT: New VM 6.67 broken (seems like packaging problem) 26 years, 1 month

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > I downloaded and installed the latest tarball, did a M-x vm, and got > (from C-h l): > Invalid function: (macro . #<compiled-function (&rest forms) "...(16)" [let ((vm-sbe-buffer (current-buffer))) unwind-protect progn forms (and (not (eq vm-sbe-buffer (current-buffer))) (buffer-name vm-sbe-buffer) (set-buffer vm-sbe-buffer))] 5>) ... > Steve, this looks like a simple packaging/byte-compiling screwup. > It's a showstopper. Something needs an (eval-when-compile (require 'vm-macro))[1] and doesn't have it. Footnotes: [1] If vm-macro.el is where this macro is defined.

3 participants
2 comments

fix custom loading of package stuff 26 years, 1 month

Andy Piper

This stuff got broken some time ago. I include the auto-autoload patch but they may need regenerating anyway. andy 1999-03-08 Andy Piper <andy(a)xemacs.org> * package-get.el (package-get-base): autoload. * menubar-items.el (default-menubar): add update menu item. Fix custom menu to only be activated when package-base is available. * package-get.el (package-get-custom): don't load package-get-custom as it is auto-generated. Fix group definition.

1 participants
0 comments

Re: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 26 years, 1 month

Gunnar Evermann

Damon Lipparelli <lipp(a)primus.com> writes: > As with the previous release, I can't build with MULE enabled. I'm not > sure what I'm supposed to have where anymore. I've got mule-base 1.28 > installed. I've attached my "Installation" file and the stack trace I > get when I try to run xemacs. Ok, I guess we have to hurry, if we want to fix this before the release. Glenn Barry from Sun reported a similar problem when building b64 with mule. When do you get this crash? During the build (in temacs) or after a successful build of xemacs? > What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch please use src/gdbbinit as you ~/.gdbinit file and use the 'pobj' command to print the 'obj' variable in stack frames 3-8. > #0 0xef0748e8 in kill () > #1 0x95748 in fatal_error_signal (sig=11) at emacs.c:262 > #2 <signal handler called> > #3 0x4c424 in mark_object (obj=541561856) at alloc.c:3170 > #4 0x6f21c in mark_char_table (obj=2, markobj=0x4c310 <mark_object>) ^^^^^^ Ouch, I doubt we have a valid object at address 2! :-( > at chartab.c:145 > #5 0x4c4a0 in mark_object (obj=541825024) at alloc.c:3180 > #6 0x4c684 in mark_object (obj=4970372) at alloc.c:3234 > #7 0x4c600 in mark_object (obj=3956736) at alloc.c:3216 > #8 0x4e598 in garbage_collect_1 () at alloc.c:4493 thanks. Gunnar P.S.: if anybody is interested here is part of Glenn's backtrace: where =>[1] _kill(0x0, 0xb, 0xa064901c, 0x0, 0xfeb31f98, 0xddb64), at 0xfeb16870 [2] fatal_error_signal(0x6464c0, 0x6464b4, 0x619800, 0x61dd20, 0x61d800, 0xa0649004), at 0xddb64 ---- called from signal handler with signal 11 (SIGSEGV) ------ [3] mark_object(), at 0x7244c [4] mark_char_table(0x87e000, 0x7230c, 0x87e004, 0x2, 0xffffc00, 0x5f800), at 0x99fe8 [5] mark_object(0x61d800, 0x87e000, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x724bc [6] mark_object(0x60000000, 0x87822c, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x726d4 [7] mark_object(0x64b31c, 0x64a000, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x7265c [8] garbage_collect_1(0x6406b8, 0x612c00, 0x47937c, 0x1, 0x640400, 0x30), at 0x76a84 [9] Feval(0x61db84, 0x61df3c, 0x615b30, 0x61b800, 0xa06afedc, 0x5fb30), at 0xf48a8 -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

3 participants
4 comments

Re: 21.2.11 wont compile with mule 26 years, 1 month

Jan Hebler

Hi Gunnar Gunnar Evermann writes: > Jan Hebler <jan(a)hebler.de> writes: > > Hi Jan, > > thanks for your report. > > > if i try to compile xemacs 21.2.11 with mule i get the following error > > > > insert-file-contents-internal("/usr/src/Xemacs/lisp/finder-inf.el" t nil nil nil undecided used-codesys) > > does that file exist and is it readable? No, that file doesnt exist and so, it is not readable ;-) But IMHO this is not the Problem. If i start the new generated xemacs, everything works fine until i want to load a nonexistend file. _then_ i will got this error. it seems to me that there is something broken in the area of locales LC_XXXX and friends. To be more precisiously the Bug occurs _only_ if i have set my LC_ALL to "DE_de" if i set them to "C" everything works fine (well, except that my LOCALES are now broken) In the File ChangeLog i found: -1998-12-28 Martin Buchholz <martin(a)xemacs.org> - - * XEmacs 21.2.8 is released. - -1998-12-28 Martin Buchholz <martin(a)xemacs.org> - - * PROBLEMS: Document Linux GNU Libc 2.0 I18N crashes. - -1998-12-24 Martin Buchholz <martin(a)xemacs.org> - - * XEmacs 21.2.7 is released. I think this is the real problem. too bad, the patch is more than 100k, so there are many points to hide. > > *please* tell me you are not building with an gcc/egcs snapshot using > a glibc snapshot on an unstable kernel release using -O3! If you do, > then you got what you deserve. :-) > Well, lets see Kernel is 2.1.132 this should be stable, since he is the last before the 2.2 Kernels glibc is (from version.h) -/* This file just defines the current version number of libc. */ - -#define RELEASE "production" -#define VERSION "2.0.7" gcc is : Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) The whole System is an SUSE 6.0 german > > used_codesys=137990816) > > at fileio.c:148 > ^^^^ > I *hate* inlined functions -- which call to report_file_error is this? Umpf, what do you mean with "wich call" ? If you tell me how i should look, maybe i kan figure it out. > > seriously, I really can't see how XEmacs can be blamed for strerror(2) > segfault'ing. > > could you try rebuilding without -O3? Of course, but the problem is still the same. ru Jan PS sorry for my nasty english, but it is not my native language

1 participants
0 comments

Re: Mojibake 26 years, 1 month

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Is it supposed to be EUC encoded Japanese? sb> Opening directory: sb> ¤½¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¢¤ë¤¤¤Ï¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¢¤ê¤Þ¤»¤ó, sb> /usr/users/steve/Mail/archives/ > Yes. It says (in EUC-encoded Japanese) "There is no file or directory > like that." Mark the region and hit it with `(decode-coding-region > (mark) (point) 'euc-jp)'. > There's supposed to be a process-coding-system variable in Mule 2.3, > but I don't think we've implemented it. We've implemented it, but it's broken by default. In a *shell* buffer: $ ls fred ls: fred: ¤½¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¢¤ë¤¤¤Ï¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¢¤ê¤Þ¤»¤ó $ ls fred ls: fred: そのようなファイルあるいはディレクトリはありません In between the two commands I did: (set-buffer-process-coding-system 'euc-jp 'euc-jp) > One would guess it's a bit unreliable in localized contexts, and > useless in multilingual ones (eg, the Japanese Web, one language, a > Babel of encodings). As Moriokasan is explaining to me.

1 participants
0 comments

Mojibake 26 years, 1 month

SL Baur

I've found another instance where XEmacs loses when libc is localized. In a Japanese locale, I get the following when I do a find file with a non-existent directory. Is it supposed to be EUC encoded Japanese? Opening directory: ¤½¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¢¤ë¤¤¤Ï¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¢¤ê¤Þ¤»¤ó, /usr/users/steve/Mail/archives/

2 participants
1 comments

Re: 21.2.11 wont compile with mule 26 years, 1 month

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > Hi Jan, Oh no another jan :-) now we will have to user surnames. Welcome anyway Jan. > *please* tell me you are not building with an gcc/egcs snapshot using > a glibc snapshot on an unstable kernel release using -O3! If you do, > then you got what you deserve. :-) This reminds of the following bit of sarcasm from Frans van Dorrselaer on c.e.m-w.wine ( <6ba4bb$dt2$1(a)highway.leidenuniv.nl>) ========== Hello, I've always hesitated to send in bug reports, but after examining this group for a while I think I'm now ready. I'm running a developer release Linux 2.1.99, compiled with a developer release gcc 2.8.13, which was compiled using itself. Both contain numerous source bugs, as well as binary bugs due to the source bugs of the latter. I use an alpha release Wine compiled with the very same developer release compiler to run Windows binaries, each of which are per definition a collection of bugs. Of course I run everything as root. Now I found a bug. Can somebody fix this ? Thanks in advance, Frans ==============================

1 participants
0 comments

Re: [Failure] Xemacs 21.0.65 on Digital UNIX 4.0D with DEC C 26 years, 1 month

Hrvoje Niksic

"Kevin Oberman" <oberman(a)es.net> writes: > Since so few people are likely to have IPv6 installed and since it > appears to clearly be a bug in the IPv6 supplied file, I don't see > any reason to "fix" anything, but a caveat might be in > order. (Though I'm not too sure it's worth even that.) I think adding an entry to PROBLEMS would be fine.

1 participants
0 comments

Re: Compiling with OpenLDAP 1.2.0 26 years, 1 month

Oscar Figueiredo

>>>>> "Gregory" == Gregory Neil Shapiro <gshapiro(a)sendmail.org> writes: Gregory> I tried compiling with OpenLDAP 1.2.0 and linking failed. The Gregory> generated src/Makefile only includes the -lldap library when LDAP is Gregory> compiled in. The libraries -llber -lkrb -ldes are also required for Gregory> linking with OpenLDAP. I'll leave the fix to someone who knows Gregory> autoconf, I'm afraid I don't qualify. Please try to make distclean, rerun configure and build again. If it still fails then send me the output of configure. The problem may be due to the fact that configure incorrectly detected your libraries as Netscape libs. Oscar

2 participants
1 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 1999