On 2/22/07, Chen, Michel <michelc(a)ti.com> wrote:
>
> Is there a way to install for Linux xemacs version 21.4.20 on a network
> disk,
>
> and each Linux machine on the local network can use it?
Yes, there are a number of network file systems supported by linux:
NFS, etc. XEmacs can be installed on a network file system:
./configure --prefix=/a/xemacs-21.4.20
where /a is a network share. Without more details about your network
configuration, it's hard to help more.
- Vin
PS. Please reply to xemacs-beta if you wish to follow up. Thanks.
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Chen, Michel writes:
> Is there a way to install for Linux xemacs version 21.4.20 on a network
> disk,
>
> and each Linux machine on the local network can use it?
Yes. XEmacs does not care whether it is started from a local drive or
a network share. The workstations must be configured to look for
XEmacs on the network share. Depending on the installation, XEmacs
may need to be configured to look for its modules and data files on
the network share, although the default installation should just work.
Such configuration is not an XEmacs issue; it is something you'll have
to ask your local sysadmin about.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Hello,
I got a creash while using the xemacs as a debugger front end. For debugging, I just started using
The xemacs and initially found interesting but now wuite often I receive such issues of crashes.
Can somebody point out the problem ?
I have tried to provide good enough details
Thanx in advance !!
Thanx and Regards
Digvijaya
'M-x describe-installation' outputs -
uname -a: Linux bugs.build.redhat.com 2.4.21-23.ELsmp #1 SMP Thu Oct 28 20:10:03 EDT 2004 i686 i686 i386 GNU/Linux
./configure 'i386-redhat-linux-gnu' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share' '--libdir=/usr/lib' '--mandir=/usr/share/man/man1' '--infodir=/usr/share/info' '--with-gpm=no' '--with-sound=native' '--with-pop' '--mail-locking=lockf' '--with-clash-detection' '--debug=yes' '--with-mule=yes' '--with-database=berkdb' '--with-ldap=yes' '--with-hesiod=no' '--with-canna=yes' '--with-wnn=yes' '--with-xim=xlib' '--with-athena=3d' '--with-widgets=athena' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena' '--with-msw=no' '--with-xfs=yes' '--pdump'
XEmacs 21.4.13 "Rational FORTRAN" configured for `i386-redhat-linux'.
Compilation / Installation:
Source code location: /usr/src/build/514944-i386/BUILD/xemacs-21.4.13
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O2 -g -pipe -march=i386 -mcpu=i686
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- 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.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "lockf" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Compiling in support for extra debugging code.
(gdb /usr/bin/xemacs-21.4.13 core) Backtrace is as follows -
#0 0x007d7fd1 in kill () from /lib/tls/libc.so.6
#1 0x080b0e6e in fatal_error_signal ()
#2 <signal handler called>
#3 0x0012bcd8 in XFillRectangle () from /soft/sds/x86-linux/X11R6/lib/libX11.so.6
#4 0x081d13fa in XawGaugeGetValue ()
#5 0x081d0418 in RadioUnset ()
#6 0x009295ac in SendExposureEvent () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#7 0x009291c7 in CompressExposures () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#8 0x00928e40 in XtDispatchEventToWidget () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#9 0x00929b5d in _XtDefaultDispatcher () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#10 0x00929fc6 in XtDispatchEvent () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#11 0x00938a6b in XtAppProcessEvent () from /soft/sds/x86-linux/X11R6/lib/libXt.so.6
#12 0x081a8769 in emacs_Xt_event_handler ()
#13 0x081a87f4 in emacs_Xt_event_handler ()
#14 0x080fdba8 in allocate_command_builder ()
#15 0x081000bc in Fdispatch_non_command_events ()
#16 0x080b84aa in Feval ()
#17 0x080b59f3 in condition_case_1 ()
#18 0x080b5c66 in condition_case_3 ()
#19 0x08092aac in execute_rare_opcode ()
#20 0x08091d76 in funcall_compiled_function ()
#21 0x08091b18 in funcall_compiled_function ()
#22 0x080b8972 in Ffuncall ()
#23 0x08091efd in funcall_compiled_function ()
#24 0x08091b18 in funcall_compiled_function ()
#25 0x080b8972 in Ffuncall ()
#26 0x08091efd in funcall_compiled_function ()
#27 0x08091b18 in funcall_compiled_function ()
#28 0x080b8972 in Ffuncall ()
#29 0x08091efd in funcall_compiled_function ()
#30 0x08091b18 in funcall_compiled_function ()
#31 0x080b8972 in Ffuncall ()
#32 0x08091efd in funcall_compiled_function ()
#33 0x08091b18 in funcall_compiled_function ()
#34 0x080b8972 in Ffuncall ()
#35 0x08091efd in funcall_compiled_function ()
#36 0x08091b18 in funcall_compiled_function ()
#37 0x080b8972 in Ffuncall ()
#38 0x08091efd in funcall_compiled_function ()
#39 0x08091b18 in funcall_compiled_function ()
#40 0x080b8972 in Ffuncall ()
#41 0x08091efd in funcall_compiled_function ()
#42 0x08091b18 in funcall_compiled_function ()
#43 0x080b8972 in Ffuncall ()
#44 0x08091efd in funcall_compiled_function ()
#45 0x0809478c in Fbyte_code ()
#46 0x080b84fa in Feval ()
#47 0x080b59f3 in condition_case_1 ()
#48 0x080b5c66 in condition_case_3 ()
#49 0x08092aac in execute_rare_opcode ()
#50 0x08091d76 in funcall_compiled_function ()
#51 0x08091b18 in funcall_compiled_function ()
#52 0x080b8972 in Ffuncall ()
#53 0x08091efd in funcall_compiled_function ()
#54 0x08091b18 in funcall_compiled_function ()
#55 0x080b8972 in Ffuncall ()
#56 0x08091efd in funcall_compiled_function ()
#57 0x08091b18 in funcall_compiled_function ()
#58 0x080b8972 in Ffuncall ()
#59 0x08091efd in funcall_compiled_function ()
#60 0x08091b18 in funcall_compiled_function ()
#61 0x080b8972 in Ffuncall ()
#62 0x08091efd in funcall_compiled_function ()
#63 0x08091b18 in funcall_compiled_function ()
#64 0x080b8972 in Ffuncall ()
#65 0x080b9420 in run_hook_with_args_in_buffer ()
#66 0x080b9548 in run_hook_with_args ()
#67 0x080b921b in Frun_hooks ()
#68 0x080b8b43 in Ffuncall ()
#69 0x08091efd in funcall_compiled_function ()
#70 0x08091b18 in funcall_compiled_function ()
#71 0x080b8972 in Ffuncall ()
#72 0x08091efd in funcall_compiled_function ()
#73 0x0809478c in Fbyte_code ()
#74 0x080b84fa in Feval ()
#75 0x080b59f3 in condition_case_1 ()
#76 0x080b5c66 in condition_case_3 ()
#77 0x08092aac in execute_rare_opcode ()
#78 0x08091d76 in funcall_compiled_function ()
#79 0x08091b18 in funcall_compiled_function ()
#80 0x080b8972 in Ffuncall ()
#81 0x08091efd in funcall_compiled_function ()
#82 0x08091b18 in funcall_compiled_function ()
#83 0x080b8972 in Ffuncall ()
#84 0x08091efd in funcall_compiled_function ()
#85 0x08091b18 in funcall_compiled_function ()
#86 0x080b8972 in Ffuncall ()
#87 0x08091efd in funcall_compiled_function ()
#88 0x08091b18 in funcall_compiled_function ()
#89 0x080b8972 in Ffuncall ()
#90 0x08091efd in funcall_compiled_function ()
#91 0x08091b18 in funcall_compiled_function ()
#92 0x080b8972 in Ffuncall ()
#93 0x08091efd in funcall_compiled_function ()
#94 0x08091b18 in funcall_compiled_function ()
#95 0x080b8972 in Ffuncall ()
#96 0x080b97e5 in call2 ()
#97 0x080ba5bb in call0_trapping_errors ()
#98 0x080b59f3 in condition_case_1 ()
#99 0x080ba816 in call2_trapping_errors ()
#100 0x08163129 in read_process_output ()
#101 0x08100c58 in wait_delaying_user_input ()
#102 0x081009ca in Fsit_for ()
#103 0x080b8a0c in Ffuncall ()
#104 0x08091efd in funcall_compiled_function ()
#105 0x08091b18 in funcall_compiled_function ()
#106 0x080b8972 in Ffuncall ()
#107 0x08091efd in funcall_compiled_function ()
#108 0x08091b18 in funcall_compiled_function ()
#109 0x080b8972 in Ffuncall ()
#110 0x08091efd in funcall_compiled_function ()
#111 0x08091b18 in funcall_compiled_function ()
#112 0x080b8972 in Ffuncall ()
#113 0x080b9495 in run_hook_with_args_in_buffer ()
#114 0x080b9548 in run_hook_with_args ()
#115 0x080b9250 in Frun_hook_with_args ()
#116 0x080b8b43 in Ffuncall ()
#117 0x08091efd in funcall_compiled_function ()
#118 0x08091b18 in funcall_compiled_function ()
#119 0x080b8972 in Ffuncall ()
#120 0x080b96f7 in apply1 ()
#121 0x08095b78 in Fcall_interactively ()
#122 0x080b79a3 in Fcommand_execute ()
#123 0x08101dd1 in extract_vector_nth_mouse_event ()
#124 0x08102167 in Fdispatch_event ()
#125 0x0809c41b in Fcommand_loop_1 ()
#126 0x080b59f3 in condition_case_1 ()
#127 0x0809be9a in Freally_early_error_handler ()
#128 0x0809becb in Freally_early_error_handler ()
#129 0x080b5649 in internal_catch ()
#130 0x0809c027 in initial_command_loop ()
#131 0x080b1f09 in xemacs_21_4_13_i386_redhat_linux ()
#132 0x080b29d2 in main ()
#133 0x007c578a in __libc_start_main () from /lib/tls/libc.so.6
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
haskell-mode
haskell-mode.el contains a Mule-only feature (a coding cookie as a
file-local variable). This patch removes that coding cookie, making
it possible to build haskell-mode under no-Mule XEmacs 21.5. The
alternative is to move haskell-mode to mule-packages, which is stupid.
(True, no-Mule 21.5 should not crash here, but that's not the point;
even if it didn't, it still couldn't do anything sensible with a
coding cookie, so having a cookie is a bug outside of mule-packages.
<RANT>Actually, IMHO, having a cookie is a bug, period....</RANT>)
>From the point of view of many users of non-Western-European 8-bit
coding-systems under Mule, the package will actually work better this
way, as their favorite coding system suddenly will acquire a
more-or-less sane syntax table. Another way to put this is that
haskell-mode is currently broken under all non-ISO-8859-1 locales, and
this makes it a little better. :-)
My apologies to Mats for taking so long to diagnose this. With this
change, we should be able to reenable the 21.5-nomule smoke test.
Jerry, do you have any objections?
Index: ChangeLog
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/haskell-mode/ChangeLog,v
retrieving revision 1.27
diff -u -r1.27 ChangeLog
--- ChangeLog 25 May 2006 08:41:46 -0000 1.27
+++ ChangeLog 20 Feb 2007 15:44:48 -0000
@@ -0,0 +1,4 @@
+2007-02-21 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * haskell-mode.el: Non-MULE doesn't support iso-8859-1 cookie.
+
Index: haskell-mode.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/haskell-mode/haskell-mode.el,v
retrieving revision 1.7
diff -u -r1.7 haskell-mode.el
--- haskell-mode.el 15 Mar 2006 05:18:23 -0000 1.7
+++ haskell-mode.el 20 Feb 2007 15:44:48 -0000
@@ -1,4 +1,4 @@
-;;; haskell-mode.el --- A Haskell editing mode -*-coding: iso-8859-1;-*-
+;;; haskell-mode.el --- A Haskell editing mode
;; Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc
;; Copyright (C) 1992, 1997-1998 Simon Marlow, Graeme E Moss, and Tommy Thorn
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Hi,
I just saw a difference between 21.4 and 21.5 about live windows. I
managed to reduce the code down to this below.
----------------------------------------------------------------------
(defun my-test (args)
(interactive "e")
(mouse-set-point current-mouse-event)
(let ((release-window (selected-window)))
(message "Window: %s" release-window)
(sit-for 1)
(read-string "### ")
(if (window-live-p release-window)
(select-window release-window)
(message "Window: %s not live" release-window)
)))
(global-set-key '(control shift button2up) 'my-test)
----------------------------------------------------------------------
Procedure: Make a split screen {C-x 2}, press (control shift button2)
in one window and then drag the mouse over to the other window and
release button2, so that a (control shift button2up) event is
generated, and my-test is executed. The result of running my-test is
that the second window is not live in 21.5 but is live in 21.4.
The intervening call to read-string, using the minibuffer, is
important for causing this difference. Maybe beeing in the minibuffer
for a while
The second window is visible all the time during this operation so how
come it is not live anymore? Is this a bug in 21.5?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
APPROVE COMMIT 21.5 RECOMMEND 21.4
Vin, I haven't actually checked, but the comments in these files smell
like they go back to maybe Jamie. ;-) 21.4 probably should get this
patch, too. It may not apply as is because it's got some of Ben's
newfangled naming in it.
Takashi Iwai writes:
> The last patch in the above is correct and doesn't lead to crashes.
OK.
> > (2) Now, this looks like a bug in the 64-bit X libraries to me. What
> > happens if it gets fixed?
>
> It's no implementation bug but a brain-dead API definition.
Oh, I think I can see why they did it. With any luck, your code will
work on 64-bit platforms running X11R4. (^^;
Here's the patch I'm putting into XEmacs. The bug report shows SuSE
has done extensive testing, and it clearly conforms to documentation.
I've verified that callers in XEmacs do indeed expect to receive
arrays of longs. The remaining question in my mind is whether this is
going to be right for older Xlibs on 64-bit platforms, but that's not
something that can be tested without access to implementations.
Mike & Takashi, I've taken the liberty of doing extensive revision to
the commentary, but the code is yours. I thought about fiddling with
some of the hard-coded assumptions, but really, we don't support
128-bit processors yet anyway, and it seems *really* unlikely that
there will ever again be a platform with anything but 8-bit chars and
16-bit shorts.
If you want any changes to the credits, let me know.
Index: src/ChangeLog
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v
retrieving revision 1.1044
diff -u -U0 -r1.1044 ChangeLog
--- src/ChangeLog 15 Feb 2007 16:12:13 -0000 1.1044
+++ src/ChangeLog 17 Feb 2007 15:45:05 -0000
@@ -0,0 +1,13 @@
+2007-02-18 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ Code by Mike FABIAN <mfabian(a)suse.de>, Takashi Iwai <tiwai(a)suse.de>.
+ See xemacs-beta <s3thctmf46c.fsf(a)magellan.suse.de>. Thanks!
+ Documentation marshalled by me.
+
+ * select-x.c (x_get_window_property):
+ The buffer for property data in 32-bit format is an array of longs,
+ which need not be 32-bit. Compute residual from partial reads and
+ buffer sizes correctly for sizeof(long) == 8.
+
+ * select-common.h: Refer to documentation in select-x.c.
+
Index: src/select-common.h
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/select-common.h,v
retrieving revision 1.6
diff -u -r1.6 select-common.h
--- src/select-common.h 25 Oct 2005 11:16:27 -0000 1.6
+++ src/select-common.h 17 Feb 2007 15:45:11 -0000
@@ -47,6 +47,10 @@
if > 16 bits: Cons of top16, bot16
* 32 > 1 Vector of the above
+ NOTE NOTE NOTE:
+ Format == 32 means that the buffer will be C longs, which need not be
+ 32-bit quantities. See the note in select-x.c (x_get_window_property).
+
When converting a Lisp number to C, it is assumed to be of format 16 if
it is an integer, and of format 32 if it is a cons of two integers.
Index: src/select-x.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/select-x.c,v
retrieving revision 1.23
diff -u -r1.23 select-x.c
--- src/select-x.c 2 Mar 2005 18:31:57 -0000 1.23
+++ src/select-x.c 17 Feb 2007 15:45:12 -0000
@@ -1048,7 +1048,42 @@
return;
}
- total_size = bytes_remaining + 1;
+ /* The manpage for XGetWindowProperty from X.org X11.7.2 sez:
+ nitems_return [[ our actual_size_ret ]]
+ Returns the actual number of 8-bit, 16-bit, or 32-bit items
+ stored in the prop_return data.
+ prop_return [[ our tmp_data ]]
+ Returns the data in the specified format. If the returned
+ format is 8, the returned data is represented as a char
+ array. If the returned format is 16, the returned data is
+ represented as a array of short int type and should be cast
+ to that type to obtain the elements. If the returned format
+ is 32, the property data will be stored as an array of longs
+ (which in a 64-bit application will be 64-bit values that are
+ padded in the upper 4 bytes).
+ bytes_after_return [[ our bytes_remaining ]]
+ Returns the number of bytes remaining to be read in the prop-
+ erty if a partial read was performed.
+
+ AFAIK XEmacs does not support any platforms where the char type is other
+ than 8 bits (Cray?), or where the short type is other than 16 bits.
+ There is no such agreement on the size of long, and 64-bit platforms
+ generally make long be a 64-bit quantity while while it's 32 bits on
+ 32-bit platforms.
+
+ This means that on all platforms the wire item is the same size as our
+ buffer unit when format == 8 or format == 16 or format == wordsize == 32,
+ and the buffer size can be taken as bytes_remaining plus padding.
+ However, when format == 32 and wordsize == 64, the buffer unit is twice
+ the size of the wire item. Obviously this code below is not 128-bit
+ safe. (We could replace the factor 2 with (sizeof(long)*8/32.)
+
+ We can hope it doesn't much matter on versions of X11 earlier than R7.
+ */
+ if (sizeof(long) == 8 && *actual_format_ret == 32)
+ total_size = 2 * bytes_remaining + 1;
+ else
+ total_size = bytes_remaining + 1;
*data_ret = xnew_rawbytes (total_size);
/* Now read, until we've gotten it all. */
@@ -1072,7 +1107,12 @@
reading it. Deal with that, I guess....
*/
if (result != Success) break;
- *actual_size_ret *= *actual_format_ret / 8;
+ /* Again we need to compute the number of bytes in our buffer, not
+ the number of bytes transferred for the property. */
+ if (sizeof(long) == 8 && *actual_format_ret == 32)
+ *actual_size_ret *= 8;
+ else
+ *actual_size_ret *= *actual_format_ret / 8;
memcpy ((*data_ret) + offset, tmp_data, *actual_size_ret);
offset += *actual_size_ret;
XFree ((char *) tmp_data);
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Hi,
I'm using xemacs-beta, and I realise it's quite old, but it has more
features than the most recent stable branch which I absolutely need
and cannot live without (i.e. sub-pixel anti-aliased true-type fonts
:-) )
I compiled it with the following flags:
--host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu
--prefix=/usr/local/xemacs
--with-package-path=/usr/local/xemacs/lib/xemacs/xemacs-packages
--with-xft=emacs,menubars,tabs,gauges
--without-gtk
--without-gnome
--with-athena=3d
--with-menubars=lucid
--with-scrollbars=lucid
--with-dialogs=athena
--with-widgets=athena
--with-gpm=no
--with-sound=no
--with-xim=no
--with-zlib
--with-database=no
--with-postgresql=no
--with-ldap=no
--with-ipv6-cname
--with-error-checking=no
--without-debug
Anyway, when I go into the haskell-mode package directory and type:
make bytecompile
I eventually get this:
xemacs -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error
t load-always-display-messages t load-ignore-out-of-date-elc-files t
load-show-full-path-in-messages t)' -eval '(setq load-path (list
lisp-directory))' -l
/home/ayqazi/src/packages/xemacs/cvs/packages/package-compile.el --
dired mail-lib xemacs-base edit-utils -- -l comint -l cus-face -l
font-lock -l func-menu -l imenu -l haskell-mode -l haskell-indent -f
batch-byte-compile auto-autoloads.el
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/package-compile.el...
Loading /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/auto-autoloads.elc...
Requiring /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/bytecomp.elc...
Requiring /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/byte-optimize.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/edit-utils/auto-autoloads.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/xemacs-base/auto-autoloads.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/mail-lib/auto-autoloads.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/dired/auto-autoloads.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/xemacs-base/comint.elc...
Requiring /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/xemacs-base/ring.elc...
Loading /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/cus-face.elc...
Loading /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/cus-face.elc...
Loading /usr/local/xemacs/lib/xemacs-21.5-b27/lisp/font-lock.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/edit-utils/func-menu.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/xemacs-base/imenu.elc...
Loading /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/haskell-mode/haskell-mode.el...make:
*** [auto-autoloads.elc] Interrupt
Note that I have to manually kill it, or it goes into a memory-sucking
vortex of death where all my memory is filled up and my computer is
ground to a halt until the kenel sensibly kills as many processes as
it can - unfortunately including the X server and anything running
under it.
Any ideas what's causing it? Or should it be ignored, and I just use
the latest stable version of XEmacs for my package compiling
shenanigans?
Thanks
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>>>>> "ST" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
ST> Suggestions for improvement of the process *are* welcome,
This isn't related to the original poster's problem, but it's something
I stumbled on a few days ago trying to update the MH-E package to the
latest upstream version.
background:
MH-E 8 delivers a bunch more files than MH-E 7, and there are
assumptions in the code about how the source is laid out. In
particular, there is at least one defvar that results in a call to find
where the (new) images live. The code that looks for the images looks
like it will work with this source layout:
mh-e/etc/images/*.pbm
mh-e/lisp/*.el
But it chokes if the Lisp source files are in the top-level directory
(i.e., mh-e/*.el), which is where they live currently.
I discussed this with the upstream team, and we agreed on changing the
source organization in the XEmacs package: create a lisp subdirectory
and move the source files there.
The problem:
I kept getting compilation failures, like being unable to load mh-e.el
in response to (require 'mh-e). And other packages that depended on
mh-e wouldn't compile either.
It turns out that in addition to setting
AUTOLOAD_PATH = lisp
I had to edit package-name-to-directory (in package-compile.el), to tell
it that the mh-e sources live now live in a "lisp" directory.
Proposal:
I was thinking it would be better to generate some or all of
package-name-to-directory on the fly, using the AUTOLOAD_PATH settings
in the makefiles.
I'm willing to code it up and test it on a couple platforms, though it
will probably be several weeks before I can get to it.
Does anyone see a problem with doing this?
cheers,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta