March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

There will be two more betas and a new Sumo released on Friday afternoon, Japan time. The deadline for getting patches committed to CVS for this round is 4:00PM Thursday (+0900).

1 participants
0 comments

Re: decode-coding-region and encode-coding-region 25 years, 8 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > But decode-coding-region basically changes where `characters' begin and > end, right?. Right. > If I create an extent in an iso8859-1 buffer (however it got there) > but then realize 'oh shit, that is really shift-jis encoded goo' and > decode the coding region, isn't it possible that the extent could > start or end in the _middle_ of a shift-his sequence, and it would > then be in the middle of the new character? In that case I would round it to a character. > Would the open/closed start/end-ness be of use there? No, I don't think so.

2 participants
1 comments

Re: forwarded message from Stephen J. Turnbull 25 years, 8 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: > Here's a message that gives the second kind of bug (split encoded > words lose). Gnus + TM is O.K. I manufactured a message with split encodings, ie. the Subject: Subject: =?ISO-2022-JP?B?GyRCRnw4dxsoQiIbJEJGfDh3GyhCIg==?= =?ISO-2022-JP?B?GyRCRnw4dxsoQiIbJEJGfDh3GyhCIg==?= I see in the Gnus *Summary* buffer: [ 34: Andrew S. Howell ] Re: 21.0.65 build problem on Solaris 2.5.1, gcc + [ 29: Stephen J. Turnbull ] [ 2: SL Baur ] 日光"日光"日光"日光" and I see in the Gnus *Article* buffer: From: SL Baur <steve(a)xemacs.org> Subject: 日光"日光"日光"日光" To: steve(a)etl.go.jp Date: 09 Mar 1999 17:38:31 +0900 X-Mailer: Gnus v5.6.45/XEmacs 21.0(beta65) - "20 minutes to 日光" Note that the ascii double quotes are deliberate, though they appear to have no effect. The addition of a double blank between `to' and <Nikko> appears to be a bug, but I'm not too worried about it. Pasting in the Subject: line doesn't appear to add spurious blanks.

3 participants
2 comments

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

Gunnar Evermann

Damon Lipparelli <lipp(a)primus.com> writes: > It looks like the badness occurs the first time mark_object() is called. > We're are trying to mark the object pointed to by staticvec[0] (a hash > table). Stepping over line 2186 in "alloc.c" corrupts *(staticvec[0]). I assume you mean line 3186? Which version of alloc.c are you using anyway? The line numbers in your backtrace look like the latest one from CVS, i.e. including Martin's patch after 21.0-b65? I am afraid I just realized that the gdb commands cannot currently handle marked lrecords properly (at least for !USE_INDEXED_LRECORD_IMPLEMENTATION), so if you mean by 'corrupted' that pobj say 'unknown Lisp_Object' then that is expected :-( I noted below the following line numbers what kind of object is about to be marked at each point in your backtrace: > #0 0x4eb24 in mark_object (obj=541672448) at alloc.c:3183 > #1 0x6a5f0 in mark_char_table (obj=542035968, markobj=0x4e960 <mark_object>) > at chartab.c:145 > #2 0x4ec04 in mark_object (obj=542035968) at alloc.c:3193 Lisp_Type_Record marker function > #3 0x4ee64 in mark_object (obj=-1605681276) at alloc.c:3247 Lisp_Type_symbol sym->value > #4 0x4edb4 in mark_object (obj=-2143416320) at alloc.c:3229 Lisp_Type_Vector element i > #5 0x52090 in garbage_collect_1 () at alloc.c:4510 staticvec[i] If I read this right we're trying to mark a chartable which is the value of a symbol which is an element of a Vector which is staticpro'd. Could you check what this vector contains? possibly before the actual marking? Presumably it is already corrupted before the GC -- do you always get the crash on marking this particular vector? Then you might want to try the watchpoint or always_gc stuff Martin mentioned... FWIW I have an additional report of such a crash under 21.0b65... -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

RE: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 25 years, 8 months

Damon Lipparelli

Yow! Sure enough, building with "--gung-ho" fixed the problem. This is the first release I've been able to get running with MULE since the MULE stuff was integrated back into the source tree. -lipp -----Original Message----- From: Gunnar Evermann [mailto:ge204＠eng.cam.ac.uk] Sent: Sunday, March 07, 1999 7:07 AM To: Damon Lipparelli Cc: 'XEmacs Beta Mailing List' Subject: Re: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 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

1 participants
0 comments

RE: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 25 years, 8 months

Damon Lipparelli

It looks like the badness occurs the first time mark_object() is called. We're are trying to mark the object pointed to by staticvec[0] (a hash table). Stepping over line 2186 in "alloc.c" corrupts *(staticvec[0]). I'm currently re-building with "--gung-ho" enabled to see if it makes a difference. -lipp ps: I've attached a more up-to-date "Installation" file and stack trace. These were produced with no optimization and all error checking and debug bits built in. -----Original Message----- From: Gunnar Evermann [mailto:ge204＠eng.cam.ac.uk] Sent: Sunday, March 07, 1999 7:07 AM To: Damon Lipparelli Cc: 'XEmacs Beta Mailing List' Subject: Re: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 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

1 participants
0 comments

Re: [CRASH] 21.2-b8..b12 starting tetris with bad xpmimage.colorTable[] 25 years, 8 months

Adrian Aichner

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 03:28 PM 3/5/99 +0100, Adrian Aichner wrote: >> this crash is still around in >> 21.2-b12 with >> games 1.09 1.09 Tetris, Sokoban, and Snake. Andy> I had gone mule mad. Sorry. This fixes the problem I will Andy> apply it to 21.2 Hello Andy, I can gladly confirm the problem fixed in (emacs-version) "XEmacs 21.2 \"Clio\" [Lucid] (i586-pc-win32) of Tue Mar 09 1999 on ZJ75T" with this patch. Regards, Adrian Andy> andy Andy> 1999-03-09 Andy Piper <andy(a)xemacs.org> Andy> * glyphs-msw.c (mswindows_xpm_instantiate): free Andy> color_symbols contents. (extract_xpm_color_names): Andy> don't use alloca'd space for color_symbol names. Andy> - csym.patch -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: decode-coding-region and encode-coding-region 25 years, 8 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > It's not clear to me what it means to "preserve metainformation" > > It means "not fuck up all the extents and text properties". > > Both extents and text properties, as well as markers, are logically > defined in *characters*, which means that it's perfectly feasible to > retain them through coding-region changes. > > Currently there is no way to convert the buffer into another coding > and have extents intact. But decode-coding-region basically changes where `characters' begin and end, right?. If I create an extent in an iso8859-1 buffer (however it got there) but then realize 'oh shit, that is really shift-jis encoded goo' and decode the coding region, isn't it possible that the extent could start or end in the _middle_ of a shift-his sequence, and it would then be in the middle of the new character? Would the open/closed start/end-ness be of use there? -Bill P.

1 participants
0 comments

Re: decode-coding-region and encode-coding-region 25 years, 8 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > It's not clear to me what it means to "preserve metainformation" It means "not fuck up all the extents and text properties". Both extents and text properties, as well as markers, are logically defined in *characters*, which means that it's perfectly feasible to retain them through coding-region changes. Currently there is no way to convert the buffer into another coding and have extents intact. > If it's easy, can you explain what you had in mind? Does the above answer satisfy you?

1 participants
0 comments

decode-coding-region and encode-coding-region 25 years, 8 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > We should ask Ken'ichi what he thinks the correct behavior of > `decode-coding-region' should be; I don't think it should move > point, myself, but I don't know what the "correct" behavior should > be if point starts strictly between START and END. This may not be related to your problem, but I'll chime in anyway. decode-coding-region is broken in both FSFmacs and XEmacs, primarily because it destroys all metainformation on buffer regions (markers and extents/text-props). If you look at the implementation of encode/decode-coding-region, you'll easily guess why that is so. I tried to fix these two functions, but couldn't think of a way to fix do so within the current stream-based framework. IMHO the trick is for decoding streams to (optionally) maintain some kind of information about old and new byte-positions, so that markers and extents can be saved internally and re-attached after the streams do their work. Currently the only way to do it is to break the streams abstraction, and there must be a better way. I think I'll pester Ben about it when I see him.

2 participants
1 comments

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