November 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Emacs and the elusive 21.0 23 years, 5 months

Dhruva_KRISHNAMURTHY＠delmia.com

Hi, Sorry, this may be irrelavent, but I just thought of passing this information. For offering to be a Pre-Tester for GNU Emacs - The response I got!! The Open Software development is NOT SO OPEN AS IT SHOULD BE!! I now know how open and accessable XEmacs. I admire the openess of XEmacs development community. with regards, dhruva RESPONSE: >> As far as I know, Emacs 21 isn't in pretest yet (but might be any >> day). Also, there is a closed list of pretesters. Not sure whom to >> ask if you want to become a member. > <gerd(a)gnu.org> - However he's not keen on "accepting" new > contributors untill the next release is out.

2 participants
1 comments

Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7) 23 years, 5 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > I can't try to reproduce your crash directly since I don't have > clearcase, but...your backtrace looks very suggestive, so... > GCPROs are very tricky. yes, indeed. Maybe Ray could build with DEBUG_GCPRO and then call show_gcprohist(). It seemed that one gcpro struct in the gcprolist was pointing to NULL, which shouldn't happen. > - Lisp_Object handler; > + Lisp_Object handler = Qnil; out of interest, is this always neccessary? Hm, I guess it is. Maybe the actual bug is of this kind -- GCPROing an unintialised variable. > /* both of these get set below */ > - GCPRO2 (name, default_directory); > + GCPRO3 (name, default_directory, handler); > > CHECK_STRING (name); > > ＠＠ -777,9 +777,8 ＠＠ > handler = Ffind_file_name_handler (name, Qexpand_file_name); > if (!NILP (handler)) > { > - UNGCPRO; > - return call3_check_string (handler, Qexpand_file_name, name, > - default_directory); > + RETURN_UNGCPRO (call3_check_string (handler, Qexpand_file_name, > + name, default_directory)); I agree with the RETURN_UNGCPRO but don't think any of this is going to make a difference. handler should be GCPRO'd by call3(). Gunnar

2 participants
1 comments

func-menu compile error under XEmacs 21.2 23 years, 5 months

Charles G Waldman

Martin Buchholz writes: > Although this is a bug in XEmacs, I suggest that this case is > sufficiently rare and difficult to fix that we not try to fix it. Wait a moment, was this message posted by an impostor? I have a hard time believing that the words above were written by the same Martin who spends countless hours making numerous tiny changes so that he can compile XEmacs with a C++ compiler, or to gain nanosecond speedups, or pedantic spelling fixes [1] - then when there's an actual, real-live bug he suggests not fixing it? [1] Don't get me wrong, proper spelling is important. But proper code is even more important.

1 participants
0 comments

Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7) 23 years, 5 months

Hrvoje Niksic

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > - Lisp_Object handler; > > + Lisp_Object handler = Qnil; > > out of interest, is this always neccessary? The initialization necessary only because of the newly introduced GCPRO on that variable. GCPRO (foo) declares that the Lisp object pointed to by &foo is a "root of accessibility", which means that it will be marked in the mark phase of GC. If you don't initialize it, the GC code will try to dereference random garbage and set the mark bit there, leading to a crash.

1 participants
0 comments

`looking-at' does not work for Japanese chars 23 years, 5 months

Katsumi Yamaoka

Hi, I'm using latest 21.2 CVS. I found a problem that the function `looking-at' does not work for Japanese characters as follows. (let ((oops (decode-coding-string "\e$B$&$C$W$9\e(B" 'iso-2022-jp))) (with-temp-buffer (insert oops) (goto-char (point-min)) (looking-at (regexp-quote oops)))) => nil What's happened? I can't write Japanese kanji text using egg-sj3 because of this. -- Katsumi Yamaoka <yamaoka(a)jpl.org>

3 participants
3 comments

CORE, newest CVS 23 years, 5 months

Norbert Koch

Hi! After an update I encounter the following dump when trying to open certain mails in gnus (it doesn't happen in .36): ------------------------------------------------ re-search-forward("\$\\s-\\|^\\|[-\"]\\|\\s(\$\$/\\(\\w+\\(\\s-+\\w+\$*[.,]?\\)/\\)\$\\s-\\|[-,;:\"]\\s-\\|[?!.]+\\s-\\|\\s)\$" nil t) # bind (alist buffer-read-only props regexp elem beg invisible # visible face) # (unwind-protect ...) # bind (arg) article-emphasize() apply(article-emphasize nil) (if interactive (call-interactively (quote article-emphasize)) (apply (quote article-emphasize) args)) # (unwind-protect ...) (save-excursion (set-buffer gnus-article-buffer) (if interactive (call-interactively ...) (apply ... args))) # bind (args interactive) gnus-article-emphasize() # (unwind-protect ...) # bind (length alist article-goto-body-goes-to-point-min-p # treated-type highlightp val elem type total-parts part-number # condition) gnus-treat-article(nil 1 1) # (unwind-protect ...) # bind (display e b type name handle buffer-read-only handles) # (unwind-protect ...) # bind (save-selected-window-window) # (unwind-protect ...) # bind (ihandles) gnus-display-mime() # bind (gnus-article-buffer buffer-read-only) gnus-article-prepare-display() # (unwind-protect ...) # bind (result group gnus-tmp-internal-hook summary-buffer # gnus-article) # (unwind-protect ...) # bind (header all-headers article) gnus-article-prepare(11016 nil) # bind (all-header article) gnus-summary-display-article(11016 nil) # (unwind-protect ...) # bind (article all-headers gnus-summary-display-article-function # article pseudo force all-headers) gnus-summary-select-article(nil nil pseudo) # bind (lines) gnus-summary-scroll-up(1) # bind (command-debug-status) call-interactively(gnus-summary-scroll-up) # (condition-case ... . error) # (catch top-level ...) Abort trap (core dumped) ------------------------------------------------- #0 0x185063d0 in kill () from /usr/lib/libc.so.3 #1 0x80bb853 in fatal_error_signal (sig=6) at emacs.c:531 #2 0xbfbfdfdc in ?? () #3 0x80be7fa in assert_failed (file=0x82ad0e8 "buffer.h", line=1712, expr=0x82ad18f "IN_TRT_TABLE_DOMAIN (c)") at emacs.c:3192 #4 0x81abc13 in re_match_2_internal (bufp=0x82e3174, string1=0x1857230d "Hallo,\n\nich habe mir vmware eingerichtet aber das host-only networking\nfunktioniert nicht.\n\nBeim \"make\" habe ich die defaultwerte für die host-ip angenommen und\ndann einfach mit make install installie"..., size1=2824, string2=0x18573607 "\neMail: jan.carmen(a)gmx.net\n", size2=27, pos=814, regs=0x82e47b4, stop=2851) at buffer.h:1712 #5 0x81aae2f in re_search_2 (bufp=0x82e3174, string1=0x1857230d "Hallo,\n\nich habe mir vmware eingerichtet aber das host-only networking\nfunktioniert nicht.\n\nBeim \"make\" habe ich die defaultwerte für die host-ip angenommen und\ndann einfach mit make install installie"..., size1=2824, string2=0x18573607 "\neMail: jan.carmen(a)gmx.net\n", size2=27, startpos=814, range=2851, regs=0x82e47b4, stop=2851) at regex.c:4081 #6 0x81b0d41 in search_buffer (buf=0x8b78e00, string=144292740, bufpos=782, buflim=3633, n=1, RE=1, trt=139274240, inverse_trt=139276288, posix=0) at search.c:1218 #7 0x81b0811 in search_command (string=144292740, limit=137467908, noerror=137467932, count=137467908, buffer=137467908, direction=1, RE=1, posix=0) at search.c:1039 #8 0x81b3ffc in Fre_search_forward (regexp=144292740, limit=137467908, noerror=137467932, count=137467908, buffer=137467908) at search.c:1817 #9 0x80c4c59 in Ffuncall (nargs=4, args=0xbfbfc1e8) at eval.c:3528 #10 0x80990be in execute_optimized_program ( program=0x88d6210 "ÆÇ\016#\"?\205Ï", stack_depth=9, constants_data=0x8985410) at bytecode.c:746 #11 0x8098cd3 in funcall_compiled_function (fun=144465360, nargs=0, args=0xbfbfc398) at bytecode.c:518 #12 0x80c4d97 in Ffuncall (nargs=1, args=0xbfbfc394) at eval.c:3563 #13 0x80c56be in Fapply (nargs=2, args=0xbfbfc394) at eval.c:3742 #14 0x80c42ca in Feval (form=144532276) at eval.c:3356 #15 0x80caeaa in Fprogn (args=144532288) at eval.c:775 #16 0x80bf3f9 in Fif (args=144532312) at eval.c:693 #17 0x80c4043 in Feval (form=144532324) at eval.c:3304 #18 0x80caeaa in Fprogn (args=144532348) at eval.c:775 #19 0x80b86ac in Fsave_excursion (args=144532348) at editfns.c:400 #20 0x80c4043 in Feval (form=144532360) at eval.c:3304 #21 0x80c5bbd in funcall_lambda (fun=144532420, nargs=0, args=0xbfbfc91c) at eval.c:775 #22 0x80c4dba in Ffuncall (nargs=1, args=0xbfbfc918) at eval.c:3571 #23 0x80990be in execute_optimized_program ( program=0x834a490 "deZ\016\023Æ\016\024?®\004ÇÈ\215ÉÊË\"Ì\211\035\034\031\030\036\025\e\036\026ÍÎ!\210\013\211A\023＠\211\025<\212\016\022\211\032\013Ï\n!\006ÐÏ\n!!)«\005\016\022q\210\r＠J)\211\024:¬\004\b«ÔÑ\f!«Ï\r＠ËN«\004\t«Æ\214\rA＠ \210)ª½.\a\207", stack_depth=8, constants_data=0x89d0110) at bytecode.c:746 #24 0x8098cd3 in funcall_compiled_function (fun=144603924, nargs=3, args=0xbfbfca7c) at bytecode.c:518 #25 0x80c4d97 in Ffuncall (nargs=4, args=0xbfbfca78) at eval.c:3563 #26 0x80990be in execute_optimized_program ( program=0x8901f10 "\212Æ \036\026Ç\216È\016\027!`\030\211\e«\nÉ\013!\210Ê\013\b\"\210*\f®\aË ®\003Ì \035Í\211\036\030\036\031Í\211\036\032\036\eÍ\211\036\034\036\035Í\036\036\f¬\030\n¬\025\t«\bÎ\t!\210Í\026\037\r\021\016 «\005Ï\r!\210\r« \r＠;«\005\rA«\027\f¬\013\n¬\bÐ \210`d|\210Ñ\032Ò\r!\210)ª\022\214Ð \210`d}\210ÓÍÔ\211#\210~\210)\f?\016\212\214Ð \210e`}\210ÓÕ!*.\013\207", stack_depth=5, constants_data=0x89d9410) at bytecode.c:746 #27 0x8098cd3 in funcall_compiled_function (fun=144565264, nargs=0, args=0xbfbfcbcc) at bytecode.c:518 #28 0x80c4d97 in Ffuncall (nargs=1, args=0xbfbfcbc8) at eval.c:3563 #29 0x80990be in execute_optimized_program ( program=0x8909e10 "pÅ\034\032\tÆa¬\004Æ \210Å\211\024\020ÇÈ!\210\013«\004\013 \210ÇÉ!*\207", stack_depth=3, constants_data=0x89c42d0) at bytecode.c:746 #30 0x8098cd3 in funcall_compiled_function (fun=144564340, nargs=0, args=0xbfbfcd0c) at bytecode.c:518 #31 0x80c4d97 in Ffuncall (nargs=1, args=0xbfbfcd08) at eval.c:3563 #32 0x80990be in execute_optimized_program ( program=0x8b78010 "\212\0164Æa¬\004\bq\210p\020\016-«\a\016-ÇHª\002\r\0365p\036*\0166\0367\016+\036.È\e\212É \210\0168q\210ÊË!«\b\016\013«\004È\0269È\036:Ì\r\016.\")\211\023\204\214", stack_depth=4, constants_data=0x89d3e10) at bytecode.c:746 #33 0x8098cd3 in funcall_compiled_function (fun=144564312, nargs=2, args=0xbfbfce5c) at bytecode.c:518 #34 0x80c4d97 in Ffuncall (nargs=3, args=0xbfbfce58) at eval.c:3563 #35 0x80990be in execute_optimized_program ( program=0x8901310 "Æ \210\n\211\034\013Ç\f!\006ÈÇ\f!!)«&r\nq\210\016\032\026\e\016\034\026\035ÉÊ!«\024ËÌ!«\017ÍÌ!«\nÎÏ!¬\005ÊÐ!\210)\r9\t«\a\t\r\b\"ª\005Ñ\r\b\"ÒÓ!\210\013«\n\013ÔU¬\005Õ\013!\210Ö \210\016\036«\r\016\037«\t×\r!\210Ø\r!\210Ù\r\016 ·A!\210\207", stack_depth=5, constants_data=0x8963310) at bytecode.c:746 #36 0x8098cd3 in funcall_compiled_function (fun=144196820, nargs=2, args=0xbfbfcfac) at bytecode.c:518 #37 0x80c4d97 in Ffuncall (nargs=3, args=0xbfbfcfa8) at eval.c:3563 #38 0x80990be in execute_optimized_program ( program=0x8901010 "\016\036Æa¬\005\016\032q\210\r®\030Ç`È\"\211\036\e«\006É\016\e!\210)Ç`Ê\"®\003Ë \f??Ì\036\037\034\035\016 ¬\nÍ\r!«\005ÎÏ!\210\212\016\032q\210\016\034«\031\013«&\n«#Ð\t!«\036\r\nAa«\030\n＠\016!k«\021\016\034¬\t\013«\n\013\ra«\005\016\"«DÑ\r\f\"\210\t\211\030\013Ð\b!\006ÒÐ\b!!)«\030r\tq\210\016#¬\017ÓÔ!«\nÕÖ!¬\005ÔÌ!\210)\f¬\005\016\035«\004× \210Ø\r\016$·A!\210\rª\f\f¬\005\016\035«\004× \210Ù,\207", stack_depth=4, constants_data=0x8963210) at bytecode.c:746 #39 0x8098cd3 in funcall_compiled_function (fun=144196848, nargs=3, args=0xbfbfd0fc) at bytecode.c:518 #40 0x80c4d97 in Ffuncall (nargs=4, args=0xbfbfd0f8) at eval.c:3563 #41 0x80990be in execute_optimized_program ( program=0x8bb7690 "ÅÆ!\210Ç \210ÈÉ\211Ê#Ëa«;Ì \031\b\032Í\nÎ\"\034Ï\216\f«\fÐ\f!\210Ñ\f!q\210ª\005Ò\n!\210\013ÓV«\rÔ\013!«\022ÕÖ×\"\210ª\013\013ÓW«\006Ø\013[!\210,Ù \210Ú \207", stack_depth=4, constants_data=0x8983690) at bytecode.c:746 #42 0x8098cd3 in funcall_compiled_function (fun=144197156, nargs=1, args=0xbfbfd258) at bytecode.c:518 #43 0x80c4d97 in Ffuncall (nargs=2, args=0xbfbfd254) at eval.c:3563 #44 0x809e11f in Fcall_interactively (function=144101620, record_flag=137467908, keys=137467908) at callint.c:940 #45 0x80c33bd in Fcommand_execute (cmd=144101620, record_flag=137467908, keys=137467908) at eval.c:2970 #46 0x81046f5 in execute_command_event (command_builder=0x858aa00, event=139832112) at event-stream.c:3833 #47 0x810535c in Fdispatch_event (event=139832112) at event-stream.c:4164 #48 0x80a35e2 in Fcommand_loop_1 () at cmdloop.c:583 #49 0x80a3882 in command_loop_1 (dummy=137467908) at cmdloop.c:494 #50 0x80cabda in condition_case_1 (handlers=137468004, bfun=0x80a3844 <command_loop_1>, barg=137467908, hfun=0x80a38f4 <cmd_error>, harg=137467908) at eval.c:1651 #51 0x80a39e7 in command_loop_2 (dummy=137467908) at cmdloop.c:256 #52 0x80caadc in internal_catch (tag=137551972, func=0x80a39ac <command_loop_2>, arg=137467908, threw=0x0) at eval.c:1317 #53 0x80a2e56 in initial_command_loop (load_me=137467908) at cmdloop.c:305 #54 0x80bcb9d in xemacs_21_2_b37_i386_unknown_freebsd3_3 (argc=4, argv=0xbfbfd748, envp=0xbfbfd75c, restart=0) at emacs.c:2231 #55 0x80bea59 in main (argc=4, argv=0xbfbfd748, envp=0xbfbfd75c) at emacs.c:2660 #56 0x8086b8d in _start ()

3 participants
6 comments

Re: Issues outstanding, redux (summary) 23 years, 5 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> The one good consequence of the core/packages separation > Hrvoje> is that releasing XEmacs is not as hard as it used to > Hrvoje> be. > > Are the bad consequences relevant to the issues list, for either > fixing or improvement, or is there absolutely nothing that can be > done about them without remerging the packages into the core? It's not necessary to remerge the packages into the core, but it would be nice to have a more decent packaging system.

1 participants
0 comments

GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7) 23 years, 5 months

Raymond Toy

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> Yes, always_gc set to 1 slows down XEmacs enormously. But if you have Martin> a likely suspect, then that may be the best way to find a Martin> _reproducible_ crash, at which point it can be dissected, analysed and Martin> maybe even fixed. If you can't reproduce the crash, you never know Martin> whether you've fixed it. Success!!!! I've found a 100% reproducible case. This is with 21.2.37 on Solaris 2.7 compiled with gcc 2.95.2. This also includes some of the UNGCPRO patches from Yoshiki Hayashi, posted yesterday. I think it needs clearcase.el, but anyway, I load up a file in a clearcase view. Insert a space, and I hit my breakpoint in lock_file. Set always_gc = 1, and run finish, and I get the backtrace appended below. I need some guidance now. What should I be looking for now exactly? I don't understand the GCPRO stuff. Thanks for any help! Ray #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xfeab92a4 in abort () from /usr/lib/libc.so.1 #2 0xade50 in assert_failed (file=0x9ab <Address 0x9ab out of bounds>, line=2542280, expr=0x26cac8 "GCLI_lh != 0") at emacs.c:3192 #3 0x6bdd4 in mark_object (obj=0) at alloc.c:2475 #4 0x6da14 in garbage_collect_1 () at alloc.c:3444 #5 0xb63c0 in Ffuncall (nargs=3, args=0xffbed9f0) at eval.c:3477 #6 0xb78ac in call3 (fn=8533364, arg0=3440884, arg1=7969364, arg2=3323908) at eval.c:4216 #7 0x131e8c in Fexpand_file_name (name=7969364, default_directory=3323908) at fileio.c:395 #8 0xc5b78 in lock_file (fn=7969364) at filelock.c:325 #9 0x18be50 in prepare_to_modify_buffer (buf=0x915200, start=6712, end=6713, lockit=1) at insdel.c:2330 #10 0x18d0cc in buffer_delete_range (buf=0x915200, from=6712, to=6713, flags=0) at insdel.c:2675 #11 0x8e108 in Fdelete_char (count=3, killp=3323908) at cmds.c:258 #12 0xb65a0 in Ffuncall (nargs=2, args=0xffbede10) at eval.c:3528 #13 0x836e8 in Fcall_interactively (function=3408596, record_flag=3323908, keys=3323908) at callint.c:940 #14 0xb4ef4 in Fcommand_execute (cmd=3408596, record_flag=3323908, keys=3323908) at eval.c:2970 #15 0x115e44 in execute_command_event (command_builder=0x64e0c0, event=8534948) at event-stream.c:3833 #16 0x116900 in Fdispatch_event (event=8534948) at event-stream.c:4116 #17 0x8d52c in Fcommand_loop_1 () at cmdloop.c:583 #18 0x8d2c4 in command_loop_1 (dummy=6757760) at cmdloop.c:494 #19 0xb156c in condition_case_1 (handlers=3324004, bfun=0x8d278 <command_loop_1>, barg=3323908, hfun=0x8d70c <cmd_error>, harg=3323908) at eval.c:1651 #20 0x8d81c in command_loop_2 (dummy=3323908) at cmdloop.c:256 #21 0xb10dc in internal_catch (tag=3408236, func=0x8d7d0 <command_loop_2>, arg=3323908, threw=0x0) at eval.c:1317 #22 0x8cbc0 in initial_command_loop (load_me=579536) at cmdloop.c:305 #23 0xacaa8 in xemacs_21_2_b37_sparc_sun_solaris2_7 (argc=1, argv=0xffbee784, envp=0xffbee78c, restart=0) at emacs.c:2231 #24 0xad2cc in main (argc=1, argv=0xffbee784, envp=0xffbee78c) at emacs.c:2660

2 participants
1 comments

RE: Who is the portable dumper expert? 21.2.37 Portable dumper s till broken. 23 years, 5 months

Troy Noble

Olivier, thanks for being so gracious. So here's the situation. I've tried this on both NT with MSVC 5.0 and Linux with gcc/gdb using 21.2b36 and 21.2b37. In src/indent.c there is the following: void vars_of_indent (void) { DEFVAR_BOOL ("indent-tabs-mode", &indent_tabs_mode /* *Indentation can insert tabs if this is non-nil. Setting this variable automatically makes it local to the current buffer. */ ); indent_tabs_mode = 1; } When the portable dumper is enabled, setting or clearing this variable has no effect. It's almost like the portable dumper loads it into memory but never wires up the appropriate forwarding information so that the lisp code knows how to find the variable. I suspect this is true of other such opaque variables, but haven't proven that conclusively yet. I do know that if I set "watch indent_tabs_mode" the only time it ever gets set throughout the lifetime of my debug session is at startup time. Any subsequent calls to (setq-default indent-tabs-mode nil) or (setq indent-tabs-mode nil) have no effect. If I stop the debugger (CTRL-C) and do "p indent_tabs_mode" it's always 1. Here's where it gets set initially: Old value = 0 New value = 1 0x4034e4b3 in memcpy (dstpp=0x8331f7c, srcpp=0x40580f34, len=4) at ../sysdeps/generic/memcpy.c:61 61 ../sysdeps/generic/memcpy.c: No such file or directory. (gdb) bt #0 0x4034e4b3 in memcpy (dstpp=0x8331f7c, srcpp=0x40580f34, len=4) at ../sysdeps/generic/memcpy.c:61 #1 0x80c8407 in pdump_load_finish () at dumper.c:1041 #2 0x80c891d in pdump_load ( argv0=0xbfffe517 "/usr2/tnoble/build/xemacs-21.2.36/src/./xemacs") at dumper.c:1358 #3 0x80b15e2 in xemacs_21_2_b36_i686_pc_linux (argc=1, argv=0xbfffe284, envp=0xbfffe28c, restart=0) at emacs.c:1164 #4 0x80b3bd1 in main (argc=1, argv=0xbfffe284, envp=0xbfffe28c) at emacs.c:2595 So am wondering if there is an additional step that might need to be added after the opaques are loaded in pdump_load_finish to make them visible to lisp. The code in question is: dumper.c, Line 1041: /* Put back the opaques */ for (i=0; i<((dump_header *)pdump_start)->nb_opaquedmp; i++) { struct pdump_dumpopaqueinfo di = PDUMP_READ (p, struct pdump_dumpopaqueinfo); > memcpy (di.data, p, di.size); p += di.size; } Interestingly, when I turn off the portable dumper... I always get a watch breakpoint at the following location whenever I (setq-default indent-tabs-mode <whatever>): symbols.c, Line 1255: case SYMVAL_BOOLEAN_FORWARD: if (magicfun) magicfun (sym, &newval, Qnil, 0); *((int *) symbol_value_forward_forward (fwd)) = !NILP (newval); > return; So do these opaques need to be added to the pdump_reloc_table (presumably in pdump_dump_rtable and then again when the rtable gets read back in) so they get manipulated in pdump_reorganize_hash_table, or is there something else that needs to happen? dumper.c, line 1089 and following: /* Final cleanups */ /* reorganize hash tables */ p = pdump_rt_list; for (;;) { pdump_reloc_table rt = PDUMP_READ (p, pdump_reloc_table); if (!rt.desc) break; if (rt.desc == hash_table_description) { for (i=0; i < rt.count; i++) pdump_reorganize_hash_table (PDUMP_READ (p, Lisp_Object)); break; } else p += sizeof (Lisp_Object) * rt.count; } I don't mind doing the legwork, just not sure what direction to head at the moment since I've only just started crawling into the code. Thanks in advance for any direction, Troy -----Original Message----- From: Olivier Galibert [mailto:galibert＠pobox.com] Sent: Wednesday, November 15, 2000 11:03 AM To: 'xemacs-beta(a)xemacs.org' Subject: Re: Who is the portable dumper expert? 21.2.37 Portable dumper still broken. On Wed, Nov 15, 2000 at 09:27:21AM -0700, Troy Noble wrote: > Who's the portable dump expert, and are there plans to fix this anytime > soon? Theorically, that's me. Theorically, because I've not been working on XEmacs for far too long to be qualified as currently active. I will answer any of your questions (or from whoever else who wants to work on the dumper), be it on xemacs-beta or by private mail. OG.

2 participants
1 comments

Re: My location: Munich, Germany! 23 years, 5 months

Dhruva_KRISHNAMURTHY＠delmia.com

Hi, I guess it is a great move, I hope everyone would be interested in letting people, I mean people on the xemacs-beta list. It helps us get a picture of XEmacs popularity region wise. Anyway, I like to chip in. I am from India (Bangalore) and work as a software engineer/developer (C/C++). with best regards, dhruva

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