July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Core dump in Benadir 25 years, 9 months

SL Baur

Marcus Thiessel <thiessel(a)hpbbse.bbn.hp.com> writes in xemacs-beta(a)xemacs.org: > As reported I have a have Mule/minimal tagsbits config that didn't > crash. I built the last few betas with --gung-ho. Marcus, I see your build report. Ignoring Xpm which I seriously doubt is the cause, the differences between your build and mine is that I have XIM/Xlib and you have XIM/Motif, and I have Canna and Wnn(6). Can you try building with one of Canna or Wnn and see if that provokes a crash?

2 participants
1 comments

Re: Core dump in Benadir 25 years, 9 months

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > Hmm. Maybe I should try a Mule build without minimal tagbits. That did it. A Mule build with minimal tagbits crashes, a Mule build without minimal tagbits does not. Does this narrow it down enough Kyle?

2 participants
1 comments

Re: Core dump in Benadir 25 years, 9 months

SL Baur

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in xemacs-beta(a)xemacs.org: > Carsten Leonhardt <leo(a)arioch.oche.de> writes: >> By doing a >> >> M-x apropos-value RET latin-iso RET >> >> from a vanilla XEmacs I get a core dump. > I can't reproduce that on linux or solaris. Are you using MULE? It's Mule related. I've tried four configurations. XEmacs/No-Mule and XEmacs/Mule-20.4 don't crash. XEmacs/Mule-21 with distribution .elcs (the ones in the -elc tarball on the FTP site bytecompiled with a tty-only XEmacs/No-Mule), and XEmacs/Mule with core .elcs bytecompiled with XEmacs/Mule. Both of the Mule builds crash in the same place. Hmm. Maybe I should try a Mule build without minimal tagbits. #0 0x817ac57 in print_internal (obj={gu = {type = Lisp_Type_Record, val = 0}, s = {bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0, i = 0, v = 0x0, cv = 0x0}, printcharfun={gu = {type = Lisp_Type_Record, val = 34583268}, s = {bits = 0, val = 69166536}, u = {bits = 0, val = 69166536}, ui = 138333072, i = 138333072, v = 0x83ecb90, cv = 0x83ecb90}, escapeflag=1) at /home/xemacs/xemacs-20.0/src/print.c:1061 #1 0x8179942 in Fprin1_to_string (object={gu = {type = Lisp_Type_Record, val = 0}, s = {bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0, i = 0, v = 0x0, cv = 0x0}, noescape={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/print.c:531 #2 0x80c1fbf in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34541822}, s = {bits = 0, val = 69083644}, u = {bits = 0, val = 69083644}, ui = 138167288, i = 138167288, v = 0x83c43f8, cv = 0x83c43f8}, nargs=1, args=0xbfffd5a0) at /home/xemacs/xemacs-20.0/src/eval.c:3193 #3 0x80c2488 in Ffuncall (nargs=2, args=0xbfffd5a0) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #4 0x8091626 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 34671263}, s = {bits = 0, val = 69342526}, u = {bits = 0, val = 69342526}, ui = 138685052, i = 138685052, v = 0x8442a7c, cv = 0x8442a7c}, vector={gu = {type = Lisp_Type_Record, val = 35125832}, s = {bits = 0, val = 70251664}, u = {bits = 0, val = 70251664}, ui = 140503328, i = 140503328, v = 0x85fe920, cv = 0x85fe920}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 3}, s = {bits = 1, val = 6}, u = { bits = 1, val = 6}, ui = 13, i = 13, v = 0xd, cv = 0xd}) at /home/xemacs/xemacs-20.0/src/bytecode.c:416 #5 0x80c339e in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 34978999}, s = {bits = 0, val = 69957998}, u = {bits = 0, val = 69957998}, ui = 139915996, i = 139915996, v = 0x856f2dc, cv = 0x856f2dc}, nargs=3, arg_vector=0xbfffdaec) at /home/xemacs/xemacs-20.0/src/eval.c:3597 #6 0x80c2358 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 35125026}, s = {bits = 0, val = 70250052}, u = {bits = 0, val = 70250052}, ui = 140500104, i = 140500104, v = 0x85fdc88, cv = 0x85fdc88}, nargs=3, args=0xbfffdae8) at /home/xemacs/xemacs-20.0/src/eval.c:3200 #7 0x80c2488 in Ffuncall (nargs=4, args=0xbfffdae8) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #8 0x8091626 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 34689877}, s = {bits = 0, val = 69379754}, u = {bits = 0, val = 69379754}, ui = 138759508, i = 138759508, v = 0x8454d54, cv = 0x8454d54}, vector={gu = {type = Lisp_Type_Record, val = 35125758}, s = {bits = 0, val = 70251516}, u = {bits = 0, val = 70251516}, ui = 140503032, i = 140503032, v = 0x85fe7f8, cv = 0x85fe7f8}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 2}, s = {bits = 1, val = 4}, u = { bits = 1, val = 4}, ui = 9, i = 9, v = 0x9, cv = 0x9}) at /home/xemacs/xemacs-20.0/src/bytecode.c:416 #9 0x80c339e in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 34978971}, s = {bits = 0, val = 69957942}, u = {bits = 0, val = 69957942}, ui = 139915884, i = 139915884, v = 0x856f26c, cv = 0x856f26c}, nargs=1, arg_vector=0xbfffdf58) at /home/xemacs/xemacs-20.0/src/eval.c:3597 #10 0x80c2358 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34978971}, s = {bits = 0, val = 69957942}, u = {bits = 0, val = 69957942}, ui = 139915884, i = 139915884, v = 0x856f26c, cv = 0x856f26c}, nargs=1, args=0xbfffdf54) at /home/xemacs/xemacs-20.0/src/eval.c:3200 #11 0x80c2488 in Ffuncall (nargs=2, args=0xbfffdf54) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #12 0x80c3acc in call1 (fn={gu = {type = Lisp_Type_Record, val = 34978971}, s = {bits = 0, val = 69957942}, u = {bits = 0, val = 69957942}, ui = 139915884, i = 139915884, v = 0x856f26c, cv = 0x856f26c}, arg0={ gu = {type = Lisp_Type_Record, val = 34555571}, s = {bits = 0, val = 69111142}, u = {bits = 0, val = 69111142}, ui = 138222284, i = 138222284, v = 0x83d1acc, cv = 0x83d1acc}) at /home/xemacs/xemacs-20.0/src/eval.c:3921 #13 0x81be92b in mapatoms_1 (sym={gu = {type = Lisp_Type_Record, val = 34555571}, s = {bits = 0, val = 69111142}, u = {bits = 0, val = 69111142}, ui = 138222284, i = 138222284, v = 0x83d1acc, cv = 0x83d1acc}, arg=0xbfffdfdc) at /home/xemacs/xemacs-20.0/src/symbols.c:408 #14 0x81be872 in map_obarray (obarray={gu = {type = Lisp_Type_Record, val = 34515182}, s = {bits = 0, val = 69030364}, u = {bits = 0, val = 69030364}, ui = 138060728, i = 138060728, v = 0x83aa3b8, cv = 0x83aa3b8}, fn=0x81be90f <mapatoms_1>, arg=0xbfffdfdc) at /home/xemacs/xemacs-20.0/src/symbols.c:395 #15 0x81be975 in Fmapatoms (function={gu = {type = Lisp_Type_Record, val = 34978971}, s = {bits = 0, val = 69957942}, u = {bits = 0, val = 69957942}, ui = 139915884, i = 139915884, v = 0x856f26c, cv = 0x856f26c}, obarray={gu = {type = Lisp_Type_Record, val = 34515182}, s = {bits = 0, val = 69030364}, u = {bits = 0, val = 69030364}, ui = 138060728, i = 138060728, v = 0x83aa3b8, cv = 0x83aa3b8}) at /home/xemacs/xemacs-20.0/src/symbols.c:422 #16 0x80c1fbf in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34543764}, s = {bits = 0, val = 69087528}, u = {bits = 0, val = 69087528}, ui = 138175056, i = 138175056, v = 0x83c6250, cv = 0x83c6250}, nargs=1, args=0xbfffe0f8) at /home/xemacs/xemacs-20.0/src/eval.c:3193 #17 0x80c2488 in Ffuncall (nargs=2, args=0xbfffe0f8) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #18 0x8091626 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 34689749}, s = {bits = 0, val = 69379498}, u = {bits = 0, val = 69379498}, ui = 138758996, i = 138758996, v = 0x8454b54, cv = 0x8454b54}, vector={gu = {type = Lisp_Type_Record, val = 35125780}, s = {bits = 0, val = 70251560}, u = {bits = 0, val = 70251560}, ui = 140503120, i = 140503120, v = 0x85fe850, cv = 0x85fe850}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 2}, s = {bits = 1, val = 4}, u = { bits = 1, val = 4}, ui = 9, i = 9, v = 0x9, cv = 0x9}) at /home/xemacs/xemacs-20.0/src/bytecode.c:416 #19 0x80c339e in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 34978978}, s = {bits = 0, val = 69957956}, u = {bits = 0, val = 69957956}, ui = 139915912, i = 139915912, v = 0x856f288, cv = 0x856f288}, nargs=2, arg_vector=0xbfffe55c) at /home/xemacs/xemacs-20.0/src/eval.c:3597 #20 0x80c2358 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34830517}, s = {bits = 0, val = 69661034}, u = {bits = 0, val = 69661034}, ui = 139322068, i = 139322068, v = 0x84de2d4, cv = 0x84de2d4}, nargs=2, args=0xbfffe558) at /home/xemacs/xemacs-20.0/src/eval.c:3200 #21 0x80c2488 in Ffuncall (nargs=3, args=0xbfffe558) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #22 0x8096eae in Fcall_interactively (function={gu = {type = Lisp_Type_Record, val = 34830517}, s = {bits = 0, val = 69661034}, u = {bits = 0, val = 69661034}, ui = 139322068, i = 139322068, v = 0x84de2d4, cv = 0x84de2d4}, record_flag={gu = {type = Lisp_Type_Record, val = 34514676}, s = {bits = 0, val = 69029352}, u = {bits = 0, val = 69029352}, ui = 138058704, i = 138058704, v = 0x83a9bd0, cv = 0x83a9bd0}, keys={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/callint.c:935 #23 0x80c071c in Fcommand_execute (cmd={gu = {type = Lisp_Type_Record, val = 34830517}, s = {bits = 0, val = 69661034}, u = {bits = 0, val = 69661034}, ui = 139322068, i = 139322068, v = 0x84de2d4, cv = 0x84de2d4}, record={gu = {type = Lisp_Type_Record, val = 34514676}, s = {bits = 0, val = 69029352}, u = {bits = 0, val = 69029352}, ui = 138058704, i = 138058704, v = 0x83a9bd0, cv = 0x83a9bd0}, keys={ gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/eval.c:2584 #24 0x80c1fdc in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34535797}, s = {bits = 0, val = 69071594}, u = {bits = 0, val = 69071594}, ui = 138143188, i = 138143188, v = 0x83be5d4, cv = 0x83be5d4}, nargs=2, args=0xbfffe980) at /home/xemacs/xemacs-20.0/src/eval.c:3193 #25 0x80c2488 in Ffuncall (nargs=3, args=0xbfffe980) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #26 0x8091626 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 34279785}, s = {bits = 0, val = 68559570}, u = {bits = 0, val = 68559570}, ui = 137119140, i = 137119140, v = 0x82c45a4, cv = 0x82c45a4}, vector={gu = {type = Lisp_Type_Record, val = 34279841}, s = {bits = 0, val = 68559682}, u = {bits = 0, val = 68559682}, ui = 137119364, i = 137119364, v = 0x82c4684, cv = 0x82c4684}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 4}, s = {bits = 1, val = 8}, u = { bits = 1, val = 8}, ui = 17, i = 17, v = 0x11, cv = 0x11}) at /home/xemacs/xemacs-20.0/src/bytecode.c:416 #27 0x80c339e in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 34279922}, s = {bits = 0, val = 68559844}, u = {bits = 0, val = 68559844}, ui = 137119688, i = 137119688, v = 0x82c47c8, cv = 0x82c47c8}, nargs=1, arg_vector=0xbfffedf4) at /home/xemacs/xemacs-20.0/src/eval.c:3597 #28 0x80c2358 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34647860}, s = {bits = 0, val = 69295720}, u = {bits = 0, val = 69295720}, ui = 138591440, i = 138591440, v = 0x842bcd0, cv = 0x842bcd0}, nargs=1, args=0xbfffedf0) at /home/xemacs/xemacs-20.0/src/eval.c:3200 #29 0x80c2488 in Ffuncall (nargs=2, args=0xbfffedf0) at /home/xemacs/xemacs-20.0/src/eval.c:3238 #30 0x8096eae in Fcall_interactively (function={gu = {type = Lisp_Type_Record, val = 34647860}, s = {bits = 0, val = 69295720}, u = {bits = 0, val = 69295720}, ui = 138591440, i = 138591440, v = 0x842bcd0, cv = 0x842bcd0}, record_flag={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}, keys={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/callint.c:935 #31 0x80c071c in Fcommand_execute (cmd={gu = {type = Lisp_Type_Record, val = 34647860}, s = {bits = 0, val = 69295720}, u = {bits = 0, val = 69295720}, ui = 138591440, i = 138591440, v = 0x842bcd0, cv = 0x842bcd0}, record={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}, keys={ gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/eval.c:2584 #32 0x8116ef2 in execute_command_event (command_builder=0x84e4c20, event={ gu = {type = Lisp_Type_Record, val = 35062042}, s = {bits = 0, val = 70124084}, u = {bits = 0, val = 70124084}, ui = 140248168, i = 140248168, v = 0x85c0468, cv = 0x85c0468}) at /home/xemacs/xemacs-20.0/src/event-stream.c:4346 #33 0x81175d3 in Fdispatch_event (event={gu = {type = Lisp_Type_Record, val = 35062042}, s = {bits = 0, val = 70124084}, u = {bits = 0, val = 70124084}, ui = 140248168, i = 140248168, v = 0x85c0468, cv = 0x85c0468}) at /home/xemacs/xemacs-20.0/src/event-stream.c:4637 #34 0x809e8e8 in Fcommand_loop_1 () at /home/xemacs/xemacs-20.0/src/cmdloop.c:579 #35 0x809e66c in command_loop_1 (dummy={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/cmdloop.c:494 #36 0x80bedaf in condition_case_1 (handlers={gu = {type = Lisp_Type_Record, val = 34514697}, s = {bits = 0, val = 69029394}, u = {bits = 0, val = 69029394}, ui = 138058788, i = 138058788, v = 0x83a9c24, cv = 0x83a9c24}, bfun=0x809e640 <command_loop_1>, barg={gu = { type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}, hfun=0x809de47 <cmd_error>, harg={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/eval.c:1653 #37 0x809df8f in command_loop_3 () at /home/xemacs/xemacs-20.0/src/cmdloop.c:256 #38 0x809dfb4 in command_loop_2 (dummy={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/cmdloop.c:267 #39 0x80be901 in internal_catch (tag={gu = {type = Lisp_Type_Record, val = 34533346}, s = {bits = 0, val = 69066692}, u = {bits = 0, val = 69066692}, ui = 138133384, i = 138133384, v = 0x83bbf88, cv = 0x83bbf88}, func=0x809dfa8 <command_loop_2>, arg={gu = { type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}, threw=0x0) at /home/xemacs/xemacs-20.0/src/eval.c:1328 #40 0x809e20a in initial_command_loop (load_me={gu = {type = Lisp_Type_Record, val = 34514669}, s = {bits = 0, val = 69029338}, u = {bits = 0, val = 69029338}, ui = 138058676, i = 138058676, v = 0x83a9bb4, cv = 0x83a9bb4}) at /home/xemacs/xemacs-20.0/src/cmdloop.c:305 #41 0x80ba4e7 in xemacs_21_0_i586_pc_linux (argc=2, argv=0xbffff398, envp=0xbffff3a4, restart=0) at /home/xemacs/xemacs-20.0/src/emacs.c:1702 #42 0x80bb008 in main (argc=2, argv=0xbffff398, envp=0xbffff3a4) at /home/xemacs/xemacs-20.0/src/emacs.c:2119

1 participants
0 comments

Re: Core dump in Benadir 25 years, 9 months

SL Baur

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in xemacs-beta(a)xemacs.org: > Carsten Leonhardt <leo(a)arioch.oche.de> writes: >> By doing a >> >> M-x apropos-value RET latin-iso RET >> >> from a vanilla XEmacs I get a core dump. > I can't reproduce that on linux or solaris. Are you using MULE? I can reproduce it with XEmacs/Mule. I'm going to cons up a no-Mule build to see how that works. > Please post your Installation file. uname -a: Linux altair.xemacs.org 2.0.34 #1 Wed Jun 3 23:15:41 PDT 1998 i586 ./configure '--cflags=-mpentium -march=pentium -fno-peep-spills -O6 -fno-risc -fno-exceptions' '--error-checking=none' '--debug=no' '--with-mule=yes' '--with-dialogs=athena3d' '--with-scrollbars=athena3d' '--use-union-type=no' '--with-xim=xlib' '--with-xfs' '--mail-locking=file' '--extra-verbose=no' XEmacs 21.0 "Corsican" configured for `i586-pc-linux'. Where should the build process find the source code? /home/xemacs/xemacs-20.0 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -mpentium -march=pentium -fno-peep-spills -O6 -fno-risc -fno-exceptions Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) 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/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for GIF image conversion. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for proper session-management. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits.

1 participants
0 comments

Re: How to control autogenerated custom dependencies ? 25 years, 9 months

Colin Rafferty

Sorry to quote the entire article, but I couldn't think of a good way to trim it. Anyway, what I would do is create a variable file for each of the front-ends, so that only those will be loaded by custom (and will be much cheaper). The custom-load should then look like this: (custom-add-loads 'eudc '("eudc-bbdb-vars" "eudc-ldap-vars" "eudc-ph-vars" "eudc")) Of course, don't forget to require the "var" files in their respective "real" files. -- Colin Oscar Figueiredo writes: > EUDC consists of eudc.el for the front-end and eudc-ph, eudc-ldap and eudc-bbdb > for the three supported backends. I would like the system to load only the > front-end and the necessary backend files according to the protocols the user > actually wants to use. The problem is I use custom and made eudc-ph, eudc-ldap > and eudc-bbdb be subgroups of the larger custom group eudc. Therefore > the generated custom-load file includes: > (custom-add-loads 'eudc '("eudc-bbdb" "eudc-ldap" "eudc-ph" "eudc")) > which means that whenever I load eudc all the backends are loaded. I really > need to avoid this. > What should I do ? > Oscar

1 participants
0 comments

Re: [PATCH] XEmacs obsolete function 25 years, 9 months

Colin Rafferty

SL Baur writes: > Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: >> Didier Verna writes: >>> This patch avoids using extent-data, a function that is obsolete at >>> least from XEmacs 20.3 and will completely disapear in XEmacs 21.2 >>> and later. >>> [... s/extent-data/extent-property/g ...] >> In which version of XEmacs did `extent-property' get created? > It has always been in XEmacs and `extent-data' has always been obsolete > in XEmacs (ie. since at least XEmacs 19.11). I don't have Lucid Emacs > sources untarred, so I don't know how much earlier it was present. Well, I just discovered the same thing myself. I guess the original author didn't believe in compiler warnings. > Basically, any version of XEmacs is O.K. Any version of Lucid Emacs > might not be. I think that we can safely dump 19.10 support, even though it's mentioned in the source. In fact, I think that BBDB 2 already fails under 19.10. I wish I had an executable to test. >> We're trying to be backwards-compatible, so I need to know whether to >> apply the patch as-is, or do a song-and-dance function. > O.K. But look at the more complete patch I sent in which changes all > the obsolete symbols not just the one Didier changed. I didn't notice that this was a subset of your original patch. I'll see about incorporating your patch. > Speaking of backwards compatibility, I don't like the way the XEmacs > M-TAB binding for `ispell-complete-word' gets overwritten by BBDB 2. Neither do I, but I didn't notice it until just now. I think the concept is fine, but I would rather have a pointer to message-x (or better, a (condition-case nil (require 'message-x) ...)), and do away with the `define-key' altogether). -- Colin

1 participants
0 comments

Re: [PATCH] XEmacs obsolete function 25 years, 9 months

SL Baur

Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: > Didier Verna writes: >> This patch avoids using extent-data, a function that is obsolete at >> least from XEmacs 20.3 and will completely disapear in XEmacs 21.2 >> and later. >> [... s/extent-data/extent-property/g ...] > In which version of XEmacs did `extent-property' get created? It has always been in XEmacs and `extent-data' has always been obsolete in XEmacs (ie. since at least XEmacs 19.11). I don't have Lucid Emacs sources untarred, so I don't know how much earlier it was present. Basically, any version of XEmacs is O.K. Any version of Lucid Emacs might not be. > We're trying to be backwards-compatible, so I need to know whether to > apply the patch as-is, or do a song-and-dance function. O.K. But look at the more complete patch I sent in which changes all the obsolete symbols not just the one Didier changed. P.S. Speaking of backwards compatibility, I don't like the way the XEmacs M-TAB binding for `ispell-complete-word' gets overwritten by BBDB 2.

1 participants
0 comments

Re: [PATCH] XEmacs obsolete function 25 years, 9 months

Colin Rafferty

Didier Verna writes: > Colin Rafferty <craffert(a)ms.com> writes: >> In which version of XEmacs did `extent-property' get created? > AFAICS, extent-property is here since at least 19.14 I'm sorry I asked. I keep forgetting that we have XEmacs 19.11 (and most intermediates) at work. It was in 19.11, and while the bbdb-xemacs file mentions 19.10, I think that we can safely say that it's no longer supported. -- Colin

1 participants
0 comments

How to control autogenerated custom dependencies ? 25 years, 9 months

Oscar Figueiredo

EUDC consists of eudc.el for the front-end and eudc-ph, eudc-ldap and eudc-bbdb for the three supported backends. I would like the system to load only the front-end and the necessary backend files according to the protocols the user actually wants to use. The problem is I use custom and made eudc-ph, eudc-ldap and eudc-bbdb be subgroups of the larger custom group eudc. Therefore the generated custom-load file includes: (custom-add-loads 'eudc '("eudc-bbdb" "eudc-ldap" "eudc-ph" "eudc")) which means that whenever I load eudc all the backends are loaded. I really need to avoid this. What should I do ? Oscar

1 participants
0 comments

Re: no inline mime images :-( 25 years, 9 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > Ah, yes: my XEmacs is very selective about the images he's willing to > display inline. I mean not by extension, by contents :-) :-) O.K. So we're playing 20 questions. Which (if any) of the following fail? Note that failure on GIF will be standard come the next release.

5 participants
4 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 July 1998