May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Don't be fancy in stderr_out [Was Re: [FAILURE] CVS @ 10/05/2000 12:12] 24 years, 7 months

Jan Vroonhof

"Daniel Pittman" <daniel(a)danann.net> writes: > #7 0x817ab56 in stderr_out ( > fmt=0x8217480 "malloc_set_state failed, rc = %d\n") at print.c:200 > retval = 27234303 > #8 0x80bb2a0 in main (argc=5, argv=0xbffff944, envp=0xbffff95c) This is the real problem. I can reproduce it now (I was using pdump before). Also on debian unstable.. Jan

1 participants
0 comments

Re: lots of doc updates, some glyph changes 24 years, 7 months

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > hrvoje, i noticed that you went and implemented much of what i > proposed should be done to display tables. this is way cool, and > it's going to save me a lot of time when i get there -- as part of > unicode support, i need really powerful display tables, and you've > gone a long way towards implementation. I'm glad you appreciate it. The most important thing I've done is enabling the use of char-tables and range-tables instead of the old-fashioned 256-element vectors, which really sucked. One important thing that we miss is and that I have _not_ added is the merging of display-tables at redisplay times, so if a character is not found in one display-table (say window-wide), it's looked up in the other one (say frame-wide), and so on until it's now. What happens now is that first the display-table is determined. Then, if the character is not found in that display-table, it's displayed raw. Sucks. The room for the desired behaviour was left by you, as shown in this specifier.c docstring: -- For chartable (e.g. display table) specifiers, MATCHSPEC should be a character, and the specification (a chartable) must give a value for that character in order to be considered. This allows you to specify, e.g., a buffer-local display table that only gives values for particular characters. All other characters are handled as if the buffer-local display table is not there. (Chartable specifiers are not yet implemented.) Unfortunately, I found the redisplay too complex to actually implement this.

2 participants
1 comments

Re: Don't be fancy in stderr_out [Was Re: [FAILURE] CVS @ 10/05/2000 12:12] 24 years, 7 months

Jan Vroonhof

"Daniel Pittman" <daniel(a)danann.net> writes: > make[1]: Entering directory `/usr/src/xemacs/src' > gcc -c -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include print.c > print.c: In function `std_handle_out_va': > print.c:173: warning: `extlen' might be used uninitialized in this function Oops gcc is right. Please use this patch at end instead. This at least compiles without warnings Index: print.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/print.c,v retrieving revision 1.27.2.17 diff -u -r1.27.2.17 print.c --- print.c 2000/03/13 10:04:29 1.27.2.17 +++ print.c 2000/05/11 10:05:37 ＠＠ -166,23 +166,44 ＠＠ msw_output_console_string(). */ static int -std_handle_out_va (FILE *stream, const char *fmt, va_list args) +std_handle_out_va (FILE *stream, int recode, const char *fmt, va_list args) { Bufbyte kludge[8192]; Extbyte *extptr; Extcount extlen; int retval; +#ifdef HAVE_VSNPRINTF + retval = vsnprintf ((char *) kludge, 8191, fmt, args); +#else retval = vsprintf ((char *) kludge, fmt, args); - TO_EXTERNAL_FORMAT (DATA, (kludge, strlen ((char *) kludge)), +#endif + kludge[8191] = 0; + if (recode) + { + TO_EXTERNAL_FORMAT (DATA, (kludge, strlen ((char *) kludge)), ALLOCA, (extptr, extlen), Qnative); + } + else + { + /* We are not doing the proper thing because we might be in + the middle of a crash, so we cast and pray. */ + + extptr = (Extbyte *) kludge; + extlen = strlen((char *) kludge); + } + std_handle_out_external (stream, Qnil, extptr, extlen, 1, 1); return retval; } /* Output portably to stderr or its equivalent; call GETTEXT on the - format string. Automatically flush when done. */ + format string. Automatically flush when done. + + We do not call std_handle_va because that tries to do code conversion + which is not a good idea in the middle of a crash +*/ int stderr_out (const char *fmt, ...) ＠＠ -190,7 +211,7 ＠＠ int retval; va_list args; va_start (args, fmt); - retval = std_handle_out_va (stderr, GETTEXT (fmt), args); + retval = std_handle_out_va (stderr, 0, GETTEXT (fmt), args); va_end (args); return retval; } ＠＠ -204,7 +225,7 ＠＠ int retval; va_list args; va_start (args, fmt); - retval = std_handle_out_va (stdout, GETTEXT (fmt), args); + retval = std_handle_out_va (stdout, 1 , GETTEXT (fmt), args); va_end (args); return retval; } ＠＠ -216,7 +237,7 ＠＠ va_start (args, fmt); stderr_out ("\nXEmacs: "); - std_handle_out_va (stderr, GETTEXT (fmt), args); + std_handle_out_va (stderr, 0, GETTEXT (fmt), args); stderr_out ("\n"); va_end (args);

1 participants
0 comments

Don't be fancy in stderr_out [Was Re: [FAILURE] CVS @ 10/05/2000 12:12] 24 years, 7 months

Jan Vroonhof

"Daniel Pittman" <daniel(a)danann.net> writes: > fmt=0x8208720 "Can't call a conversion function from a conversion function") at eval.c:2266 > #28 0x808ef76 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA, > source=0xbf807824, coding_system=137147428, sink_type=DFC_TYPE_DATA, > sink=0xbf80781c) at buffer.c:1873 > #29 0x817aa53 in std_handle_out_va (stream=0x403d38e0, > fmt=0x8217a20 "Fatal error: assertion failed, file %s, line %d, %s\n", > args=0xbf809858) at print.c:177 > #30 0x817ab2b in stderr_out ( > fmt=0x8217a20 "Fatal error: assertion failed, file %s, line %d, %s\n") > at print.c:193 > #31 0x80bb005 in assert_failed (file=0x8204d06 "lisp.h", line=1425, > expr=0x8204f40 "RECORD_TYPEP (obj, lrecord_type_lcrecord_list)") > at emacs.c:2883 > #32 0x80851f6 in allocate_managed_lcrecord (lcrecord_list=137622592) > at lisp.h:1425 > #33 0x8170f39 in Lstream_new (imp=0x8272f20, mode=0x8248aec "w") > at lstream.c:239 > #34 0x8172ba4 in make_resizing_buffer_output_stream () at lstream.c:1349 > #35 0x80b12c7 in emacs_doprnt_string_va ( > format_nonreloc=0x8208720 "Can't call a conversion function from a conversion function", format_reloc=137029460, format_length=-1, vargs=0xbf809958) > at doprnt.c:830 > #36 0x80bdf94 in error ( > fmt=0x8208720 "Can't call a conversion function from a conversion function") at eval.c:2266 ... repeated a zillion times. Trying to be clever in stderr_out (which can be used in the middle of a crash, redisplay etc) is bad juju. Let's undo that change, so we can at least seee the real problem [Will apply this after I get around to actually testing it] 2000-05-10 Jan Vroonhof <vroonhof(a)math.ethz.ch> * print.c (fatal): (stderr_out): Do not do code conversion. (stdout_out): Do code conversion. (std_handle_out_va): add recode argument. Index: print.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/print.c,v retrieving revision 1.27.2.17 diff -u -r1.27.2.17 print.c --- print.c 2000/03/13 10:04:29 1.27.2.17 +++ print.c 2000/05/10 12:33:08 ＠＠ -166,7 +166,7 ＠＠ msw_output_console_string(). */ static int -std_handle_out_va (FILE *stream, const char *fmt, va_list args) +std_handle_out_va (FILE *stream, int recode, const char *fmt, va_list args) { Bufbyte kludge[8192]; Extbyte *extptr; ＠＠ -174,15 +174,22 ＠＠ int retval; retval = vsprintf ((char *) kludge, fmt, args); - TO_EXTERNAL_FORMAT (DATA, (kludge, strlen ((char *) kludge)), + if (recode) + { + TO_EXTERNAL_FORMAT (DATA, (kludge, strlen ((char *) kludge)), ALLOCA, (extptr, extlen), Qnative); + } std_handle_out_external (stream, Qnil, extptr, extlen, 1, 1); return retval; } /* Output portably to stderr or its equivalent; call GETTEXT on the - format string. Automatically flush when done. */ + format string. Automatically flush when done. + + We do not call std_handle_va because that tries to do code conversion + which is not a good idea in the middle of a crash +*/ int stderr_out (const char *fmt, ...) ＠＠ -190,7 +197,7 ＠＠ int retval; va_list args; va_start (args, fmt); - retval = std_handle_out_va (stderr, GETTEXT (fmt), args); + retval = std_handle_out_va (stderr, 0, GETTEXT (fmt), args); va_end (args); return retval; } ＠＠ -204,7 +211,7 ＠＠ int retval; va_list args; va_start (args, fmt); - retval = std_handle_out_va (stdout, GETTEXT (fmt), args); + retval = std_handle_out_va (stdout, 1 , GETTEXT (fmt), args); va_end (args); return retval; } ＠＠ -216,7 +223,7 ＠＠ va_start (args, fmt); stderr_out ("\nXEmacs: "); - std_handle_out_va (stderr, GETTEXT (fmt), args); + std_handle_out_va (stderr, 0, GETTEXT (fmt), args); stderr_out ("\n"); va_end (args);

2 participants
1 comments

buffer-tabs vs build-report 24 years, 7 months

Robert Pluim

In XEmacs 21.2 (beta32) "Kastor & Polydeukes" [Lucid] (i686-pc-linux) of Tue May 9 2000 on wibble configured using `configure --pdump' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: loading the following file using xemacs -vanilla, cvsupped after Andy Piper's latest patches (~8:40 AM EST, May 9). --begin-- (setq debug-on-error t) (require 'build-report) (custom-set-variables '(gutter-buffers-tab-visible-p nil)) --end-- Produces the following backtrace: Signaling: (wrong-type-argument glyphp nil) wrong-type-argument(glyphp nil) glyph-property-instance(nil image nil nil nil) glyph-image-instance(nil) remove-buffer-from-gutter-tab() kill-buffer(" *Config*") config-value-hash-table() (gethash (quote blddir) (config-value-hash-table)) ) (regexp-quote (gethash (quote blddir) (config-value-hash-table))) ) (concat (regexp-quote (gethash ... ...)) "/lisp/[^ \n]+ hides ") ) (list "confl.*with.*auto-inlining" (concat (regexp-quote ...) "/lisp/[^ \n]+ hides ")) ) eval((list "confl.*with.*auto-inlining" (concat (regexp-quote ...) "/lisp/[^ \n]+ hides "))) custom-initialize-reset(build-report-delete-regexp (list "confl.*with.*auto-inlining" (concat (regexp-quote ...) "/lisp/[^ \n]+ hides "))) custom-declare-variable(build-report-delete-regexp (list "confl.*with.*auto-inlining" (concat (regexp-quote ...) "/lisp/[^ \n]+ hides ")) "Regexp of make process output lines to delete from the report." :type (repeat regexp) :group build-report) load-internal("build-report" nil t nil nil nil) load("build-report" nil t nil) require(build-report) load-internal("/home/rpluim/test.el" nil t nil nil nil) load("/home/rpluim/test.el" nil t) command-line-do-load("-l") command-line-1() command-line() normal-top-level() If I swap the (require) and (custom-set) lines, then everything works fine. Recent keystrokes: ESC x r e p o r t SPC e m TAB RET Recent messages (most recent first): Loading mailcrypt... Loading emacsbug...done Loading emacsbug... Gnuserv process exited; restart with `M-x gnuserv-start' Loading timer...done Loading timer... Loading br-start...done Loading hvar...done Loading hvar... Loading hui-window...done -- The above are my opinions, and my opinions only.

3 participants
3 comments

[21.2.32] Build failure with minimal configuration 24 years, 7 months

Yoshiki Hayashi

gcc -nostdlib -L/usr/X11R6/lib -I/src/xemacs/src -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o debug.o tests.o unexelf.o realpath.o getloadavg.o inline.o event-unixoid.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o lastfile.o free-hook.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lXmu -lXt -lXext -lX11 -lSM -lICE -lm -lgcc -lc -lgcc /usr/lib/crtn.o `gcc -print-libgcc-file-name` glyphs-x.o: In function `x_finalize_image_instance': /src/xemacs/src/glyphs-x.c:415: undefined reference to `ungcpro_popup_callbacks' collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make[1]: Leaving directory `/home/penny/xemacs-bin/minimal/src' make: *** [src] Error 2 ungcpro_popup_callbacks is defined in gui-x.c. Should gui-x.o be linked unconditionally? uname -a: Linux buck.sodan.org 2.2.14 #4 Sun Mar 12 10:02:54 JST 2000 i686 unknown /src/xemacs/configure '--prefix=/opt/local' '--with-dialogs=no' '--without-gif' '--with-jpeg=no' '--with-ldap=no' '--with-sound=no' '--without-tty' '-with-gpm=no' '--with-modules=no' '--with-database=no' '--with-menubars=no' '--with-png=no' '--with-tiff=no' '--with-scrollbars=no' '--without-toolbars' '--with-widgets=no' '--with-xface=no' '--with-xpm=no' '--with-postgresql=no' XEmacs 21.2-b32 "Kastor & Polydeukes" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /src/xemacs Installation prefix: /opt/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw TTY: Images: WARNING: ----------------------------------------------------------- WARNING: Compiling without XPM image support. WARNING: You should strongly consider installing XPM. WARNING: Otherwise toolbars and other graphics will look suboptimal. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) WARNING: ----------------------------------------------------------- WARNING: ----------------------------------------------------------- WARNING: Compiling without PNG image support. WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) WARNING: ----------------------------------------------------------- Sound: Databases: Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- Yoshiki Hayashi

2 participants
1 comments

Re: XEmacs/GTK does menus... 24 years, 7 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > Only the menu about to be popped down is generated (I think the > lwlib menus currently generate the entire menubar when you click in > the menubar, not 100% sure). I'm 100% sure -- I've been seeing it for a while. Because of that, popups with many submenus are extremely slow as they need to evaluate all the :active statements. Things get even worse when filters come into play. > On to toolbars tomorrow - although this will probably be nasty given > that toolbar.c wants to know about pixel positions of the mouse and > things like that. I want to let Gtk handle all that nastiness. > Should be interesting. :) You can always take a look at what Windows people have done. Although I'd rather you wouldn't :), because the mswindows toolbar doesn't behave properly, for instance it doesn't generate motion events when mouse moves over the toolbar.

1 participants
0 comments

Re: Bug#63760: xemacs21: bad content in backtrace window 24 years, 7 months

Yoshiki Hayashi

[ Please remove Cc: xemacs-patches(a)xemacs.org when replying to this mail. ] dwitch <ydirson(a)altern.org> writes: > I trigger debug-on-error from the Options/General menu from "xemacs21 > -q". When triggering an error I sometime have stange infos (unmatched > closing paren on some lines) in the backtrace buffer, which make > debugger-mode barf - I can't use debugger-frame ('b') on frames > following the first of these parens. [...] > ==== > (let ((i 1) j) > (nconc i j)) > ==== > > And the backtrace it produces: > > ===== > Signaling: (wrong-type-argument 1 listp) > nconc(1 nil) > (let ((i 1) j) (nconc i j)) > ) ^ > eval((let ((i 1) j) (nconc i j))) > eval-interactive((let ((i 1) j) (nconc i j))) > eval-last-sexp(nil) > call-interactively(eval-last-sexp) This patch fixes that parenthesis. This patch is for 21.2 but I think it applies to 21.1 cleanly. 2000-05-11 Yoshiki Hayashi <yoshiki(a)xemacs.org> * eval.c (Fbacktrace): Don't output a line with only right parenthesis. Index: eval.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/eval.c,v retrieving revision 1.27.2.22 diff -u -r1.27.2.22 eval.c --- eval.c 2000/04/06 21:57:49 1.27.2.22 +++ eval.c 2000/05/11 05:26:07 ＠＠ -4901,8 +4901,8 ＠＠ Fprin1 (backlist->args[i], stream); } } + write_c_string (")\n", stream); } - write_c_string (")\n", stream); backlist = backlist->next; } } -- Yoshiki Hayashi

1 participants
0 comments

Re: detachable menubars for XEmacs... 24 years, 7 months

Daniel Pittman

On 10 May 2000, William M. Perry <wmperry(a)aventail.com> wrote: > So... I implemented this for GTK (surprisingly simple) and they appear > to work. My question is, how user-configurable should this be? OK, FWIW, I would /not/ want to be able to move the menu bar around. I like it stuck just where it is, and find that the Netscape movable bar gets misplaced every now and then. > Should it be a frame property that is honored at frame-creation time > only (that would be fairly doable). Making it settable after frame > creation could be kind of kludgey and flicker pretty weirdly for a > second or so. I can't see my preferences changing half way through a session, or between frames. If they did, it would be to experiment, and so a little flicker would not bother me... [...] > What about detachable submenus? Please. *This* I like. One of the more useful UI features out there. Daniel -- We fear that pop-culture is the only culture we're ever going to have. We want to stop reading magazines, stop watching tv, stop caring about Hollywood, but we're addicted to the things we hate. -- KMFDF, _Dogma_

1 participants
0 comments

detachable menubars for XEmacs... 24 years, 7 months

William M. Perry

So... I implemented this for GTK (surprisingly simple) and they appear to work. My question is, how user-configurable should this be? Should it be a frame property that is honored at frame-creation time only (that would be fairly doable). Making it settable after frame creation could be kind of kludgey and flicker pretty weirdly for a second or so. Just curious. I plan on doing the same for toolbars. Would be really sweet to have a minibuffer that was detachable like that. How does the detached minibuffer work now? Could I just abuse that and say it is detached and give it a window that is really just sitting inside a GtkHandleBox? Would that work? What about detachable submenus? They way I handle the GCPRO'ing could make that a little difficult. Hrmm. -Bill P.

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 May 2000