Ar an dara lá de mí Deireadh Fómhair, scríobh Vin Shelton: Am seeing it locally, so that’s unnecessary. I don’t know. I thought initially it was because unicode-error-sequence-regexp-range included non-character values in its numeric range; but editing regex.c to avoid that doesn’t help. The failure that provokes the error message is that dy->largest is 5 while dy->max is four; however right up to dump time and beyond, dy->max is eight, it’s only on loading the dumped data that it becomes 4. If I explicitly overwrite Vthe_lisp_rangetab with an empty range table before dumping, the build continues; but as far as I can work out this a bug in the dump process. Marcus, you’ve worked with this pretty closely; any ideas? (This patch makes the build continue with the current unicode.el:) Index: dumper.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/dumper.c,v retrieving revision 1.36 diff -u -u -r1.36 dumper.c --- dumper.c 2007/08/22 15:10:18 1.36 +++ dumper.c 2007/10/03 16:20:43 ＠＠ -43,6 +43,7 ＠＠ #include "lstream.h" #include "sysfile.h" #include "console-stream.h" +#include "rangetab.h" #ifdef WIN32_NATIVE #include "syswindows.h" ＠＠ -1976,9 +1977,17 ＠＠ Lisp_Object t_console, t_device, t_frame; int none; pdump_header header; + extern Lisp_Object Vthe_lisp_rangetab; in_pdump = 1; + { + Vthe_lisp_rangetab = Fmake_range_table (Qstart_closed_end_closed); + } + pdump_object_table = xnew_array (pdump_block_list, lrecord_type_count); pdump_alert_undump_object = xnew_array (int, lrecord_type_count); -- On the quay of the little Black Sea port, where the rescued pair came once more into contact with civilization, Dobrinton was bitten by a dog which was assumed to be mad, though it may only have been indiscriminating. (Saki) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta