June 2001 - XEmacs-Beta - XEmacs Mailing List Archives

o.t

I have Xemacs 21.4.3, Linux Mandrake 8.0 x86 and latest efs 1.25. I choose a download site in "Tools->Packages->Add Download Site" and then I choose "Tools->Packages->List and Install" Then I get the following messages in reverse order: ------------------------------------- End of file or stream: #<killed buffer> Retrieving /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/package-index.LATEST...done Retrieving /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/package-index.LATEST... Listing /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/...done Listing /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/... CWD'ing to /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/...done CWD'ing to /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/... CWD'ing to /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/package-index.LATEST/... Getting pwd...done Getting pwd... Logging in as user anonymous...done; MOTD of 19 lines Logging in as user anonymous... Opening FTP connection to ftp.xemacs.org... ---------------------------------------- Then no buffer with the packages appears. I choose again "List and Install" and receive the following messages: -------------------- End of file or stream: #<killed buffer> Retrieving /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/package-index.LATEST...done Retrieving /anonymous＠ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/package-index.LATEST... -------------- The same happens every time then. Here's the FTP buffer: --------------------------------- 230 Anonymous access granted, restrictions apply. ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> quote pwd 257 "/" is current directory. ftp> quote syst 215 UNIX Type: L8 quote cwd /pub/xemacs/beta/experimental/packages/package-index.LATEST/ ftp> 550 /pub/xemacs/beta/experimental/packages/package-index.LATEST/: Not a directory ftp> quote site idle 500 'SITE IDLE' not understood. ftp> quote cwd /pub/xemacs/beta/experimental/packages/ 250 CWD command successful. ftp> ls "-al" /home/oleg/tmp/efsb0H7eJ 200 PORT command successful. 150 Opening ASCII mode data connection for file list. 226 Transfer complete. ftp> type image 200 Type set to I. ftp> get /pub/xemacs/beta/experimental/packages/package-index.LATEST /home/oleg/tmp/efsb0H7eJ.LATEST 200 PORT command successful. 150 Opening BINARY mode data connection for /pub/xemacs/beta/experimental/packages/package-index.LATEST (51004 bytes). ################################################# 226 Transfer complete. 51004 bytes received in 7.06 secs (7.1 Kbytes/sec) ftp> get /pub/xemacs/beta/experimental/packages/package-index.LATEST /home/oleg/tmp/efsc0H7eJ.LATEST 200 PORT command successful. 150 Opening BINARY mode data connection for /pub/xemacs/beta/experimental/packages/package-index.LATEST (51004 bytes). ################################################# 226 Transfer complete. 51004 bytes received in 7.27 secs (6.8 Kbytes/sec) --------------------------

3 participants
2 comments

re: XEmacs from CVS is randomly crashing and locking up 24 years, 1 month

Paul Krause

In Message-ID: < yz13d9j97zf.fsf(a)milhouse.cs.cornell.edu <http://list-archive.xemacs.org/xemacs-beta/200106/msg00018.html> > , Paul Stodghill writes: > Window procedure called during GC??????? > Window procedure called during GC??????? > Window procedure called during GC??????? > Fatal error: assertion failed, file events.h, line 496, RECORD_TYPEP (obj, lrecord_type_event) Any clues on this? I'm getting it regularly. The stack trace looks like NTDLL! 77f9eea9() error_check_event(long 41301336) line 496 + 59 bytes dequeue_event(long * 0x011b2434, long * 0x011b2544) line 870 + 9 bytes mswindows_dequeue_dispatch_event() line 1051 + 72 bytes emacs_mswindows_next_event(Lisp_Event * 0x02763584) line 3358 + 5 bytes event_stream_next_event(Lisp_Event * 0x02763584) line 502 + 13 bytes next_event_internal(long 41301380, int 0) line 1942 + 9 bytes Faccept_process_output(long 34915584, long 28332036, long 28332036) line 2598 + 11 bytes Ffuncall(int 2, long * 0x0082d41c) line 3427 + 127 bytes execute_optimized_program(unsigned char * 0x0082d618, int 10, long * 0x01c14c90) line 744 + 16 bytes Fbyte_code(long 29378148, long 29445248, long 21) line 2392 + 38 bytes Feval(long 29341212) line 3229 + 187 bytes internal_catch(long 29342924, long (long)* 0x0107272c Feval(long), long 29341212, int * 0x00000000) line 1317 + 7 bytes execute_rare_opcode(long * 0x0082d928, unsigned char * 0x0200f0a5, int 141) line 1250 + 22 bytes execute_optimized_program(unsigned char * 0x0200f010, int 9, long * 0x01bc3410) line 654 + 17 bytes funcall_compiled_function(long 29363608, int 6, long * 0x0082dc14) line 516 + 53 bytes Ffuncall(int 7, long * 0x0082dc10) line 3462 + 17 bytes Fapply(int 6, long * 0x0082dd08) line 3703 + 13 bytes Ffuncall(int 7, long * 0x0082dd04) line 3448 + 14 bytes execute_optimized_program(unsigned char * 0x01ff2610, int 7, long * 0x01d1f310) line 744 + 16 bytes funcall_compiled_function(long 30551336, int 6, long * 0x0082dfec) line 516 + 53 bytes Ffuncall(int 7, long * 0x0082dfe8) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x0217b910, int 8, long * 0x01e74b10) line 744 + 16 bytes funcall_compiled_function(long 34901876, int 0, long * 0x0082e2d4) line 516 + 53 bytes Ffuncall(int 1, long * 0x0082e2d0) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x02181010, int 5, long * 0x0206c910) line 744 + 16 bytes funcall_compiled_function(long 33276132, int 0, long * 0x0082e5b0) line 516 + 53 bytes Ffuncall(int 1, long * 0x0082e5ac) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x01b06090, int 6, long * 0x01e54c90) line 744 + 16 bytes funcall_compiled_function(long 33276104, int 0, long * 0x0082e890) line 516 + 53 bytes Ffuncall(int 1, long * 0x0082e88c) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x02173d50, int 1, long * 0x01e5b390) line 744 + 16 bytes funcall_compiled_function(long 34901792, int 0, long * 0x0082ec60) line 516 + 53 bytes Ffuncall(int 1, long * 0x0082ec5c) line 3462 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x02193e00, int 1, long * 0x0082ec5c, int 0) line 3919 + 13 bytes run_hook_with_args(int 1, long * 0x0082ec5c, int 0) line 3932 + 23 bytes Frun_hooks(int 1, long * 0x0082ec5c) line 3786 + 19 bytes Ffuncall(int 2, long * 0x0082ec58) line 3448 + 14 bytes execute_optimized_program(unsigned char * 0x0217ba10, int 5, long * 0x01c76110) line 744 + 16 bytes funcall_compiled_function(long 29888036, int 2, long * 0x0082ef38) line 516 + 53 bytes Ffuncall(int 3, long * 0x0082ef34) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x0082f114, int 3, long * 0x01c7e910) line 744 + 16 bytes Fbyte_code(long 29934436, long 29878528, long 7) line 2392 + 38 bytes Feval(long 29520452) line 3229 + 187 bytes condition_case_1(long 29322924, long (long)* 0x0107272c Feval(long), long 29520452, long (long, long)* 0x0106fbf4 run_condition_case_handlers(long, long), long 28505748) line 1651 + 7 bytes condition_case_3(long 29520452, long 28505748, long 29322924) line 1732 + 27 bytes execute_rare_opcode(long * 0x0082f478, unsigned char * 0x0217bdec, int 143) line 1269 + 19 bytes execute_optimized_program(unsigned char * 0x0217bd10, int 6, long * 0x01c76210) line 654 + 17 bytes funcall_compiled_function(long 29888008, int 1, long * 0x0082f760) line 516 + 53 bytes Ffuncall(int 2, long * 0x0082f75c) line 3462 + 17 bytes execute_optimized_program(unsigned char * 0x021abf90, int 3, long * 0x01c81ad0) line 744 + 16 bytes funcall_compiled_function(long 29887616, int 2, long * 0x0082fa2c) line 516 + 53 bytes Ffuncall(int 3, long * 0x0082fa28) line 3462 + 17 bytes Fcall_interactively(long 29232284, long 28332036, long 28332036) line 1008 + 22 bytes Fcommand_execute(long 29232284, long 28332036, long 28332036) line 2868 + 17 bytes execute_command_event(command_builder * 0x01b64e40, long 35161872) line 3902 + 25 bytes Fdispatch_event(long 35161872) line 4194 + 70 bytes Fcommand_loop_1() line 583 + 9 bytes command_loop_1(long 28332036) line 495 condition_case_1(long 28332132, long (long)* 0x0105134b command_loop_1(long), long 28332036, long (long, long)* 0x01050d60 cmd_error(long, long), long 28332036) line 1651 + 7 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 28332036) line 268 internal_catch(long 28453276, long (long)* 0x01050eb0 command_loop_2(long), long 28332036, int * 0x00000000) line 1317 + 7 bytes initial_command_loop(long 28332036) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b49fe8, char * * 0x01d28900, int 0) line 2348 + 9 bytes main(int 1, char * * 0x01b49fe8, char * * 0x01d28900) line 2777 + 21 bytes mainCRTStartup + 211 bytes _start() line 170 KERNEL32! 77e992a6()

1 participants
0 comments

Compilation fix for 21.4.3 --without-x 24 years, 1 month

Andrew J Cosgriff

oops :) Enjoy, Cos -- Andrew J Cosgriff <ajc(a)polydistortion.net> exterminate all rational thought ! Index: src/event-stream.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-stream.c,v retrieving revision 1.49.2.2 diff -u -r1.49.2.2 event-stream.c --- src/event-stream.c 2001/05/15 12:13:50 1.49.2.2 +++ src/event-stream.c 2001/06/04 08:41:34 ＠＠ -3785,7 +3785,7 ＠＠ EQ (fun, Qscrollbar_to_right) || EQ (fun, Qscrollbar_horizontal_drag)); #else - return 0 + return 0; #endif }

1 participants
0 comments

GTK+ and 21.2 24 years, 1 month

Doug Alcorn

After seeing the "Call for Testers" for 21.2/22.0, I thought I would jump on the bandwagon. I'm primarily interested in the GTK+ port. So, I went out and grabbed the latest xemacs from cvs with: $ cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot checkout -d xemacs-21.2 -r release-21-2 xemacs When I run ./configure, I don't see anything about enabling gtk+. Has the gtk+ port been merged in with 21.2 yet? Is it the default toolkit? How do I compile xemacs with GTK+ support? -- (__) Doug Alcorn (mailto:doug＠lathi.net http://www.lathi.net) oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.

4 participants
3 comments

Attempted XEmacs<->Monier regexp sync 24 years, 1 month

Jan Vroonhof

I cannot quite keep up with reading my XEmacs e-mail at the moment, so I am no use for the day to day stuff. In order to still do some useful things, I decided to have a go at syncing Stefan Monnier's regexp's changes. I am about halfway ("default:" case of regexp_compile). Here is what I am doing: /* Synched up with: FSF 21.0 */ /* Changes made for XEmacs/Sync policy: JV: Stefan Monnier has done substantial work on the FSF 21.0 regexp implementation, making it compatible with the XEmacs version by also implementing shy groups and minimal matching. During doing so he discovered a lot problems in corner cases leading to incorrect matching and infinite loops. Although some have since been fixed in the XEmacs version this sync replaces our algorithm with his. In addition I have tried to reduce gratuitous differences to reduce the pain of syncing in the future. In case of algorithmic differences: - Use sm's version - except in the handling of charset range table where the XEmacs implementation (using a separate bytecode & rangetables from rangetab.c) has been favored over sm's private regexp rangetables. In case of notational differences: - Preferably removed if gratuitous (favoring sm's). buf_end vs b is the major remaining offender. - The XEmacs specific MULE coding standards, #ifdef MULE, INC_CHARPTR etc have been kept - In case of of K&R, LIBC etc etc compatability cruft on the FSF side, the XEmacs status quo (strict use of ISO C prototypes, REGISTER) has been kept. Whitespace: - To reduce the size of the XEmacs diff I have not synced up whitespace. This would be a worthwile excercise to reduce clutter in ediff. */

2 participants
1 comments

21.4.3 crashing 24 years, 1 month

Arkadiusz Miskiewicz

hi, my xemacs 21.4.3 (-O2 -march=i686) is crashing in gnus when i want to save some attachment (trough mouse menu->save). Unfortunately I can't track this problem because after compiling with -g -O0 it doesn't want to crash :-( It just displays: Warning: XtRemoveGrab asked to remove a widget not on the list I checked 21.4 cvs branch (release-21.4) but I didn't find any fixes (moreover there is no changes at all comparing to .3 release, strange). And I tried 21.5 (cvs version from today) and here problem occur, too but now I have backtrace (below). Patch fixing this *is welcome*. Program received signal SIGSEGV, Segmentation fault. 0x40272ea2 in XtIsSubclass () from /usr/X11R6/lib/libXt.so.6 (gdb) bt #0 0x40272ea2 in XtIsSubclass () from /usr/X11R6/lib/libXt.so.6 #1 0x40273e1c in XtDisplayOfObject () from /usr/X11R6/lib/libXt.so.6 #2 0x40145998 in XmImVaSetValues () from /usr/X11R6/lib/libXm.so.2 #3 0x40143061 in _XmImFreeShellData () from /usr/X11R6/lib/libXm.so.2 #4 0x4014bc5c in _XmRemoveGrab () from /usr/X11R6/lib/libXm.so.2 #5 0x40268c00 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #6 0x40268a1e in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #7 0x40268f59 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #8 0x4026905d in _XtDoPhase2Destroy () from /usr/X11R6/lib/libXt.so.6 #9 0x40269209 in XtDestroyWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x082005df in x_delete_frame (f=0x8bfab98) at frame-x.c:2692 #11 0x08147111 in delete_frame_internal (f=0x8bfab98, force=0, called_from_delete_device=0, from_io_error=0) at frame.c:1554 #12 0x0814767e in Fdelete_frame (frame=146779032, force=137290948) at frame.c:1703 #13 0x080c7a8c in Ffuncall (nargs=2, args=0xbfffe368) at eval.c:3427 #14 0x080964bc in execute_optimized_program ( program=0xbfffe3c4 "ÄÅ!\210Æ\n!\210Ç\t!\210Ç\b!\210\013«\005Ç\013!\210Ä\207¤Í\b\001", stack_depth=2, constants_data=0x847f630) at bytecode.c:744 #15 0x0809999c in Fbyte_code (instructions=138307572, constants=138933792, stack_depth=5) at bytecode.c:2392 #16 0x080c7019 in Feval (form=138913372) at eval.c:3229 #17 0x080cd6fe in Fprogn (args=138066980) at eval.c:775 #18 0x080ca5ac in unbind_to_hairy (count=29) at eval.c:4877 #19 0x08096571 in execute_optimized_program ( program=0x8bc61c8 "\0161Æa\032ÇÈ!\034\n\004ÉÊ!\031ÉÊ!\030Ë \035Ì\211\e\036.Ì\0362Í\216Î\f!\210Ï\r!\210Ð\0364ÑÌÒ\r!ÓZ\"\210)\n«\eÔÕ!\210Ö\r!\023×\r!\026.Ø\013\f\"\210Ø\016.\t\"\210ª\nÙ\r!\023Ø\013\f\"\210\f\t\013\016.F\0262ØÚ\r!\b\"\210Û\036/\fq\210ÜÝ\016/\"\210\n«\n\tq\210ÜÝ\016/\"\210)Þßà\"\210\bq\210á\0163!\210\0160«\005\0160\0265âã!«\bä\0166å\b#\210æc\210çèéê\"!\210æc\210çèëì\"!\210í\0167\0163\0160\0168\0169\016:\0161"..., stack_depth=9, constants_data=0x847f760) at bytecode.c:757 #20 0x080960d3 in funcall_compiled_function (fun=138912940, nargs=7, args=0xbfffe75c) at bytecode.c:516 #21 0x080c7c37 in Ffuncall (nargs=8, args=0xbfffe758) at eval.c:3462 #22 0x080964bc in execute_optimized_program ( program=0xbfffe7d4 "Æ\r\f\013\n\t\b\016\a&\a\207xz\f\bt×z\b\001", stack_depth=8, constants_data=0x847f3a0) at bytecode.c:744 #23 0x0809999c in Fbyte_code (instructions=138821580, constants=138933136, stack_depth=17) #24 0x080c7019 in Feval (form=138854080) at eval.c:3229 #25 0x080c43f0 in run_condition_case_handlers (val=137923628, var=137290948) at eval.c:775 #26 0x080c4867 in condition_case_3 (bodyform=138860532, var=137290948, handlers=138854500) at eval.c:1634 #27 0x08096f9f in execute_rare_opcode (stack_ptr=0xbfffeb10, program_ptr=0x8bc5b48 "\207ÊËÌ\"\210Í\r\f\013\n\t\b\016\016&\a\207Te9", opcode=Bcondition_case) at bytecode.c:1269 #28 0x080962be in execute_optimized_program ( program=0x8bc5b40 "Æ «\006ÇÈÉ\217\207ÊËÌ\"\210Í\r\f\013\n\t\b\016\016&\a\207Te9", stack_depth=8, constants_data=0x8481440) at bytecode.c:654 #29 0x080960d3 in funcall_compiled_function (fun=138912212, nargs=7, args=0xbfffec6c) at bytecode.c:516 #30 0x080c7c37 in Ffuncall (nargs=8, args=0xbfffec68) at eval.c:3462 #31 0x080964bc in execute_optimized_program ( program=0x8bc5b00 "Æ\013®\002Ç\n\f\t®\025\r«\nÈÉ\r\f\"Ê\"®\t\b\006È\016\fÊ\"\016\r\rË&\a\207ctively1", stack_depth=8, constants_data=0x8481490) at bytecode.c:744 #32 0x080960d3 in funcall_compiled_function (fun=138912240, nargs=2, args=0xbfffedcc) at bytecode.c:516 #33 0x080c7c37 in Ffuncall (nargs=3, args=0xbfffedc8) at eval.c:3462 #34 0x080964bc in execute_optimized_program ( program=0x8bc5aa0 "À\tA＠Â\"\032ÀÃ\t8Ä\"\034Å\036\006\f«\005Ç\f!\024ÈÉÊ\f®\005\n®\002Ë\016\f®\003\016\r\"\"\026\006Î\016\006!\026\fÏ\016\006!«\nÐÑÒ\016\006\"!\006Ó\t\016\006\"+\207ubleA", stack_depth=5, constants_data=0x8723b18) at bytecode.c:744 #35 0x080960d3 in funcall_compiled_function (fun=142458280, nargs=1, args=0xbfffef1c) at bytecode.c:516 #36 0x080c7c37 in Ffuncall (nargs=2, args=0xbfffef18) at eval.c:3462 #37 0x080964bc in execute_optimized_program ( program=0x8bc5108 "À \210Á`Â\"\211\e\004Ä\013!)\207(", stack_depth=4, constants_data=0x8a0cfd8) at bytecode.c:744 #38 0x080960d3 in funcall_compiled_function (fun=144661800, nargs=0, args=0xbffff098) at bytecode.c:516 #39 0x080c7c37 in Ffuncall (nargs=1, args=0xbffff094) at eval.c:3462 #40 0x080cc833 in apply1 (fn=144661800, arg=137290948) at eval.c:4051 #41 0x0809a6fc in Fcall_interactively (function=144563892, record_flag=137290948, keys=137290948) at callint.c:465 #42 0x080c7aa1 in Ffuncall (nargs=2, args=0xbffff298) at eval.c:3427 #43 0x080964bc in execute_optimized_program ( program=0x8bc43a0 "ÀÁÂÃ\f\"B!\035Æ\016\a!q\210È\016\a!b\210É\r!Ê\r!!)\207", stack_depth=5, constants_data=0x871cde8) at bytecode.c:744 #44 0x080960d3 in funcall_compiled_function (fun=142761592, nargs=1, args=0xbffff3f8) at bytecode.c:516 #45 0x080c7c37 in Ffuncall (nargs=2, args=0xbffff3f4) at eval.c:3462 #46 0x0809c0ab in Fcall_interactively (function=143258940, record_flag=137290948, keys=137290948) at callint.c:1008 #47 0x080c63d6 in Fcommand_execute (cmd=143258940, record_flag=137290948, keys=137290948) at eval.c:2868 #48 0x08117a9a in execute_command_event (command_builder=0x8601818, event=142268160) at event-stream.c:3902 #49 0x081186ee in Fdispatch_event (event=142268160) at event-stream.c:4234 #50 0x080a5c97 in Fcommand_loop_1 () at cmdloop.c:583 #51 0x080a5f2a in command_loop_1 (dummy=137290948) at cmdloop.c:494 #52 0x080cd417 in condition_case_1 (handlers=137291044, bfun=0x80a5eec <command_loop_1>, barg=137290948, hfun=0x80a5fa0 <cmd_error>, harg=137290948) at eval.c:1651 #53 0x080a609f in command_loop_2 (dummy=137290948) at cmdloop.c:256 #54 0x080cd2dc in internal_catch (tag=137367524, func=0x80a605c <command_loop_2>, arg=137290948, threw=0x0) at eval.c:1317 #55 0x080a5507 in initial_command_loop (load_me=137290948) at cmdloop.c:305 #56 0x080c01a3 in xemacs_21_5_b1_i686_pld_linux () at emacs.c:2348 #57 0x080c2269 in main () at emacs.c:2777 #58 0x404197d1 in __libc_start_main () from /lib/libc.so.6 ps. binary data in backtrace seems be messed by mouse copy&&paste from non-console... weird. -- Arkadiusz Miśkiewicz, AM2-6BONE, 1024/3DB19BBD http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ IPv6 ready PLD/Linux at http://www.pld.org.pl/

1 participants
0 comments

Windows NT redisplay bug or feature? 24 years, 1 month

Nickolay Pakoulin

It seems to me that both 21.4.3 and 21.5.1 do not redraw toolbars and scrollbars until mouse pointer enters the frame. To reproduce: minimize frame and then restore it. On my win2000 SP1 toolbars and scrollbars do not redraw until I move mouse pointer inside the frame. No screenshots are available because when i press PrintScreen button xemacs redraws and appeares on the screenshot in all its beauty :)) It is in no way annoying but *stable* xemacs shoud not behave like this, IMHO. Nick.

2 participants
1 comments

Re: smtpmail.el fix for AUTH LOGIN (PR#1687) 24 years, 1 month

Gunnar Evermann

Simon, could you look into this? Gunnar donpellegrino(a)computer.org writes: > Full_Name: Don Pellegrino > OS: Windows 2000 Pro > Version: 21.4 Solid Vapor > mule: no > severity: Aggravating > Submission from: (NULL) (151.197.120.90) > > > The current version of smtpmail.el in the mail-lib package > (mail-lib-1.37-pkg.tar.gz) only supports the SMTP AUTH mechanism "cram-md5". > There is code in the file to handle the SMTP AUTH "login" mechanism but due to > bug/typo the login mechanism is never used. Below are pasted the ediff of the > changes I made and the original file. AUTH LOGIN is now working fine for me. > On another note, perhaps there is an easier way to implemented all of the AUTH > SASL mechanisms by tying some sort of SASL package with the SMTP AUTH function? > Let me know if you need more info on this bug. > > *** C:\DOCUME~1\don\LOCALS~1\Temp\smtpmail.el Wed May 16 15:09:58 2001 > --- C:\DOCUME~1\don\LOCALS~1\Temp\smtpmail.elIUAeow Wed May 16 15:09:58 2001 > *************** > *** 185,191 **** > (defvar smtpmail-queue-index (concat smtpmail-queue-dir > smtpmail-queue-index-file)) > > ! (defconst smtpmail-auth-supported '(cram-md5) > "List of supported SMTP AUTH mechanisms.") > > ;;; > --- 185,191 ---- > (defvar smtpmail-queue-index (concat smtpmail-queue-dir > smtpmail-queue-index-file)) > > ! (defconst smtpmail-auth-supported '(cram-md5 login) > "List of supported SMTP AUTH mechanisms.") > > ;;; > *************** > *** 510,516 **** > (not (integerp (car response-code))) > (>= (car response-code) 400)) > (throw 'done nil))))) > ! ((member 'auth=login supported-extensions) > (smtpmail-send-command process "AUTH LOGIN") > (if (or (null (car (setq response-code (smtpmail-read-response > process)))) > (not (integerp (car response-code))) > --- 510,518 ---- > (not (integerp (car response-code))) > (>= (car response-code) 400)) > (throw 'done nil))))) > ! ( > ! ;(member 'auth=login supported-extensions) > ! (eq mech 'login) > (smtpmail-send-command process "AUTH LOGIN") > (if (or (null (car (setq response-code (smtpmail-read-response > process)))) > (not (integerp (car response-code))) >

3 participants
3 comments

XEmacs from CVS is randomly crashing and locking up 24 years, 1 month

Paul Stodghill

In XEmacs 21.5 (beta1) "anise" [Lucid] (i686-pc-cygwin) of Thu May 31 2001 on MILHOUSE milhouse$ uname -a CYGWIN_NT-5.0 MILHOUSE 1.3.2(0.39/3/2) 2001-05-20 23:28 i686 unknown milhouse$ Since Ben's change to set BROKEN_SIGIO and then the changes that he checked in yesterday to fix C-g under Windows, I have been seeing random crashes and lock ups. The crashes do not produce backtraces. Below is the console output from two crashes. There is no useful output from the lockups. What more can I do to gather information about this? I updated my sources from the CVS server yesterday, if that matters. =========================================================================== milhouse$ xemacs-21.5 & [1] 1464 milhouse$ Window procedure called during GC??????? Window procedure called during GC??????? Window procedure called during GC??????? Window procedure called during GC??????? Window procedure called during GC??????? Window procedure called during GC??????? Window procedure called during GC??????? Fatal error: assertion failed, file events.h, line 496, RECORD_TYPEP (obj, lreco rd_type_event) =========================================================================== milhouse$ xemacs-21.5 & [1] 300 milhouse$ milhouse$ 0 [win] xemacs-21.5 300 sig_send: wait for sig_complete event fa iled, signal 14, rc 258, Win32 error 0 ===========================================================================

1 participants
0 comments

[comp.emacs.xemacs] setting toolbar-visible-p makes xemacs windows jump around 24 years, 1 month

Simon Josefsson

Bug reports are still sent to comp.emacs.xemacs, this one is probably more appropriate here though.

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 June 2001