January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[BUGlet] Scrolling partial lines damages the modeline... 24 years, 11 months

Daniel Pittman

Hi. The new partial-line scrolling stuff works quite well in "21.2 (beta27) \"Hera\" XEmacs Lucid", scrolling the XFace headers in my Gnus by the height of a single line of text. The one problem this has is that when doing so, parts of the modeline above are overdrawn with the `From: [FACE] ....' header. This does not get redrawn by XEmacs in the normal course of things. This is on Linux, XFree 3.3.6. More detail on request... Daniel -- They only hit until you cry And after that you don't ask why You just don't argue anymore -- Suzanne Vega, _Luka_ (Solitude)

1 participants
0 comments

Re: [PATCH] Last assault on binary-process-output 24 years, 11 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Some time ago, Hrvoje Niksic wrote... > >You mean: binary-process-output is now ignored, and everyone should > >bind coding-system-for-read to `binary' instead. Don't you think this > >should be documented in NEWS, along with a rationale for the change? > > Exactly. binary-process-output was NTEmacs influenced variable, > while coding systems are XEmacs-wode, not NT-only. The variable was > initially marked by marcpa as borrowed temporarily from NTEmacs, > while coding streams are not implemented. I do not really know if > removal of oblosete features should be put into NEWS[1], on your > discretion Hrvoje. The purpose of NEWS is to document user-visible changes. If I have code that does: (let ((binary-process-output t)) ...) and that code no longer works in 21.2, this should well be mentioned in NEWS, under "Lisp and internal changes". The entry might look like this: ** The variable `binary-process-output' is now obsolete. This variable was previously used to tell NT XEmacs to forgo the CRLF detection and accept its input as binary. The correct way to do it is now the same as under Unix, by binding `coding-system-for-read'. The NT-specific code that looked like this: (let ((binary-process-output t)) ... code ...) should be changed to this: (let ((coding-system-for-read 'binary)) ... code ...)

3 participants
2 comments

problem with latest CVS XEmacs 21.2 24 years, 11 months

Damon Lipparelli

I've got a co-worker here who has built GNUS 5.8.3 against today's XEmacs build. When he tries to run, he gets the error: No such coding system: file-name Is coding system gone? Thanks, -lipp

1 participants
0 comments

emacs-version incorrect? 24 years, 11 months

John A. Turner

although I built 21.2b27 last week and it was reporting the correct version (21.2-b27 "Hera" configured for `mips-sgi-irix6.5'): http://www.xemacs.org/list-archives/xemacs-build-reports/200001/msg00019.... I did a cvs-update today and re-built, and now emacs-version is: "21.1 (patch 8) \"Bryce Canyon\" XEmacs Lucid" not sure if this is related, but I used to do gmake all-elc to build - it seems like that has changed and now I should just be doing gmake - is that correct? thanks, -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 381-8400

2 participants
2 comments

DLL problem 24 years, 11 months

Rafael Laboissiere

Hi, I tried to load the sample module in modules/sample/sample.c distributed with XEmacs 21.2.23 and did not succeed. After a successful compilation, I issued: (load-module "/build/xemacs-21.2.23/modules/sample/sample.ell") and got the error message: Opening dynamic module: /build/xemacs-21.2.23/modules/sample/sample.ell: undefined symbol: Qt How can I make that work? Please, Cc: replies to me, as I am not subscribed to xemacs-beta. Thanks, -- Rafael Laboissiere <rafael(a)icp.inpg.fr> Institut de la Communication Parlee / INP Grenoble, France http://www.icp.inpg.fr/~rafael

1 participants
0 comments

Re: [PATCH] Last assault on binary-process-output 24 years, 11 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > This might break packages which expect NTEmacs variable binary-process-output > to do things. Packages in XEmacs sumo tarball are clear, please test 3rd > party packages which you are using. The correct fix is: > > Whenever a construct > (let ((binary-process-output t)) > ... ) > > is used, add one more binding: > (let ((binary-process-output t) > (coding-system-for-read 'binary)) > ... ) > > This way, old compatibility is not broken and XEmacs compatibility is > restored. You mean: binary-process-output is now ignored, and everyone should bind coding-system-for-read to `binary' instead. Don't you think this should be documented in NEWS, along with a rationale for the change?

2 participants
1 comments

Please re-configure after cvs-update 24 years, 11 months

Martin Buchholz

Recent changes to src/config.h.in require rebuilding from scratch (actually you might get away with "./config.status; make"). Martin

1 participants
0 comments

PDUMP questions 24 years, 11 months

Martin Buchholz

I suggest the following as being more intuitive, more maintainable, and also being more correct. You are making the non-portable assumption that the compiler lays out structs like an array. In fact, the compiler can order key and value any way it likes. You did call it the _portable_ dumper. Of course, you might object that the proposed change makes pdump_load slower. If you really really think this micro-optimization is worth it (I don't) then you can change the declaration of hentry to be Lisp_Object hentry[2]; and change all the references to hentry->key, e.g. using #define HENTRY_KEY(hentry) hentry[0] #define HENTRY_VALUE(hentry) hentry[1] Index: elhash.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/elhash.c,v retrieving revision 1.14.2.17 diff -u -r1.14.2.17 elhash.c --- elhash.c 2000/01/08 07:51:23 1.14.2.17 +++ elhash.c 2000/01/26 00:40:53 ＠＠ -374,7 +374,8 ＠＠ } static const struct lrecord_description hentry_description_1[] = { - { XD_LISP_OBJECT, offsetof(hentry, key), 2 }, + { XD_LISP_OBJECT, offsetof(hentry, key), 1 }, + { XD_LISP_OBJECT, offsetof(hentry, value), 1 }, { XD_END } }; I don't understand where the zero'ed ends of strings and hash_tables are being stored and/or restored. The size of the data member in a string or a hash_table refers to the "real" data, but strings have a NUL byte at the end, and hash table entries have a null sentinel entry at the end. How are these being restored? I've been purifying xemacs built with pdump. creating the dump file runs cleanly for me now. However, after running the test suite, I get lots of memory leak warnings I don't understand like this: (elhash.c source file pointers are off by one) MLK: 94240 bytes leaked in 254 blocks This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] xcalloc [alloc.c:293] xmalloc_and_zero [alloc.c:302] resize_hash_table [elhash.c:894] *** WARNING: Source file is newer, display may be incorrect ht->size = new_size; old_entries = ht->hentries; => ht->hentries = xnew_array_and_zero (hentry, new_size + 1); new_entries = ht->hentries; reorganize_hash_table [elhash.c:915] *** WARNING: Source file is newer, display may be incorrect void reorganize_hash_table (Lisp_Hash_Table *ht) => { resize_hash_table (ht, ht->size); } pdump_load [alloc.c:5132] for (i=0; i<rt->count; i++) { struct Lisp_Hash_Table *ht = XHASH_TABLE (*(Lisp_Object *)p); => reorganize_hash_table (ht); p += sizeof (EMACS_INT); } break; xemacs_21_2_b27_sparc_sun_solaris2_6 [emacs.c:854] main [emacs.c:2251] _start [crt1.o] Block of 6304 bytes at 0x10ba628 Block of 3664 bytes (2 times); last block at 0x10aacd8 Block of 2784 bytes (2 times); last block at 0x10b1648 Block of 1584 bytes (4 times); last block at 0x10b9f38 Block of 1200 bytes at 0x10a6258 Block of 864 bytes (8 times); last block at 0x10b5cc8 Block of 640 bytes (7 times); last block at 0x10b65f8 Block of 480 bytes (4 times); last block at 0x10a7468 Block of 336 bytes (2 times); last block at 0x10bc138 Block of 240 bytes (223 times); last block at 0x10bbf88 MLK: 480 bytes leaked at 0x115d0a0 This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] xcalloc [alloc.c:293] xmalloc_and_zero [alloc.c:302] resize_hash_table [elhash.c:894] *** WARNING: Source file is newer, display may be incorrect ht->size = new_size; old_entries = ht->hentries; => ht->hentries = xnew_array_and_zero (hentry, new_size + 1); new_entries = ht->hentries; enlarge_hash_table [elhash.c:923] *** WARNING: Source file is newer, display may be incorrect enlarge_hash_table (Lisp_Hash_Table *ht) { size_t new_size = => hash_table_size ((size_t) ((double) ht->size * ht->rehash_size)); resize_hash_table (ht, new_size); } Fputhash [elhash.c:967] *** WARNING: Source file is newer, display may be incorrect e->key = key; e->value = value; => if (++ht->count >= ht->rehash_count) enlarge_hash_table (ht); return value; keymap_store_internal [keymap.c:608] keymap_store [keymap.c:673] Fdefine_key [keymap.c:1949] Feval [eval.c:2975] readevalloop [lread.c:1448] Fload_internal [lread.c:736] Ffuncall [eval.c:3175] execute_optimized_program [bytecode.c:747] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] execute_optimized_program [bytecode.c:747] Fbyte_code [bytecode.c:2404] Feval [eval.c:2975] condition_case_1 [eval.c:1629] condition_case_3 [eval.c:1710] execute_rare_opcode [bytecode.c:1272] execute_optimized_program [bytecode.c:657] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] mapcar1 [fns.c:3112] Fmapcar [fns.c:3218] Ffuncall [eval.c:3175] execute_optimized_program [bytecode.c:747] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] MLK: 336 bytes leaked at 0x1109388 This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] xcalloc [alloc.c:293] xmalloc_and_zero [alloc.c:302] resize_hash_table [elhash.c:894] enlarge_hash_table [elhash.c:923] Fputhash [elhash.c:967] keymap_store_inverse_internal [keymap.c:528] keymap_store_internal [keymap.c:610] keymap_store [keymap.c:673] Fdefine_key [keymap.c:1949] Ffuncall [eval.c:3175] execute_optimized_program [bytecode.c:747] Fbyte_code [bytecode.c:2404] Feval [eval.c:2975] readevalloop [lread.c:1448] Fload_internal [lread.c:736] Ffuncall [eval.c:3175] execute_optimized_program [bytecode.c:747] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] execute_optimized_program [bytecode.c:747] Fbyte_code [bytecode.c:2404] Feval [eval.c:2975] condition_case_1 [eval.c:1629] condition_case_3 [eval.c:1710] execute_rare_opcode [bytecode.c:1272] execute_optimized_program [bytecode.c:657] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] mapcar1 [fns.c:3112] Fmapcar [fns.c:3218] Martin

4 participants
5 comments

Crash after "Switch to Buffer, Other Frame" selected 24 years, 11 months

Jon Maxell

****************************************************** *** Here is M-x describe-installation ****************************************************** uname -a: OSF1 lasher.avs.dec.com V4.0 878 alpha ./configure 'alpha-dec-osf4.0d' '--prefix=/usr/local' '--bindir=/usr/local/bin/alpha-dec-osf4.0d' '--with-gcc=no' '--cflags=-g3 -O4' '--site-includes=/udir/carney/local/include' '--site-libraries=/udir/carney/local/lib' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=motif' '--with-xpm' '--with-xface' '--with-tooltalk' '--with-gif' '--with-png' '--with-jpeg' '--with-tiff' '--with-database=dbm' '--with-cde' XEmacs 21.1-p3 "Acadia" configured for `alpha-dec-osf4.0d'. Where should the build process find the source code? /udir/carney/software/xemacs/release What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/decosf4-0.h' and `m/alpha.h' What compiler should XEmacs be built with? cc -g3 -O4 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include Where do we find X Windows libraries? /usr/dt/lib Additional header files: /udir/carney/local/include Additional libraries: /udir/carney/local/lib Runtime library search path: /udir/carney/local/lib:/usr/dt/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in support for DBM. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "flock" for locking mail spool files. ****************************************************** *** Here is result of 'where' from dbx /usr/local/bin/xemacs core ****************************************************** dbx /usr/local/bin/xemacs core dbx version 3.11.10 Type 'help' for help. Core file created by program "xemacs-21.1-p3" signal Segmentation fault at >*[__kill, 0x3ff800edea8] beq r19, 0x3ff800edec0 (dbx) where > 0 __kill(0xa0000001401a4808, 0xa0000001401d72a8, 0xa0000001401a4838, 0xa0000001401a4838, 0x0) [0x3ff800edea8] 1 fatal_error_signal() ["emacs.c":263, 0x1200a0564] 2 menu_item_type(val = 0xdeadbeef) ["xlwmenu.c":1428, 0x1201cc0dc] (dbx) ****************************************************** *** Here is the lisp backtrace ****************************************************** Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) --=-=-=--

1 participants
0 comments

Re: Can't build some texinfo files 24 years, 11 months

Martin Buchholz

>>>>> "sew" == Sandra Wambold <wambold(a)xemacs.org> writes: Mats> I'm also disturbed by the fact that nobody seems to care. I was Mats> hoping for at least "I have the same problem" or "It works OK for me" Mats> but so far not a sound except you asking about a patch. Of course if Mats> nobody is working this way then that would explain the silence. I care. sew> I don't know if anyone is working this way, but I was thinking that I sew> should make whatever texinfo problem might exist go away. No one sew> seems to be taking texinfo files under their wing in general (Yoshiki sew> and I have been working on the FAQ), but perhaps I should worry about sew> the texinfo files in general. I recently sanitized the texinfo files in the XEmacs core. This means making sure they build with: texinfo-3.12 texinfo-3.12f texinfo-4.0 texi2dvi It would be good if someone did the same for the packages. It would be further good if all the release engineers (moiself, Vin, and Andreas) would do this in an automated fashion for every release. sew> I'll dig through the mail archives this weekend to find what work sew> you've done and generate a patch for the file if it needs one. If you decide to do this, you can get access to my machine to do the testing with all the .texi file processing programs. I cc:ed xemacs-beta. Hope that's OK. Martin

1 participants
0 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 January 2000