Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() )
26 years, 3 months
Gary D. Foster
Gary D. Foster
>>>>> "DO" == Darryl Okahata <darrylo(a)sr.hp.com> writes:
DO> Mike Scheidler <c23mts(a)eng.delcoelect.com> wrote:
>> You can't dispute raw numbers, but I don't think this is an
>> accurate usage indicator. I'd venture that most of the
>> non-Linux binary kit downloads are used by more than one person
>> (does an average of 10 sound reasonable?), while most Linux
>> downloads are single-user.
This talk of only supporting linux disturbs me deeply. I cannot possibly
believe that anyone is seriously considering this?
I use linux on my laptop and I use solaris everywhere else. I like
linux, I like what it's done for the Unix community in general. What
I _don't_ like about linux is when I see all these pieces of software
come out that are written specifically for it without even a nod
towards portability. I get _really_ annoyed when I see that someone
has written a really nifty utility or tool or front-end or whatever
and it's riddled through with linux-isms which end up making it
difficult (if not downright impossible) to port to any other unix. A
perfect example for this is some of the graphical front-ends to cdrom
burning software. I end up using the command-line tools because the
GUI front-ends _to_ the command line tools were written in such a way
as to make it impossible to compile on any other platform without a
complete rewrite. It's ironic that the underlying tools that these
rely on are well-written cross-platform apps while the stupid FRONT
END tools which do nothing but feed the cross-platform CLI's are not.
Linux-centrism is JUST as bad as microsoft-centrism or
solaris-centrism or anything-else-centrism.
-- Gary F.
(who cannot even begin to communicate the frustration of trying to
compile the latest enlightenment snapshots on solaris, for example).
--
"Whenever you find yourself on the side of the majority it is
time to pause and reflect." -- Mark Twain
- 2 participants
- 1 comments
Crash while building SEMI 1.8.5
26 years, 3 months
Dan Rich
Dan Rich
In XEmacs 21.0 "Erzgeberg-pre1" [Lucid] (sparc-sun-solaris2.5.1, Mule) of Mon Aug 31 1998 on sandman
configured using `configure --site-libraries=/opt/local/lib --site-includes=/opt/local/include --with-mule --dynamic --prefix=/usr/local/beta --with-tooltalk=no'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
While attempting to build SEMI 1.8.5 on Solaris 2.5.1, I got a crash
in file-coding.c. This XEmacs was built from a cvs update of last
Thursday's CVS tree. Other than this, it's been running fine since Friday.
Here's the output from the make, the stack trace from the core image
follows.
/usr/local/beta/bin/xemacs -batch -q -no-site-file -l SEMI-MK -f compile-semi \
NONE NONE NONE
Loading /home/drich/Lisp/tm-eng/semi-1.8.5/SEMI-CFG...
Loading /home/drich/Lisp/tm-eng/semi-1.8.5/SEMI-ELS...
Compiling /home/drich/Lisp/tm-eng/semi-1.8.5/mime-edit.el...Fatal error: assertion failed, file file-coding.c, line 2037, abort()
PREFIX=/usr/local/beta EXEC_PREFIX=/usr/local/beta
LISPDIR=/usr/local/beta/lib/xmule/site-lisp
("/usr/local/beta/lib/xemacs-21.0/etc/w3" "/usr/local/beta/lib/xemacs/packages/lisp/mailcrypt" "/home/drich/Lisp/tm-eng/semi-1.8.5" "/usr/local/beta/lib/xemacs/packages/lisp/flim" "/usr/local/beta/lib/xemacs-21.0/etc" "/usr/local/beta/lib/site-lisp/apel" "/usr/local/beta/lib/xemacs/packages/lisp/" "/usr/local/beta/lib/xemacs/packages/lisp/Sun/" "/usr/local/beta/lib/xemacs/packages/lisp/ada/" "/usr/local/beta/lib/xemacs/packages/lisp/apel/" "/usr/local/beta/lib/xemacs/packages/lisp/auctex/" "/usr/local/beta/lib/xemacs/packages/lisp/c-support/" "/usr/local/beta/lib/xemacs/packages/lisp/calc/" "/usr/local/beta/lib/xemacs/packages/lisp/calendar/" "/usr/local/beta/lib/xemacs/packages/lisp/cc-mode/" "/usr/local/beta/lib/xemacs/packages/lisp/cookie/" "/usr/local/beta/lib/xemacs/packages/lisp/crisp/" "/usr/local/beta/lib/xemacs/packages/lisp/debug/" "/usr/local/beta/lib/xemacs/packages/lisp/dired/" "/usr/local/beta/lib/xemacs/packages/lisp/edebug/" "/usr/local/beta/lib/xemacs/packages!
/lisp/edict/" "/usr/local/beta/lib/xemacs/packages/lisp/ediff/" "/usr/local/beta/lib/xemacs/packages/lisp/edit-utils/" "/usr/local/beta/lib/xemacs/packages/lisp/edt/" "/usr/local/beta/lib/xemacs/packages/lisp/efs/" "/usr/local/beta/lib/xemacs/packages/lisp/emerge/" "/usr/local/beta/lib/xemacs/packages/lisp/emu/" "/usr/local/beta/lib/xemacs/packages/lisp/eterm/" "/usr/local/beta/lib/xemacs/packages/lisp/eudc/" "/usr/local/beta/lib/xemacs/packages/lisp/flim/" "/usr/local/beta/lib/xemacs/packages/lisp/footnote/" "/usr/local/beta/lib/xemacs/packages/lisp/forms/" "/usr/local/beta/lib/xemacs/packages/lisp/frame-icon/" "/usr/local/beta/lib/xemacs/packages/lisp/fsf-compat/" "/usr/local/beta/lib/xemacs/packages/lisp/games/" "/usr/local/beta/lib/xemacs/packages/lisp/gnats/" "/usr/local/beta/lib/xemacs/packages/lisp/gnus/" "/usr/local/beta/lib/xemacs/packages/lisp/hm--html-menus/" "/usr/local/beta/lib/xemacs/packages/lisp/igrep/" "/usr/local/beta/lib/xemacs/packages/lisp/ilisp/" "/usr/lo!
cal/beta/lib/xemacs/packages/lisp/ispell/" "/usr/local/beta/lib/xemacs/packages/lisp/jde/" "/usr/local/beta/lib/xemacs/packages/lisp/mail-lib/" "/usr/local/beta/lib/xemacs/packages/lisp/mailcrypt/" "/usr/local/beta/lib/xemacs/packages/lisp/mh-e/" "/usr/local/beta/lib/xemacs/packages/lisp/mine/" "/usr/local/beta/lib/xemacs/packages/lisp/misc-games/" "/usr/local/beta/lib/xemacs/packages/lisp/mule-base/" "/usr/local/beta/lib/xemacs/packages/lisp/net-utils/" "/usr/local/beta/lib/xemacs/packages/lisp/os-utils/" "/usr/local/beta/lib/xemacs/packages/lisp/pc/" "/usr/local/beta/lib/xemacs/packages/lisp/pcl-cvs/" "/usr/local/beta/lib/xemacs/packages/lisp/ph/" "/usr/local/beta/lib/xemacs/packages/lisp/prog-modes/" "/usr/local/beta/lib/xemacs/packages/lisp/psgml/" "/usr/local/beta/lib/xemacs/packages/lisp/reftex/" "/usr/local/beta/lib/xemacs/packages/lisp/rmail/" "/usr/local/beta/lib/xemacs/packages/lisp/scheme/" "/usr/local/beta/lib/xemacs/packages/lisp/semi/" "/usr/local/beta/lib/xemacs!
/packages/lisp/sgml/" "/usr/local/beta/lib/xemacs/packages/lisp/sh-script/" "/usr/local/beta/lib/xemacs/packages/lisp/slider/" "/usr/local/beta/lib/xemacs/packages/lisp/speedbar/" "/usr/local/beta/lib/xemacs/packages/lisp/strokes/" "/usr/local/beta/lib/xemacs/packages/lisp/supercite/" "/usr/local/beta/lib/xemacs/packages/lisp/texinfo/" "/usr/local/beta/lib/xemacs/packages/lisp/text-modes/" "/usr/local/beta/lib/xemacs/packages/lisp/textools/" "/usr/local/beta/lib/xemacs/packages/lisp/time/" "/usr/local/beta/lib/xemacs/packages/lisp/tooltalk/" "/usr/local/beta/lib/xemacs/packages/lisp/tpu/" "/usr/local/beta/lib/xemacs/packages/lisp/vc/" "/usr/local/beta/lib/xemacs/packages/lisp/vhdl/" "/usr/local/beta/lib/xemacs/packages/lisp/view-process/" "/usr/local/beta/lib/xemacs/packages/lisp/viper/" "/usr/local/beta/lib/xemacs/packages/lisp/vm/" "/usr/local/beta/lib/xemacs/packages/lisp/w3/" "/usr/local/beta/lib/xemacs/packages/lisp/xemacs-base/" "/usr/local/beta/lib/xemacs/packages/lisp/!
xemacs-devel/" "/usr/local/beta/lib/xemacs-21.0/lisp/" "/usr/local/beta/lib/xemacs-21.0/lisp/apel/" "/usr/local/beta/lib/xemacs-21.0/lisp/auctex/" "/usr/local/beta/lib/xemacs-21.0/lisp/bytecomp/" "/usr/local/beta/lib/xemacs-21.0/lisp/calendar/" "/usr/local/beta/lib/xemacs-21.0/lisp/cc-mode/" "/usr/local/beta/lib/xemacs-21.0/lisp/cl/" "/usr/local/beta/lib/xemacs-21.0/lisp/comint/" "/usr/local/beta/lib/xemacs-21.0/lisp/custom/" "/usr/local/beta/lib/xemacs-21.0/lisp/dired/" "/usr/local/beta/lib/xemacs-21.0/lisp/edebug/" "/usr/local/beta/lib/xemacs-21.0/lisp/ediff/" "/usr/local/beta/lib/xemacs-21.0/lisp/efs/" "/usr/local/beta/lib/xemacs-21.0/lisp/egg/" "/usr/local/beta/lib/xemacs-21.0/lisp/electric/" "/usr/local/beta/lib/xemacs-21.0/lisp/emulators/" "/usr/local/beta/lib/xemacs-21.0/lisp/energize/" "/usr/local/beta/lib/xemacs-21.0/lisp/eos/" "/usr/local/beta/lib/xemacs-21.0/lisp/epoch/" "/usr/local/beta/lib/xemacs-21.0/lisp/eterm/" "/usr/local/beta/lib/xemacs-21.0/lisp/games/" "/us!
r/local/beta/lib/xemacs-21.0/lisp/gnats/" "/usr/local/beta/lib/xemacs-21.0/lisp/gnus/" "/usr/local/beta/lib/xemacs-21.0/lisp/hm--html-menus/" "/usr/local/beta/lib/xemacs-21.0/lisp/hyperbole/" "/usr/local/beta/lib/xemacs-21.0/lisp/ilisp/" "/usr/local/beta/lib/xemacs-21.0/lisp/iso/" "/usr/local/beta/lib/xemacs-21.0/lisp/its/" "/usr/local/beta/lib/xemacs-21.0/lisp/language/" "/usr/local/beta/lib/xemacs-21.0/lisp/leim/" "/usr/local/beta/lib/xemacs-21.0/lisp/locale/" "/usr/local/beta/lib/xemacs-21.0/lisp/mailcrypt/" "/usr/local/beta/lib/xemacs-21.0/lisp/mel/" "/usr/local/beta/lib/xemacs-21.0/lisp/mh-e/" "/usr/local/beta/lib/xemacs-21.0/lisp/modes/" "/usr/local/beta/lib/xemacs-21.0/lisp/mu/" "/usr/local/beta/lib/xemacs-21.0/lisp/mule/" "/usr/local/beta/lib/xemacs-21.0/lisp/ns/" "/usr/local/beta/lib/xemacs-21.0/lisp/oobr/" "/usr/local/beta/lib/xemacs-21.0/lisp/packages/" "/usr/local/beta/lib/xemacs-21.0/lisp/pcl-cvs/" "/usr/local/beta/lib/xemacs-21.0/lisp/prim/" "/usr/local/beta/lib/!
xemacs-21.0/lisp/psgml/" "/usr/local/beta/lib/xemacs-21.0/lisp/quail/" "/usr/local/beta/lib/xemacs-21.0/lisp/rmail/" "/usr/local/beta/lib/xemacs-21.0/lisp/skk/" "/usr/local/beta/lib/xemacs-21.0/lisp/sunpro/" "/usr/local/beta/lib/xemacs-21.0/lisp/term/" "/usr/local/beta/lib/xemacs-21.0/lisp/tl/" "/usr/local/beta/lib/xemacs-21.0/lisp/tm/" "/usr/local/beta/lib/xemacs-21.0/lisp/tooltalk/" "/usr/local/beta/lib/xemacs-21.0/lisp/url/" "/usr/local/beta/lib/xemacs-21.0/lisp/utils/" "/usr/local/beta/lib/xemacs-21.0/lisp/viper/" "/usr/local/beta/lib/xemacs-21.0/lisp/vm/" "/usr/local/beta/lib/xemacs-21.0/lisp/vms/" "/usr/local/beta/lib/xemacs-21.0/lisp/w3/" "/usr/local/beta/lib/xemacs-21.0/lisp/w32/" "/usr/local/beta/lib/xemacs-21.0/lisp/x11/")
Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Please report this bug by running the send-pr script included
with XEmacs, or selecting `Send Bug Report' from the help menu.
As a last resort send ordinary email to `crashes(a)xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type
gdb /usr/local/beta/bin/xemacs core
then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB. A similar procedure should work for all of
these. Ask your system administrator if you need more help.)
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
insert-file-contents-internal("/home/drich/Lisp/tm-eng/semi-1.8.5/mime-edit.el" nil nil nil nil undecided used-codesys)
byte-code("..." [run-hook-with-args insert-file-contents-access-hook filename visit coding-system-for-read run-special-hook-with-args insert-file-contents-pre-hook find-file-coding-system-for-read-from-filename buffer-file-coding-system-for-read no-conversion coding-system return-val find-coding-system message "Invalid coding-system (%s), using 'undecided" undecided insert-file-contents-internal beg end replace used-codesys] 9)
# (condition-case ... . ((file-error (byte-code "ÀÁ\n $Å ＠ A\"" ... 5))))
# bind (return-val coding-system used-codesys conversion-func replace end beg visit filename)
insert-file-contents("/home/drich/Lisp/tm-eng/semi-1.8.5/mime-edit.el")
# (unwind-protect ...)
# bind (byte-compile-current-file debug-issue-ebola-notices target-file input-buffer output-buffer byte-compile-dest-file load filename)
byte-compile-file("/home/drich/Lisp/tm-eng/semi-1.8.5/mime-edit.el")
# bind (el-file elc-file every-time path module)
compile-elisp-module(mime-edit "." nil)
# bind (module)
#<compiled-function (module) "...(8)" [compile-elisp-module module path every-time] 4>(mime-edit)
mapcar(#<compiled-function (module) "...(8)" [compile-elisp-module module path every-time] 4> (signature semi-def mime-view mime-text mime-play mime-partial mime-edit semi-setup mail-mime-setup mime-pgp mime-mc mime-w3 mime-image))
# bind (every-time path modules)
compile-elisp-modules((signature semi-def mime-view mime-text mime-play mime-partial mime-edit semi-setup mail-mime-setup mime-pgp mime-mc mime-w3 mime-image) ".")
compile-semi()
# bind (arg)
command-line-do-funcall("-f")
# bind (dir file-count line end-of-options first-file-buffer file-p arg tem)
command-line-1()
# bind (command-line-args-left)
command-line()
# (unwind-protect ...)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
make: *** [elc] Abort (core dumped)
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-sun-solaris2.5.1),
Copyright 1996 Free Software Foundation, Inc...
warning: core file may not match specified executable file.
Core was generated by `/usr/local/beta/bin/xemacs -batch -q -no-site-file -l SEMI-MK -f compile-semi N'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/dt/lib/libXm.so.3...done.
Reading symbols from /opt/local/lib/libtiff.so...done.
Reading symbols from /opt/local/lib/libpng.so.2...done.
Reading symbols from /usr/openwin/lib/libXpm.so.4.11...done.
Reading symbols from /usr/openwin/lib/libXmu.so.4...done.
Reading symbols from /usr/openwin/lib/libXt.so.4...done.
Reading symbols from /usr/openwin/lib/libXext.so.0...done.
Reading symbols from /usr/openwin/lib/libX11.so.4...done.
Reading symbols from /usr/openwin/lib/libSM.so.6.0...done.
Reading symbols from /usr/openwin/lib/libICE.so.6.3...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /opt/gnu/lib/libncurses.so.3.0...done.
Reading symbols from /usr/lib/libkvm.so.1...done.
Reading symbols from /usr/lib/libkstat.so.1...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libelf.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libw.so.1...done.
Reading symbols from /usr/lib/libintl.so.1...done.
Reading symbols from /usr/lib/libmp.so.1...done.
Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/nss_files.so.1...done.
#0 0xef17498c in kill ()
(gdb) where
#0 0xef17498c in kill ()
#1 0x48e84 in fatal_error_signal (sig=6) at emacs.c:262
#2 <signal handler called>
#3 0xef17498c in kill ()
#4 0x4b770 in assert_failed (file=0x1ad3e8 "file-coding.c", line=2037,
expr=0x1ad3f8 "abort()") at emacs.c:2605
#5 0x72084 in mule_decode (decoding=0x406200,
src=0x547000 ";;; mime-edit.el --- Simple MIME Composer for GNU Emacs\n\n;; Copyright (C) 1993,1994,1995,1996,1997,1998 Free Software Foundation, Inc.\n\n;; Author: UMEDA Masanobu <umerin(a)mse.kyutech.ac.jp>\n;; "...,
dst=0x470720, n=65536) at file-coding.c:2037
#6 0x7a308 in decoding_reader (stream=0x406200,
data=0x547000 ";;; mime-edit.el --- Simple MIME Composer for GNU Emacs\n\n;; Copyright (C) 1993,1994,1995,1996,1997,1998 Free Software Foundation, Inc.\n\n;; Author: UMEDA Masanobu <umerin(a)mse.kyutech.ac.jp>\n;; "...,
size=65536) at file-coding.c:1812
#7 0xdb7d8 in Lstream_read_more (lstr=0x406200) at lstream.c:509
#8 0xdb8e8 in Lstream_read (lstr=0x406200, data=0xefff2f30, size=32768)
at lstream.c:571
#9 0xa43fc in Finsert_file_contents_internal (filename=1615795128,
visit=-1607585788, beg=268435455, end=2814976, replace=2816000,
codesys=-1607485468, used_codesys=-1606627740) at fileio.c:2990
#10 0x516a4 in funcall_recording_as (recorded_as=-1607493484, nargs=7,
args=0xefffb350) at eval.c:3197
#11 0x518d0 in Ffuncall (nargs=8, args=0xefffb350) at eval.c:3238
#12 0x272dc in Fbyte_code (bytestr=1613173848, vector=-2144922412, maxdepth=67)
at bytecode.c:416
#13 0x50d84 in Feval (form=1076302920) at eval.c:3063
#14 0x4dc88 in condition_case_1 (handlers=1076303216, bfun=0x50554 <Feval>,
barg=1076302920, hfun=0x4dcd4 <run_condition_case_handlers>,
harg=-1607162508) at eval.c:1653
#15 0x4dee0 in condition_case_3 (bodyform=1076302920, var=-1607162508,
handlers=1076303216) at eval.c:1715
#16 0x2779c in Fbyte_code (bytestr=1613173568, vector=-2144922656, maxdepth=12)
at bytecode.c:576
#17 0x52830 in funcall_lambda (fun=539432516, nargs=1, arg_vector=0xefffc15c)
at eval.c:3597
#18 0x5185c in funcall_recording_as (recorded_as=-1607493972, nargs=1,
args=0xefffc158) at eval.c:3214
#19 0x518d0 in Ffuncall (nargs=2, args=0xefffc158) at eval.c:3238
#20 0x272dc in Fbyte_code (bytestr=1615954236, vector=-2142142976, maxdepth=93)
at bytecode.c:416
#21 0x52830 in funcall_lambda (fun=541570204, nargs=1, arg_vector=0xefffc564)
at eval.c:3597
#22 0x5185c in funcall_recording_as (recorded_as=-1606527652, nargs=1,
args=0xefffc560) at eval.c:3214
#23 0x518d0 in Ffuncall (nargs=2, args=0xefffc560) at eval.c:3238
#24 0x272dc in Fbyte_code (bytestr=1615146980, vector=-2144242368, maxdepth=33)
at bytecode.c:416
#25 0x52830 in funcall_lambda (fun=541569112, nargs=3, arg_vector=0xefffc8ec)
at eval.c:3597
#26 0x5185c in funcall_recording_as (recorded_as=-1606037724, nargs=3,
args=0xefffc8e8) at eval.c:3214
#27 0x518d0 in Ffuncall (nargs=4, args=0xefffc8e8) at eval.c:3238
#28 0x272dc in Fbyte_code (bytestr=1615146560, vector=-2142828320, maxdepth=5)
at bytecode.c:416
#29 0x52830 in funcall_lambda (fun=541569140, nargs=1, arg_vector=0xefffcb84)
at eval.c:3597
#30 0x5185c in funcall_recording_as (recorded_as=541569140, nargs=1,
args=0xefffcb80) at eval.c:3214
#31 0x52e50 in call1 (fn=541569140, arg0=-1605666404) at eval.c:3238
#32 0xafc38 in mapcar1 (leni=13, vals=0xefffccb0, fn=541569140, seq=1078303572)
at fns.c:3237
#33 0xafda8 in Fmapcar (fn=541569140, seq=1078303572) at fns.c:3287
#34 0x51600 in funcall_recording_as (recorded_as=-1607490932, nargs=2,
args=0xefffcf88) at eval.c:3197
#35 0x518d0 in Ffuncall (nargs=3, args=0xefffcf88) at eval.c:3238
#36 0x272dc in Fbyte_code (bytestr=1615146620, vector=-2142828192, maxdepth=4)
at bytecode.c:416
#37 0x52830 in funcall_lambda (fun=541569168, nargs=2, arg_vector=0xefffd138)
at eval.c:3597
#38 0x52238 in apply_lambda (fun=541569168, numargs=2,
unevalled_args=-1607585788) at eval.c:3501
#39 0x50f0c in Feval (form=1077089228) at eval.c:3085
#40 0x527dc in funcall_lambda (fun=1077088980, nargs=0, arg_vector=0xefffd674)
at eval.c:758
#41 0x5185c in funcall_recording_as (recorded_as=-1606037796, nargs=0,
args=0xefffd670) at eval.c:3214
#42 0x518d0 in Ffuncall (nargs=1, args=0xefffd670) at eval.c:3238
#43 0x272dc in Fbyte_code (bytestr=1612944928, vector=-2145151428, maxdepth=8)
at bytecode.c:416
#44 0x52830 in funcall_lambda (fun=539203144, nargs=1, arg_vector=0xefffddc4)
at eval.c:3597
#45 0x5185c in funcall_recording_as (recorded_as=-1606879980, nargs=1,
args=0xefffddc0) at eval.c:3214
#46 0x518d0 in Ffuncall (nargs=2, args=0xefffddc0) at eval.c:3238
#47 0x272dc in Fbyte_code (bytestr=1612951528, vector=-2145144480,
maxdepth=142) at bytecode.c:416
#48 0x52830 in funcall_lambda (fun=539210516, nargs=0, arg_vector=0xefffe2cc)
at eval.c:3597
#49 0x5185c in funcall_recording_as (recorded_as=-1606879380, nargs=0,
args=0xefffe2c8) at eval.c:3214
#50 0x518d0 in Ffuncall (nargs=1, args=0xefffe2c8) at eval.c:3238
#51 0x272dc in Fbyte_code (bytestr=1612949108, vector=-2145147112, maxdepth=84)
at bytecode.c:416
#52 0x52830 in funcall_lambda (fun=539207644, nargs=0, arg_vector=0xefffe8dc)
at eval.c:3597
#53 0x5185c in funcall_recording_as (recorded_as=-1606879596, nargs=0,
args=0xefffe8d8) at eval.c:3214
#54 0x518d0 in Ffuncall (nargs=1, args=0xefffe8d8) at eval.c:3238
#55 0x272dc in Fbyte_code (bytestr=1612946940, vector=-2145149188,
maxdepth=165) at bytecode.c:416
#56 0x52830 in funcall_lambda (fun=539205852, nargs=0, arg_vector=0xefffea98)
at eval.c:3597
#57 0x52238 in apply_lambda (fun=539205852, numargs=0,
unevalled_args=-1607585788) at eval.c:3501
#58 0x50f0c in Feval (form=1077462780) at eval.c:3085
#59 0x4dc88 in condition_case_1 (handlers=-1607585692, bfun=0x50554 <Feval>,
barg=1077462780, hfun=0x311c8 <cmd_error>, harg=-1607585788) at eval.c:1653
#60 0x31254 in top_level_1 (dummy=-1607585788) at cmdloop.c:206
#61 0x4da6c in internal_catch (tag=-1607507868, func=0x3121c <top_level_1>,
arg=-1607585788, threw=0x0) at eval.c:1328
#62 0x308ac in initial_command_loop (load_me=201244) at cmdloop.c:285
#63 0x4a720 in xemacs_21_0_sparc_sun_solaris2_5_1 (argc=11, argv=0xeffff1a4,
envp=0xeffff1d4, restart=0) at emacs.c:1702
#64 0x4ae78 in main (argc=0, argv=0xeffff1a4, envp=0xeffff1d4) at emacs.c:2119
(gdb) q
--
Dan Rich <drich(a)cisco.com> | http://www.employees.org/~drich/
Tech. Lead, Web Infr. Team | "Danger, you haven't seen the last of me!"
Cisco Systems, Inc. | "No, but the first of you turns my stomach!"
(408) 527-3195 | -- The Firesign Theatre's Nick Danger
Come see me in Oliver! -- http://www.sunnyvaleplayers.org/
- 1 participants
- 0 comments
Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() )
26 years, 3 months
Hrvoje Niksic
Hrvoje Niksic
Gary.Foster(a)Corp.Sun.COM (Gary D. Foster) writes:
> This talk of only supporting linux disturbs me deeply. I cannot
> possibly believe that anyone is seriously considering this?
Noone is. It was Karl's momentary lapse of reason, as far as I'm
concerned.
> I use linux on my laptop and I use solaris everywhere else. I like
> linux, I like what it's done for the Unix community in general.
> What I _don't_ like about linux is when I see all these pieces of
> software come out that are written specifically for it without even
> a nod towards portability. I get _really_ annoyed when I see that
> someone has written a really nifty utility or tool or front-end or
> whatever and it's riddled through with linux-isms which end up
> making it difficult (if not downright impossible) to port to any
> other unix. A perfect example for this is some of the graphical
> front-ends to cdrom burning software. I end up using the
> command-line tools because the GUI front-ends _to_ the command line
> tools were written in such a way as to make it impossible to compile
> on any other platform without a complete rewrite. It's ironic that
> the underlying tools that these rely on are well-written
> cross-platform apps while the stupid FRONT END tools which do
> nothing but feed the cross-platform CLI's are not.
>
> Linux-centrism is JUST as bad as microsoft-centrism or
> solaris-centrism or anything-else-centrism.
I agree 100% with all you've said.
I wonder what will the cool-os-of-the-year be in a few years, and if
everyone will end up writing non-portable code for it. I guess people
never learn.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Try to use "ad nauseam" at least once per flame. It doesn't mean
anything; but it gives that polished feel to your postings.
- 1 participants
- 0 comments
Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() )
26 years, 3 months
Mike Scheidler
Mike Scheidler
"sb" == SL Baur <steve(a)xemacs.org> writes:
sb>
>>> A year or so from now, if things keep going the way they have been,
>>> nearly all of our users will be on either Linux or some flavor of
>>> Microsoft Windows. Linux has been the most popular Unix to run XEmacs
>>> on[1] since 19.14.
sb>
>> I don't believe that's true. :-(
sb>
sb> The statement is absolutely true under the condition given in the
sb> footnote:
sb>
>>> Footnotes:
>>> [1] With regards to counts of downloads of binary kits from the FTP site.
You can't dispute raw numbers, but I don't think this is an accurate usage
indicator. I'd venture that most of the non-Linux binary kit downloads are
used by more than one person (does an average of 10 sound reasonable?),
while most Linux downloads are single-user.
>> I really like Linux, but most larger installations (universities or
>> companies) use a 'commercial' Unix.
That's definitely true. No matter how good Linux is or will become, large
corporations will go commercial every time. It's one thing to use free
software for utilities, but it's an entirely different story when you're
talking about the OS.
As for the portability issue mentioned at the start of this thread, I've
already run into problems with some other packages, and it's pretty
frustrating when you're on the wrong end of it. A while back I was looking
for a music CD player to run on our HPUX machines and most of what I found
was Linux-only. Besides containing hardware-specific code, there were
unconditional hardcoded references to linux/* header files--not a chance of
making it work. I realize that most of the people developing packages such
as this are doing so with Linux as the only available platform, but it
really limits the "market" for their end product. Maybe they don't really
care, but I think *we* should if we want XEmacs to be available to as many
people as might want to use it.
sb> That's undoubtedly true. How much does it skew the numbers? I don't
sb> know. The number is complicated by the fact that many XEmacs users
sb> use it on multiple platforms including Linux at home. Do you count
sb> them twice?
I'd estimate that maybe 10% of the software people I deal with have Linux
at home. Most of them are Prisoners of Bill when they're on their own
time. :-(
sb> I'm vaguely interested in getting an order of magnitude (or two)
sb> count, but not enough to want to invade people's privacy.
I can vouch for my site, whose free software directory is mirrored to
selected General Motors and Delphi Automotive sites around the world. A
couple of months ago I put an invocation wrapper around XEmacs to log usage
and counted 275 different users over a 2 week period. These people are all
using SunOS and HPUX binaries I built and installed from the source
distribution.
--
Mike Scheidler c23mts(a)eng.delcoelect.com
Corporate Software Technology
Delphi Delco Electronics Systems PHONE: (765) 451-0319
Kokomo, IN 46904-9005 GMNET: 8-322-0319
- 2 participants
- 1 comments
isearch bug
26 years, 3 months
Greg Klanderman
Greg Klanderman
when searching backwards, isearch mode does not properly switch into
non case-folding mode:
xemacs -vanilla
insert "fooBar" into the buffer and move above it.
C-s f o o B -> switches from `Isearch' to `ISeARch'
move past 'fooBar':
C-r f o o B -> still in `Isearch' (case folding) mode
greg
btw, if someone out there really understands this isearch code
it would be really nice to fix the history mechanism.
- 1 participants
- 0 comments
Re: Proposal: defface.d
26 years, 3 months
Greg Klanderman
Greg Klanderman
>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes:
sb>
sb> Karl M Hegbloom <karlheg(a)inetarena.com> writes in xemacs-beta(a)xemacs.org:
>> What if we pulled the defface stuff out of everything, made them into
>> separate files, and had each package drop that defface file into a
>> directory, like:
sb>
sb> How much of a problem is this really?
I don't think it is. Some time ago I was trying to figure out where
all my color cells were going (8 bit display). From what I recall, it
seemed that for example the billions of Gnus faces (which I do not use
but are defined in my XEmacs) did not actually cause color cells to be
allocated until they were used.
greg
- 1 participants
- 0 comments
Re: Seppuku and x_IO_error_handler()
26 years, 3 months
Gunnar Evermann
Gunnar Evermann
SL Baur <steve(a)xemacs.org> writes:
> Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in xemacs-beta(a)xemacs.org:
>
> > SL Baur <steve(a)xemacs.org> writes:
> >>
> >> A year or so from now, if things keep going the way they have been,
> >> nearly all of our users will be on either Linux or some flavor of
> >> Microsoft Windows. Linux has been the most popular Unix to run XEmacs
> >> on[1] since 19.14.
>
> > I don't believe that's true. :-(
>
> The statement is absolutely true under the condition given in the
> footnote:
indeed, sorry.
I answered before my caffeine level reached normal operating levels.
speaking of footnotes -- Didier posted a file called
'footnote-balloons' a couple of days ago. This pops up a balloon-help
when the mouse is over a footnote. This is really cool. Can/should this be
included in your footnote-package?
Gunnar
--
Gunnar Evermann
Natural Language Systems Group, University of Hamburg
EMail: Gunnar.Evermann(a)nats.informatik.uni-hamburg.de
- 1 participants
- 0 comments
Re: Seppuku and x_IO_error_handler()
26 years, 3 months
SL Baur
SL Baur
[Dirk, in response to a previous unanswered question, we're dancing as
fast as we can. XEmacs 21.0 is almost ready for release but not quite
and we're hopeful to get it out soon. When will XFree86-4.0 be out? :-)]
Rick Campbell <campbell(a)cyberpass.net> writes in xemacs-beta(a)xemacs.org:
> From: SL Baur <steve(a)xemacs.org>
> Date: 30 Aug 1998 15:38:50 -0700
> Karl M Hegbloom <karlheg(a)inetarena.com> writes in xemacs-beta(a)xemacs.org:
>> Since X won't be free anymore,
> . . .
> XFree86 is committed to keeping a free version of X11.[1]
> . . .
> [1] http://sunsite.doc.ic.ac.uk/XFree86/news/pr-980407.html
> I didn't see anything at this URL that explicitly stated that they are
> now supporting platforms other than Intel *86, although it's suggested
> implicitly as the X11R6.3 SI supports other platforms.
> Have your contacts with them included any explicit discussion of other
> platforms?
I corresponded with Dirk Hohndel who was courteous and helpful and to
whom this message is cc'ed. I did not ask about OS variants because
that wasn't the issue at the time.
I reiterate my previous statement -- the XFree86 folks are the Good
Guys. They deserve our support. Just because past releases of theirs
has concentrated on free OS'es, doesn't mean their distribution is any
less portable than (what used to be) the base X11. Have you tried
building XFree86 on your target system? I've built and installed both
`vanilla' X11R4 and X11R5 on Suns and HPs and XFree86 installation
from source sure looks the same to me today.
- 2 participants
- 1 comments
Re: Seppuku and x_IO_error_handler()
26 years, 3 months
SL Baur
SL Baur
David, how long do you keep FTP download stats and can give us any
access to the ones pertaining to XEmacs downloads?
Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in xemacs-beta(a)xemacs.org:
> SL Baur <steve(a)xemacs.org> writes:
>> Mauro Condarelli <MC5686(a)mclink.it> writes in xemacs-beta(a)xemacs.org:
>> ...[re supporting non-Linux Unix]
>> > If we;re going to take that stance we will have a lot less problems...
>> > and a lot less users.
>>
>> A year or so from now, if things keep going the way they have been,
>> nearly all of our users will be on either Linux or some flavor of
>> Microsoft Windows. Linux has been the most popular Unix to run XEmacs
>> on[1] since 19.14.
> I don't believe that's true. :-(
The statement is absolutely true under the condition given in the
footnote:
>> Footnotes:
>> [1] With regards to counts of downloads of binary kits from the FTP site.
We don't have any other means of measuring usage. One can take note
of platform specific questions going through comp.emacs.xemacs but I
don't think that's a particularly reliable measure of usage either.
I'm basing my prediction on the rate of change of bug reports per
platform and the rate of change of build reports per platform as well
as the binary kit download stats from UIUC. All of those metrics
show Linux usage increasing exponentially.
Given the known volume of Microsoft Windows hosts and the rate at
which I've seen the XEmacs on Microsoft project grow, I feel safe in
predicting that it will continue to grow quickly.
;; I'm well-aware this can be inaccurate too as some get lax in reporting
;; on systems they are active in testing.
...
> BTW. I don't want to start a Linux vs. 'commercial' Unix flameware.
Neither do I.
> I really like Linux, but most larger installations (universities or
> companies) use a 'commercial' Unix.
That's undoubtedly true. How much does it skew the numbers? I don't
know. The number is complicated by the fact that many XEmacs users
use it on multiple platforms including Linux at home. Do you count
them twice?
I'm vaguely interested in getting an order of magnitude (or two)
count, but not enough to want to invade people's privacy.
- 1 participants
- 0 comments
Re: Pterodactyl Gnus v0.10 is released
26 years, 3 months
Lars Magne Ingebrigtsen
Lars Magne Ingebrigtsen
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> > * rfc2047.el: Renamed file.
> > * gnus-art.el (gnus-article-decode-mime-words): Use 1522.
>
> Won't it be easier to use a name that does not incluse any standard/RFC
> (revision)numbers otherwise you are screwed again if another RFC
> supercedes the current ones? Especially given that, hopefully, the
> mime support will evolve into a general mime library.
RFC1522/RFC2047 define how characters in headers are to be encoded
this week. If someone comes up with a new scheme next week, it would
be not-all-that-nice to have two libraries called
mime-header-encoding.el (or whatever). By clearly stating what each
library does (rfc2047.el encodes according to that RFC), there's less
possibility of confusion. I think.
The 1522/2047 thing is almost purely a cosmetic change, so if
rfc1522.el has already existed, rfc2047.el wouldn't have been
written.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen
- 1 participants
- 0 comments