"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: I still have a workspace containing OG's code for dumping bignums. I had to remove one bit of type-checking he had. It used the comma operator, but every C compiler I used warned about that construct, and g++ couldn't digest it at all. It looks like that workspace is slightly bitrotted. I'll work on it over the next couple of days and commit it. -- Jerry James http://www.ittc.ku.edu/~james/

? How come it's only on this platform?

Mon, 31 Jan 2005 (14:05 +0900 UTC) Stephen J. Turnbull wrote: No warnings on my OS X 10.3.7 system with gcc 3.3 20030304 (Apple Computer, Inc. build 1671) for the gcc command gcc -c -Wall -Wno-switch -Wmissing-prototypes -Wsign-compare -Wno-char-subscripts -Wundef -Wstrict-prototypes -Wpacked -Wpointer-arith -Wunused-parameter -g -Os -Demacs -I. -DHAVE_CONFIG_H -I/opt/local/include -I/usr/X11R6/include dumper.c The only remaining 'int format' warnings are emacs.c:1006: warning: unsigned int format, size_t arg (arg 2) emacs.c:1006: warning: unsigned int format, size_t arg (arg 3) extents.c:3122: warning: long int format, int arg (arg 3) extents.c:3122: warning: long int format, int arg (arg 4) print.c:2180: warning: long int format, int arg (arg 2) process-unix.c:1901: warning: long int format, int arg (arg 4) My config is a bit non-standard for 21.5.b18: ./configure '--with-mule' '--with-widgets=athena' '--with-athena=3d' '--with-dialogs=athena' '--with-scrollbars=athena' '--error-checking=none' '--site-libraries=/opt/local/lib:/usr/X11R6/lib:/usr/lib' '--debug=no' '--site-runtime-libraries=/opt/local/lib:/usr/X11R6/lib:/usr/lib' '--package-path=/Users/royar/usr/local/lib/xemacs/xemacs-packages:/Users/royar/usr/local/lib/xemacs/mule-packages' '--prefix=/Users/royar/usr/local' '--with-prefix' '--with-png' '--with-jpeg' '--with-tiff' '--cflags= -Os' '--pdump' '--with-xmu' '--with-xim=no' '--with-sound=esd' '--with-xfs=no' '--use-number-lib=gmp' '--use-union-type' '--dynamic=yes' XEmacs 21.5-b18 "chestnut" (+CVS-20050128) configured for `powerpc-apple-darwin7.7.0'. gcc -Wall -Wno-switch -Wmissing-prototypes -Wsign-compare -Wno-char-subscripts -Wundef -Wstrict -prototypes -Wpacked -Wpointer-arith -Wunused-parameter -g -Os -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky

robert> No warnings on my OS X 10.3.7 system with gcc 3.3 20030304 robert> (Apple Computer, Inc. build 1671) for the gcc command robert> gcc -c -Wall -Wno-switch -Wmissing-prototypes -Wsign-compare Thanks for the report! I can confirm on my system, too, as well as on Linux. I think probably I was doing very few compiles on Linux for a while, so one of Ben's type-correctness fixes caught this at some point. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

On Mon, 31 Jan 2005, Darryl Okahata stated: My primary working platform is an UltraSPARC/Linux box, big-endian. I've been using the portable undumper since at least 21.4.10 and probably before then. It works fine. So it's byte order clean, I'd say. (I'd really like it if the .dmp files didn't have to go in /usr/bin, though... can they be moved?) -- `Blish is clearly in love with language. Unfortunately, language dislikes him intensely.' --- Russ Allbery

On Thu, 3 Feb 2005, Aidan Kehoe spake: Excellent: the *right* place for them. (How do you put them there? libelf and a custom ELF section isn't portable enough... a huge static array? It'd almost have to be...) -- `Blish is clearly in love with language. Unfortunately, language dislikes him intensely.' --- Russ Allbery

Nix <nix(a)esperi.org.uk&gt; wrote: This may already be possible (sorry, I haven't checked ;-), but it would be *REALLY* nice if plain users could make their own, private dumps. You could significantly speed up startup, by preloading a lot of user-specific junk from ~/.xemacs/init.el and then dumping that. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: While a separate dump file is preferable, from a disk space standpoint (perhaps, compressing it, too?), a private binary is fine. Disk space is cheap. ;-) You just have to make sure that the private binary can tell where the XEmacs installation is. [ Well, if you're on a multi-user system, then there may be issues ... ;-) ] Well, while a private binary isn't optimal, it's a perfectly usable solution. Given that this is -- at least initially, until we have more experience with it -- something of an "advanced feature", we probably don't need a nice interface. Here are some wild ideas, to which I've given virtually no thought ;-): * Plan A: Press a button, and the current state of the running XEmacs gets dumped (just like a real, old-fashioned lisp workspace ;-). All of it. At this point, the user can rename ~/.xemacs/init.el and try running the newly-dumped XEmacs (the normal loading of init.el and custom.el will still continue). [ I can't help but wonder if a lot of additional work is required for this. I haven't looked, but can the existing pdump code handle dumping an XEmacs with an active GUI? ] * Plan B: The user runs XEmacs in batch mode (just like today), but the contents of init.el (by default) is included in the dump. A different file other than init.el can be optionally specified. [ Virtually all of the code needed to do this should already exist. The only issue that comes to mind is if the user has added interactive code to his init.el (i.e., code that prompts him for something at startup). ] Yup. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.