December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 27 years

Colin Rafferty

Hrvoje Niksic writes: > Colin Rafferty <craffert(a)ms.com> writes: >> However, the equivalent in 19.13 does not crash, but creates the >> margin annotation correctly. > How can it attach a "pointer" annotation to a buffer? Perhaps it was > a bug in 19.13? I did the code from the sample.emacs from 19.13: (if (featurep 'xpm) (let ((file "/u/sag3_dev4/craffert/xemacs/irix-cvs-2/etc/recycle2.xpm")) (if (condition-case error (make-cursor file) ;returns a cursor if successful. (error nil)) ; returns nil if an error occurred. (setq x-gc-pointer-shape file)))) Then, I redefined `make-annotation' (from 21.0), and ran: (make-annotation x-gc-pointer-shape nil 'text) make-annotation had an error at the end, but the glyph was appropriately in the buffer. Is this a bug in 19.13? Maybe, but I would say that 19.15+ crashing is a much worse bug. -- Colin

1 participants
0 comments

[YetAnotherCrash] 21.2-b5 27 years

Adrian Aichner

And now for a different crash under (emacs-version) "XEmacs 21.2 \"Aphrodite\" [Lucid] (i386-pc-win32) of Mon Dec 14 1998 on DARTER2" NTDLL! 77f76148() start_end_of_last_line(window * 0x109dc400, int 0x00000001, int 0x00000001) line 6621 + 20 bytes end_of_last_line(window * 0x109dc400, int 0x00000001) line 6695 + 15 bytes pixel_to_glyph_translation(frame * 0x109dc600, int 0x00000016, int 0x00000047, int * 0x0082f184, int * 0x0082f178, int * 0x0082f168, int * 0x0082f16c, window * * 0x0082f188, int * 0x0082f18c, int * 0x0082f164, int * 0x0082f17c, Lisp_Object * 0x0082f180, Lisp_Object * 0x0082f174) line 7839 + 29 bytes event_pixel_translation(Lisp_Object {...}, int * 0x00000000, int * 0x00000000, int * 0x00000000, int * 0x00000000, window * * 0x0082f1d4, int * 0x00000000, int * 0x00000000, int * 0x00000000, Lisp_Object * 0x00000000, Lisp_Object * 0x00000000) line 1734 + 66 bytes Fevent_window(Lisp_Object {...}) line 1864 + 31 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082f264) line 3189 + 80 bytes execute_optimized_program(const unsigned char * 0x011cb17c, int 0x00000002, Lisp_Object * 0x011cb150) line 750 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000001, Lisp_Object * 0x0082f548) line 530 + 53 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082f544) line 3221 + 17 bytes execute_optimized_program(const unsigned char * 0x102ea818, int 0x00000009, Lisp_Object * 0x10100c10) line 750 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000001, Lisp_Object * 0x0082f938) line 530 + 53 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082f934) line 3221 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x10100e00, int 0x00000002, Lisp_Object * 0x0082f934, int 0x00000000) line 3671 + 13 bytes run_hook_with_args(int 0x00000002, Lisp_Object * 0x0082f934, int 0x00000000) line 3684 + 23 bytes Frun_hook_with_args(int 0x00000002, Lisp_Object * 0x0082f934) line 3560 + 15 bytes Ffuncall(int 0x00000003, Lisp_Object * 0x0082f930) line 3207 + 14 bytes execute_optimized_program(const unsigned char * 0x1060ab78, int 0x00000003, Lisp_Object * 0x104a39f0) line 750 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0x00000001, Lisp_Object * 0x0082fc24) line 530 + 53 bytes Ffuncall(int 0x00000002, Lisp_Object * 0x0082fc20) line 3221 + 17 bytes call1(Lisp_Object {...}, Lisp_Object {...}) line 3834 + 11 bytes execute_internal_event(Lisp_Object {...}) line 2952 + 16 bytes Fdispatch_event(Lisp_Object {...}) line 4689 + 9 bytes Fcommand_loop_1() line 578 + 9 bytes command_loop_1(Lisp_Object {...}) line 494 condition_case_1(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x0103a7be command_loop_1(Lisp_Object), Lisp_Object {...}, Lisp_Object (Lisp_Object, Lisp_Object)* 0x0103a24b cmd_error(Lisp_Object, Lisp_Object), Lisp_Object {...}) line 1640 + 7 bytes command_loop_3() line 255 + 35 bytes command_loop_2(Lisp_Object {...}) line 267 internal_catch(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x0103a3b3 command_loop_2(Lisp_Object), Lisp_Object {...}, int * volatile 0x00000000) line 1315 + 7 bytes initial_command_loop(Lisp_Object {...}) line 304 + 25 bytes STACK_TRACE_EYE_CATCHER(int 0x00000001, char * * 0x10105680, char * * 0x10208100, int 0x00000000) line 1715 + 9 bytes main(int 0x00000001, char * * 0x10105680, char * * 0x10208100) line 2144 + 21 bytes XEMACS! mainCRTStartup + 180 bytes _start() line 165 KERNEL32! 77f1b304() Happens at call to abort() in src\redisplay.c at line 6621: static Bufpos start_end_of_last_line (struct window *w, Bufpos startp, int end) { struct buffer *b = XBUFFER (w->buffer); line_start_cache_dynarr *cache = w->line_start_cache; int pixpos = 0; int bottom = WINDOW_TEXT_HEIGHT (w); Bufpos cur_start; int start_elt; validate_line_start_cache (w); w->line_cache_validation_override++; if (startp < BUF_BEGV (b)) startp = BUF_BEGV (b); else if (startp > BUF_ZV (b)) startp = BUF_ZV (b); cur_start = startp; start_elt = point_in_line_start_cache (w, cur_start, 0); if (start_elt == -1) => abort (); /* this had better never happen */ Adrian

3 participants
2 comments

Re: [BROKEN?] mmencode.exe 27 years

Norbert Koch

Fabrice POPINEAU <popineau(a)ese-metz.fr> writes: > Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > AFAIK, pgnus-0.65 will allow you to read/send mime messages without > mmencode ! That's correct, also it's horribly slow ... Cheers, norbert. -- Being a BALD HERO is almost as FESTIVE as a TATTOOED KNOCKWURST.

1 participants
0 comments

Re: [BROKEN?] mmencode.exe 27 years

Fabrice POPINEAU

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > leads a somewhat bigger file than sorted-doc.exe. > Could this be a CRLF vs. NL problem on Windows NT native? Check that the file is opened with "rb", and also that stdin is switched to binary mode in case it can be used with redirections. > Is anybody inserting base64 attachments successfully in > XEmacs21.2-b5/"Gnus v5.6.44" under WindowsNT native? AFAIK, pgnus-0.65 will allow you to read/send mime messages without mmencode ! -- Fabrice POPINEAU ------------------------ e-mail: popineau(a)ese-metz.fr | "God is real ... Fabrice.POPINEAU(a)supelec.fr | voice-mail: +33 (0) 387764715 | ... unless integer ?" surface-mail: Supelec, 2 rue E. Belin, | F-57078 Metz Cedex 3 |

1 participants
0 comments

pcl-cvs package comments, update `request' 27 years

Adrian Aichner

Hello Greg, I spent some time today to get PCL-CVS's e runs `cvs-mode-ediff' working on native NT. Fixed temp-directory handling along the way. Then I decided to verify my patch against the CVS sources. Much to my pleasant surprise you had incorporated these changes already, and somewhat more general than my solution would have been. So I tried xemacs-pcl-cvs and it works fine. I had to do an unorthodox installation of xemacs-pcl-cvs under my package path and generated the info doc from within XEmacs since I don't have makeinfo on NT. Now for a sensitive subject: Colors :O) Cvs Filename Face: (sample) * PCL-CVS face used to highlight file names. Looks good. Cvs Handled Face: (sample) * PCL-CVS face used to highlight handled file status. "pink" is almost invisible on grayish backgrounds. How about changing this to "orchid" or "dark orchid", which is similar, but visible on gray background. Cvs Header Face: (sample) * PCL-CVS face used to highlight directory changes. Looks good. Cvs Marked Face: (sample) * PCL-CVS face used to highlight marked file indicator. "green" looks vitriolic on my display at least. How about using the general signaling color "red" here? Cvs Need Action Face: (sample) * PCL-CVS face used to highlight status of files needing action. "orange" looks good. These files get the attention they need. Cvs Unknown Face: (sample) * PCL-CVS face used to highlight unknown file status. "red" draws all attention to these files, while they may well be un-interesting in many cases. How about using "forest green" for these. I realize colors are a subject of taste. However, they can make a big difference to make one feel at home. I, for one, hate the default of "red" for font-lock-comment-face. It makes me feel guilty when I write a comment into the source-code. So I use "forest green" for comments. The more comments I write, the greener gets the environment I work in. PCL-CVS works great on Windows NT with the changes you've made since the latest binary package. Do you know when the latest changes will percolate into a package installable via Options->Manage Packages from xemacs.org? Best regards, Adrian

2 participants
1 comments

[BROKEN?] mmencode.exe 27 years

Adrian Aichner

Hello All! mmencode.exe builds fine under 21.2-b5 (and 21.2-b{59,60}) but does not seem to work right under 21.2-b5 at least. Below is the output of some experiments I did: find-file sorted-doc.exe mark-whole-buffer base64-encode-region write-file sorted-doc.64intern (add newline? no) leads the file shown below. Decoding that buffer internally with base64-decode-region write-file sorted-doc.intern leads a somewhat bigger file than sorted-doc.exe. Could this be a CRLF vs. NL problem on Windows NT native? This was the good part! Using ./mmencode -b -o sorted-doc.64 sorted-doc.exe leads a file way too small. Who knows why? I tried protable-newlines mode which fails too: ./mmencode -p -b -o sorted-doc.64p sorted-doc.exe c:\Program Files\XEmacs\XEmacs-21.2-b5\i386-pc-win32: total 4924 -rw-rw-rw- 1 AichnerA 5 4918 Dec 15 00:36 sorted-doc.64 -rw-rw-rw- 1 AichnerA 5 42696 Dec 15 00:56 sorted-doc.64intern -rw-rw-rw- 1 AichnerA 5 4934 Dec 15 00:37 sorted-doc.64p -rwxrwxrwx 1 AichnerA 5 31232 Dec 14 12:19 sorted-doc.exe -rw-rw-rw- 1 AichnerA 5 31322 Dec 15 00:57 sorted-doc.intern Is anybody inserting base64 attachments successfully in XEmacs21.2-b5/"Gnus v5.6.44" under WindowsNT native? Regards, Adrian

1 participants
0 comments

Re: [WANTED] movemail.exe with MAIL_USE_POP on native Windows NT 27 years

Adrian Aichner

>>>>> "Fabrice" == Fabrice POPINEAU <popineau(a)ese-metz.fr> writes: Fabrice> [1 <text/plain; us-ascii (7bit)>] Fabrice> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> When I define MAIL_USE_POP, I can't get movemail.c compile due to >> undefined macros like O_CREAT. I tried compiling with HAVE_FCNTL_H >> too, to get <fcntl.h> included. Even adding _POSIX_=1 did not do the >> trick. >> >> As always, any help would be appreciated. >> >> Adrian >> Fabrice> This is the quick and dirty one that will do the Fabrice> trick. Something is wrong with native win32 in Fabrice> src/systime.h, because including winsock bugs withe Fabrice> redefinition of dome types. Fabrice> Also, movemail.exe need to be linked to winsock to use pop. Fabrice> I guess there are cleaner ways to handle the cases Fabrice> login/password stuff, but I doubt they are useful under Fabrice> native win32. Hello Fabrice, the patch below has one problem: I could not a apply it to a freshly checked out 21.2-b5 because there is no src\config.h before running xemacs.mak. This part of the patch should be against nt\config.h instead. Other than that the patch works fine and produces a functional movemail.exe on WindowsNT native. Thanks, Adrian Fabrice> -- Fabrice> Fabrice POPINEAU Fabrice> ------------------------ Fabrice> e-mail: popineau(a)ese-metz.fr | "God is real ... Fabrice> Fabrice.POPINEAU(a)supelec.fr | Fabrice> voice-mail: +33 (0) 387764715 | ... unless integer ?" Fabrice> surface-mail: Supelec, 2 rue E. Belin, | Fabrice> F-57078 Metz Cedex 3 | Fabrice> - /tmp/xemacs.patch Fabrice> [2 xemacs.patch <application/octet-stream>]

1 participants
0 comments

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 27 years

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > However, the equivalent in 19.13 does not crash, but creates the > margin annotation correctly. How can it attach a "pointer" annotation to a buffer? Perhaps it was a bug in 19.13?

1 participants
0 comments

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 27 years

Colin Rafferty

SL Baur writes: > Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: > ... >> I can reproduce this in a vanilla XEmacs. >> Here is the Lisp code (assuming that you have a recycle2.xpm glyph). >> Note that this will not happen if you use the default gc-pointer-glyph. >> (if (featurep 'xpm) >> (let ((file (locate-data-file "recycle2.xpm"))) >> (if (condition-case error >> (make-image-instance file nil >> '(pointer)) >> (error nil)) >> (set-glyph-image gc-pointer-glyph file)))) >> (make-annotation gc-pointer-glyph nil 'text) > This sequence crashes on me. > Fatal error: assertion failed, file redisplay-x.c, line 491, abort() I don't know if it makes you feel better or worse, but it also crashes 19.16 and 19.15. However, the equivalent in 19.13 does not crash, but creates the margin annotation correctly. -- Colin

1 participants
0 comments

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 27 years

Raymond Toy

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: sb> ... >> I can reproduce this in a vanilla XEmacs. >> Here is the Lisp code (assuming that you have a recycle2.xpm glyph). >> Note that this will not happen if you use the default gc-pointer-glyph. >> (if (featurep 'xpm) >> (let ((file (locate-data-file "recycle2.xpm"))) >> (if (condition-case error >> (make-image-instance file nil >> '(pointer)) >> (error nil)) >> (set-glyph-image gc-pointer-glyph file)))) >> (make-annotation gc-pointer-glyph nil 'text) sb> This sequence crashes on me. sb> Fatal error: assertion failed, file redisplay-x.c, line 491, abort() Same here, on a Solaris 2.5.1 box, gcc 2.7.2.x, xemacs 21.0 b60. A snip of the traceback is: #0 0xef0f452c in kill () #1 0x9326c in fatal_error_signal (sig=6) at emacs.c:262 #2 <signal handler called> #3 0xef0f452c in kill () #4 0xef0ba5d4 in abort () #5 0x95e9c in assert_failed (file=0x2a9c48 "redisplay-x.c", line=491, expr=0x2a9ca0 "abort()") at emacs.c:2608 #6 0x20e9dc in x_output_display_block (w=0x5abe00, dl=0x74d3f0, block=7632256, start=18, end=46, start_pixpos=19, cursor_start=359, cursor_width=5, cursor_height=13) at redisplay-x.c:491 #7 0x1b30a4 in compare_display_blocks (w=0x5abe00, cdl=0x7613f0, ddl=0x74d3f0, c_block=46, d_block=0, start_pixpos=19, cursor_start=359, cursor_width=5, cursor_height=13) at redisplay-output.c:419 #8 0x1b4c1c in output_display_line (w=0x5abe00, cdla=0x5f3780, ddla=0x5f3760, line=14, force_start=19, force_end=580) at redisplay-output.c:659 #9 0x1b6e80 in redisplay_output_window (w=0x5abe00) at redisplay-output.c:1318 #10 0x1a3c04 in redisplay_window (window=5946880, skip_selected=468) at redisplay.c:5241 #11 0x1a4448 in redisplay_frame (f=0x537200, preemption_check=0) at redisplay.c:5417 #12 0x1a4764 in redisplay_device (d=0x3ee200) at redisplay.c:5501 #13 0x1a4d2c in redisplay_without_hooks () at redisplay.c:5617 #14 0x1a4f64 in redisplay () at redisplay.c:5685 #15 0xfbe68 in Fnext_event (event=543365704, prompt=-1606610940) at event-stream.c:2238 #16 0x71ab8 in Fcommand_loop_1 () at cmdloop.c:570 #17 0x71708 in command_loop_1 (dummy=-1606610940) at cmdloop.c:494 #18 0x98fb0 in condition_case_1 (handlers=3743744, bfun=0x71664 <command_loop_1>, barg=-1606610940, hfun=0x71c58 <cmd_error>, harg=-1606610940) at eval.c:1653 #19 0x71d6c in command_loop_2 (dummy=-1606610940) at cmdloop.c:256 #20 0x98ba0 in internal_catch (tag=-1606532996, func=0x71d20 <command_loop_2>, arg=-1606610940, threw=0x0) at eval.c:1328 #21 0x70da0 in initial_command_loop (load_me=466208) at cmdloop.c:305 #22 0x94c6c in xemacs_21_0_b60_sparc_sun_solaris2_5_1 (argc=1, argv=0xefffe94c, envp=0xefffe954, restart=0) at emacs.c:1705 #23 0x95420 in main (argc=0, argv=0xefffe94c, envp=0xefffe954) at emacs.c:2122 Ray

1 participants
0 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 December 1998