Re: Installation HOWTO
24 years, 7 months
john s jacobs anderson
john s jacobs anderson
>>>>> "MS" == Michael Sperber <sperber(a)Informatik.Uni-Tuebingen.De> writes:
>>>>> "john" == john s jacobs anderson <jacobs(a)azstarnet.com> writes:
john> also, *BSD/Solaris/other non-RedHat platforms: where do
john> these instructions break on your setup?
MS> Nowhere. However, they should be abstracted over $prefix.
this was done this way on purpose, based on two lines of reasoning:
(1) it's more complicated to explain the whole $prefix issue, and
(2) if you really need to muck with it, you shouldn't need
instructions at this hand-holding level.
Or are you referring specifically to the package install location in
line 7? If so, could you provide specific location/platform pairs?
Then I can make up a table. I am (unfortunately) woefully ignorant of
non-RedHat distros.
MS> Also, they sometimes refer to the version number as "21.1.*",
MS> sometimes as "21.1.6". This should be consistent.
fixed.
MS> I don't understand why we don't have a tarball containing the
MS> .elc and .info files anymore, but that seems to be somebody
MS> else's fault.
not it. 8^)=
thanks; keep 'em comin'.
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)azstarnet.com Journeyman Molecular Biologist
<URL:http://www.azstarnet.com/~jacobs/> <- GeneHack:bioinfo*linux*opinion
- 1 participants
- 0 comments
Re: Installation HOWTO
24 years, 7 months
Michael Sperber
Michael Sperber
>>>>> "john" == john s jacobs anderson <jacobs(a)azstarnet.com> writes:
john> a draft version is available at
john> <URL:http://www.xemacs.org/Install/index.html>
john> please test it out (i.e., pretend you know nothing and try to install
john> based just on what's on that page).
john> also, *BSD/Solaris/other non-RedHat platforms: where do these
john> instructions break on your setup?
Nowhere. However, they should be abstracted over $prefix.
Also, they sometimes refer to the version number as "21.1.*",
sometimes as "21.1.6". This should be consistent.
I don't understand why we don't have a tarball containing the .elc and
.info files anymore, but that seems to be somebody else's fault.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Installation HOWTO
24 years, 7 months
john s jacobs anderson
john s jacobs anderson
a draft version is available at
<URL:http://www.xemacs.org/Install/index.html>
please test it out (i.e., pretend you know nothing and try to install
based just on what's on that page).
also, *BSD/Solaris/other non-RedHat platforms: where do these
instructions break on your setup?
LARTs/critiques/comments to the list(s) or me; your choice.
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)azstarnet.com Journeyman Molecular Biologist
<URL:http://www.azstarnet.com/~jacobs/> <- GeneHack:bioinfo*linux*opinion
- 1 participants
- 0 comments
FTP trouble?
24 years, 7 months
john s jacobs anderson
john s jacobs anderson
There appears to be some issue with ftp.xemacs.org.
Try this:
(1) Open <URL:http://www.xemacs.org/Documentation/index.html>
(2) Click the [letter] link for Programming in...
(3) See 'Can't connect to FTP server' error message
(4) Use Netscape to go to <URL:ftp://ftp.xemacs.org> and navigate to
the file that the above link goes to.
(5) Scratch head. Try again a minute or two later; everything works.
I think someone posted about this early last week, too. I can confirm
that there appears to be an intermittent connection issue.
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)azstarnet.com Journeyman Molecular Biologist
<URL:http://www.azstarnet.com/~jacobs/> <- GeneHack:bioinfo*linux*opinion
- 1 participants
- 0 comments
Time for 21.1.7
24 years, 7 months
Vin Shelton
Vin Shelton
I want to release 21.1.7 this week. I've committed all the patches I
have in hand to CVS. Please take a look and let me know if there's
anything you think I should add. Unless I hear of a good reason, I'll
plan on making the release sometime between Friday and Sunday, so get
your thoughts in early.
If you can't check the CVS archive, here's the list of the message
headers (sorry I haven't tracked down the message numbers from the
mailinglist archives):
To: xemacs-beta(a)xemacs.org
Cc: acs(a)xemacs.org, xemacs-patches(a)xemacs.org
From: Adrian Aichner <aichner(a)ecf.teradyne.com>
Subject: followup patch for 9907/msg00022.html for 21.1.6
Message-ID: <uvhahqmg7.fsf(a)ecf.teradyne.com>
To: Vin Shelton <acs(a)xemacs.org>
Cc: xemacs-beta(a)xemacs.org,
From: Tsukamoto Tetsuo <czkmt(a)remus.dti.ne.jp>
Subject: Re: XEmacs Build Report for XEmacs-21.1.6
Message-ID: <86emh4q5d1.fsf(a)remus.dti.ne.jp>
To: "'xemacs-patches(a)xemacs.org'" <xemacs-patches(a)xemacs.org>
To: 'xemacs-patches(a)xemacs.org'
Cc: "'vroonhof(a)math.ethz.ch'" <vroonhof(a)math.ethz.ch>
From: "Wedler, Christoph" <christoph.wedler(a)sap-ag.de>
From: Wedler, Christoph
Subject: bytecomp.el: wrong warning for `buffer-substring'
Subject: bytecomp.el: wrong warning for `buffer-substring'
Message-ID: <FAFE609CB754D311B60C0008C75D35563BDC73(a)dbwdfx14.wdf.sap-ag.de>
To: xemacs-patches(a)xemacs.org
From: Alexandre Oliva <oliva(a)dcc.unicamp.br>
Subject: Building XEmacs 21.1.6 with SunOS 4.1.3's bundled X11
Message-ID: <or9077ky4g.fsf(a)cupuacu.lsd.dcc.unicamp.br>
To: xemacs-patches(a)xemacs.org
From: sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Subject: GC documentation
Message-ID: <y9laerlp24a.fsf(a)brabantio.informatik.uni-tuebingen.de>
To: xemacs-patches(a)xemacs.org
From: Stef Epardaud <stef(a)lunatech.com>
Subject: compile warnings for man/internals/internals.texi
Message-ID: <19990823121352.A6969(a)tanglefoot.lunatech.com>
To: xemacs-beta(a)xemacs.org
From: rpluim(a)bigfoot.com
Subject: Suggested addition to README.packages
Message-ID: <14274.22304.667656.619177(a)ltrpluim.corpemea.baynetworks.com>
To: XEmacs Patches <xemacs-patches(a)xemacs.org>
From: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: Regions delimiting replacements fix
Message-ID: <876722h3zz.fsf(a)pc-hrvoje.srce.hr>
To: xemacs-patches(a)xemacs.org
From: Adrian Aichner <aichner(a)ecf.teradyne.com>
Subject: Native info support and man cleanup for 21.1.4 "i386-pc-win32"
Message-ID: <u7lo8ls3p.fsf(a)ecf.teradyne.com>
From: burt(a)dfki.de (Alastair Burt)
Subject: Derived Mode Patch
Message-ID: <953-Thu26Aug1999203217+0200-burt(a)dfki.de>
To: xemacs-patches(a)xemacs.org
From: Jan Vroonhof <vroonhof(a)math.ethz.ch>
Subject: Fix for shifted popup menus
Message-Id: <19990827202126.5CAE811085(a)petteflet.dialup.ethz.ch>
To: Vin Shelton <acs(a)xemacs.org>
Cc: Hrvoje Niksic <hniksic(a)srce.hr>,
From: Jan Vroonhof <vroonhof(a)math.ethz.ch>
Subject: Re: Revisited: Bug? - auto-show doesn't take account of minibuf prompt
Message-ID: <by671zwt60.fsf(a)bolzano.math.ethz.ch>
To: XEmacs Patches <xemacs-patches(a)xemacs.org>
From: Andreas Jaeger <aj(a)arthur.rhein-neckar.de>
Subject: Support for Linux-MIPS
Message-ID: <u8btbql2xm.fsf(a)arthur.rhein-neckar.de>
To: xemacs-patches(a)xemacs.org
Cc: Jan Vroonhof <jan(a)xemacs.org>
From: Robert Pluim <rpluim(a)bigfoot.com>
Subject: Re: Suggested addition to README.packages
Message-ID: <14282.18364.943364.114946(a)ltrpluim.corpemea.baynetworks.com>
To: xemacs-patches(a)xemacs.org
Cc: jareth(a)camelot-soft.com
From: Lee Kindness <lkindness(a)csl.co.uk>
Subject: Handle read/write colorcells in allocate_nearest_color()
Message-ID: <14283.63560.326968.229239(a)gargle.gargle.HOWL>
To: XEmacs Patches <xemacs-patches(a)xemacs.org>
From: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: Fix setf methods for extent-start-position and extent-end-position
Message-ID: <87vh9tcom3.fsf(a)pc-hrvoje.srce.hr>
To: XEmacs Patches <xemacs-patches(a)xemacs.org>
From: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: remprop on extents
Message-ID: <87aer5e2pg.fsf(a)pc-hrvoje.srce.hr>
To: Hrvoje Niksic <hniksic(a)srce.hr>
Cc: XEmacs Patch Reviews <xemacs-review(a)xemacs.org>,
From: Robert Pluim <rpluim(a)bigfoot.com>
Subject: Re: Suggested addition to README.packages
Message-ID: <14291.45086.782948.337411(a)ltrpluim.corpemea.baynetworks.com>
To: xemacs-patches(a)xemacs.org
From: Jan Vroonhof <vroonhof(a)math.ethz.ch>
Subject: allow-remote-paths
Message-Id: <199909071924.VAA21691＠bolzano>
To: andyp(a)beasys.com, xemacs-nt(a)xemacs.org, xemacs-patches(a)xemacs.org
From: jback(a)rudd.compulink.co.uk (Julian Back)
Subject: Re: process-environment (1/1)
Message-Id: <memo.19990909233103.21721B(a)jback.compulink.co.uk>
To: James LewisMoss <dres(a)ioa.com>
Cc: xemacs-patches(a)xemacs.org
From: sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Subject: Re: docdir [21.1 also]
Message-ID: <y9ln1uto9mr.fsf(a)brabantio.informatik.uni-tuebingen.de>
To: xemacs-review(a)xemacs.org
From: James LewisMoss <dres(a)ioa.com>
Subject: Re: debian patch to xemacs
Message-ID: <hhemg3uly8.fsf(a)dres.lewismoss.org>
To: XEmacs Patches <xemacs-patches(a)xemacs.org>
From: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: Fix for auto-fill bug
Message-ID: <87g10dbdse.fsf(a)pc-hrvoje.srce.hr>
To: xemacs-patches(a)xemacs.org
From: sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Subject: EMACS_CONFIGURATION must be set to $configuration [21.1 also]
Message-ID: <y9lwvtmu8b3.fsf(a)brabantio.informatik.uni-tuebingen.de>
- vin
- 1 participants
- 0 comments
Re: Gnuserv fix
24 years, 7 months
Michael Harnois
Michael Harnois
I am still getting the random crashes with this patch applied.
However, now I get the message
Error: Object "(null)" does not have windowed ancestor
--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org
There are three steps in the revelation of any truth: in the
first, it is ridiculed; in the second, resisted; in the
third, it is considered self-evident. -- Arthur Schopenhauer
- 1 participants
- 0 comments
core dump
24 years, 7 months
Georg Nikodym
Georg Nikodym
This may be my beta X libs, but with latest CVS I got:
Lisp backtrace follows:
# (condition-case ... . error)
# (unwind-protect ...)
read-minibuffer-internal("Complete attribution name: ")
byte-code("..." [recursion-depth minibuffer-depth t standard-input standard-output read-minibuffer-internal prompt] 2)
# (catch exit ...)
# bind (mouse-grabbed-buffer current-prefix-arg minibuffer-history-variable minibuffer-history-position minibuffer-scroll-window)
# (unwind-protect ...)
# bind (_history_ oconfig mconfig frame buffer window oframe owindow dir abbrev-table history readp keymap initial-contents prompt)
read-from-minibuffer("Complete attribution name: " "JT" #<keymap 9 entries 0xf660> nil nil)
# bind (minibuffer-completion-table minibuffer-completion-predicate minibuffer-completion-confirm last-exact-completion ret default history initial-contents require-match predicate table prompt)
completing-read("Complete attribution name: " (("Jerzy") ("Terlecki") ("Jerzy") ("JT")) nil nil "JT")
# bind (history initial-contents require-match predicate table prompt)
sc-completing-read("Complete attribution name: " (("Jerzy") ("Terlecki") ("Jerzy") ("JT")) nil nil ("JT" . 0) sc-attribution-confirmation-history)
byte-code("..." [sc-attrib-or-cite sc-read-string "Enter citation prefix: " citation sc-citation-confirmation-history sc-completing-read "Complete attribution name: " query-alist nil initial 0 sc-attribution-confirmation-history choice ""] 7)
# (catch sc-reconfirm ...)
# bind (choice completer-disable initial minibuffer-local-map minibuffer-local-completion-map query-alist query-p attribution citation attriblist)
sc-select-attribution()
# bind (mark point mark-active zmacs-regions)
sc-cite-original()
run-hooks(sc-cite-original)
# (unwind-protect ...)
# bind (b start end message)
vm-yank-message([[#<marker at 11762421 in INBOX 0x179376c> #<marker at 11762484 in INBOX 0x1793784> #<marker at 11763602 in INBOX 0x17a88dc> #<marker at 11763784 in INBOX 0x17a9d14> #<marker at 11763878 in INBOX 0x17684b4> #<marker at 11763878 in INBOX 0x176855c>] ["1240" "1240" nil #<marker at 101376 in INBOX Summary 0x16c3fcc> #<marker at 101439 in INBOX Summary 0x176801c> <<>> <-- From_-with-Content-Length "1250" #<buffer "INBOX"> 0 (<199909161844\.OAA07934(a)phobe\.canada\.sun\.com>) nil nil nil nil [... ... "7bit" nil nil nil nil #<marker at 11762484 in INBOX 0x179849c> #<marker at 11763784 in INBOX 0x1798634> #<marker at 11763878 in INBOX 0xb5aaa4> nil nil <<m>> nil] none #<extent (101376, 101439) H 0x15cabf4 in buffer INBOX Summary>] [nil nil nil nil nil nil nil nil nil] ["94" "Thursday" "16" "September" "1999" "14:44:12" "-0400" "Jerzy Terlecki -- Customer Engineering" "jerzy(a)opcom-mail.canada.sun.com" "<199909161844.OAA07934(a)phobe.canada.sun.com>" "6" "Great Emacs" "^From:" nil nil "9" "1999091618:44:12" "Great Emacs" (number " " mark " Jerzy Terlecki -- Sep 16 6/94 " thread-indent "\"Great Emacs\"\n") nil nil] [nil <v> t nil nil]])
# (unwind-protect ...)
# (unwind-protect ...)
# bind (mlist dir message-pointer case-fold-search to cc subject mp in-reply-to references tmp tmp2 newsgroups count include-text to-all)
vm-do-reply(nil t 1)
# bind (count)
vm-reply-include-text(1)
# bind (command-debug-status)
call-interactively(vm-reply-include-text)
# (condition-case ... . error)
# (catch top-level ...)
[1] + Segmentation Fault(coredump)xemacs &
(verve) 1275$ dbx $(whence xemacs) core
Reading xemacs
core file header read successfully
Reading ld.so.1
Reading libXm.so.4
Reading libpng.so.2
Reading libXpm.so.4.6
Reading libDtSvc.so.1
Reading libtt.so.2
Reading libXmu.so.4
Reading libXt.so.4
Reading libXext.so.0
Reading libX11.so.4
Reading libdl.so.1
Reading libncurses.so.4
Reading libldap.so.3
Reading libm.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libgen.so.1
Reading libc.so.1
Reading libz.so
Reading libSM.so.6
Reading libICE.so.6
Reading libresolv.so.2
Reading libmp.so.2
Reading libc_psr.so.1
program terminated by signal SEGV (Segmentation Fault)
Current function is fatal_error_signal
276 kill (getpid (), fatal_error_code);
(verve:dbx) 1$ where
[1] _libc_kill(0x0, 0xb, 0x0, 0x0, 0x20c10, 0x13947c), at 0xfec1dc94
=>[2] fatal_error_signal(sig = 11), line 276 in "emacs.c"
[3] sigacthandler(0xb, 0x0, 0xffbeb078, 0x0, 0x0, 0xffbeb3d1), at 0xfec1cd58
---- called from signal handler with signal 11 (SIGSEGV) ------
[4] XtMoveWidget(0x43, 0x4, 0x0, 0xfef66000, 0x16cff00, 0x29), at 0xfef3e0b8
[5] x_map_subwindow(p = 0x1758600, x = 4, y = 41), line 2057 in "glyphs-x.c"
[6] map_subwindow(subwindow = UNION, x = 4, y = 41), line 3999 in "glyphs.c"
[7] redisplay_output_subwindow(w = 0x1a0ec00, image_instance = UNION, db = 0xffbeb5e0, dga = 0xffbeb5d0, findex = 4U, cursor_start = 0, cursor_width = 0, cursor_height = 0), line 1168 in "redisplay-output.c"
[8] x_output_display_block(w = 0x1a0ec00, dl = 0x1758f80, block = 0, start = 0, end = 1, start_pixpos = 4, cursor_start = 0, cursor_width = 0, cursor_height = 0), line 485 in "redisplay-x.c"
[9] redisplay_output_display_block(w = 0x1a0ec00, dl = 0x1758f80, block = 0, start = 0, end = 1, start_pixpos = 4, cursor_start = 0, cursor_width = 0, cursor_height = 0), line 1043 in "redisplay-output.c"
[10] output_display_line(w = 0x1a0ec00, cdla = 0xeec260, ddla = 0x197b840, line = 0, force_start = -1, force_end = -1), line 711 in "redisplay-output.c"
[11] output_gutter(f = 0x1a0e200, pos = TOP_GUTTER), line 252 in "gutter.c"
[12] update_frame_gutters(f = 0x1a0e200), line 345 in "gutter.c"
[13] redisplay_frame(f = 0x1a0e200, preemption_check = 0), line 6325 in "redisplay.c"
[14] redisplay_device(d = 0x87ff00), line 6482 in "redisplay.c"
[15] redisplay_without_hooks(), line 6565 in "redisplay.c"
[16] redisplay(), line 6635 in "redisplay.c"
[17] Fnext_event(event = UNION, prompt = UNION), line 2236 in "event-stream.c"
[18] Fcommand_loop_1(), line 569 in "cmdloop.c"
[19] command_loop_1(dummy = UNION), line 493 in "cmdloop.c"
[20] condition_case_1(handlers = UNION, bfun = 0xe0340 = &`xemacs`cmdloop.c`command_loop_1(Lisp_Object dummy), barg = UNION, hfun = 0xdf0a0 = &`xemacs`cmdloop.c`cmd_error(Lisp_Object data, Lisp_Object dummy), harg = UNION), line 1646 in "eval.c"
[21] command_loop_3(), line 255 in "cmdloop.c"
[22] command_loop_2(dummy = UNION), line 266 in "cmdloop.c"
[23] call_command_loop(catch_errors = UNION), line 327 in "cmdloop.c"
[24] Fread_minibuffer_internal(prompt = UNION), line 188 in "minibuf.c"
[25] Ffuncall(nargs = 2, args = 0xffbec0bc), line 3195 in "eval.c"
[26] execute_optimized_program(program = 0xffbec1e8 "\xc0 \xc1 V\xab^K\xc2\x89^[^\\xc5^N^F!*\x87\xc5^N^F!\x87\xc2^\", stack_depth = 2, constants_data = 0x779f10), line 747 in "bytecode.c"
[27] Fbyte_code(instructions = UNION, constants = UNION, stack_depth = UNION), line 2406 in "bytecode.c"
[28] Feval(form = UNION), line 2992 in "eval.c"
[29] internal_catch(tag = UNION, func = 0x14ea00 = &Feval(Lisp_Object form), arg = UNION, threw = (nil)), line 1321 in "eval.c"
[30] execute_rare_opcode(stack_ptr = 0xffbec524, program_ptr = 0xa9c180 "\xe6a\xab^L\x81H", opcode = Bcatch), line 1253 in "bytecode.c"
[31] execute_optimized_program(program = 0xa9c010 "^H\xac^R\xc1 \xc2V\xab^L\xc3 \xc4 a\xab^E\xc5\xc6!\x88^N^G\xab^Q^N^G\xc2V\xab^K\xc1 ^N^GY\xab^D\xc8 \x88^N^I\xab"^N^I9\xab^O\xca^N^I!\xac^W\xc5\xcb^N^I"\x88\xaa^O\xca^N^I＠!\xac^H\xc5\xcb^N^I＠"\x88\xcc \xab^I\xcd\xce\xcf^N^P!"\x88^N^Q^^^R\xc3 ^^^S\xd4 ^^^U\xc4 ^^^V\xc1 \xc2a\xab^G\xd7^N^V!\xaa^H\xd8\xd9\xda\xc1 "!^^^[\xdc^N^V!\x89^^^]\xd4 a?\xad^E\xde^N^]!^^^_\xde ^^ ^N^I^^!\xe2\x8e\xe3^N^[!q\x88^N^R^V^Q\xe4\xe5!\x88\xe6^V%\xe4\xe7!\x88\xe4\xe8!\x88\xe4\xe9!\x88\xea^V'\xeb^V(^N,\xab^U\xe4\xed!\x88^N-\xac^D\xee^V-\xe4\xef!\x88\xf0\xef\xf1"\x88\xf2^N^V^N^["\x88\xf3^N^V!\x88\xf4^N^V\xc2"\x88\xf5^N^[!\x88\xcd\xf6!\x88^N7\xab(^N7:\xab^X^N7＠c\x88^N7ATb\x88^N7＠^V'^N7A^V(\xaa^L^N7c\x88^N7^V'`^V(\xf8\xf9^N:\xae^C^N;^N<"!\x88^N,\xad^Bp^N=^N!\xac^D\xfe\xaa^M^N!:\xab^F^N!＠\xaa^C^N!^N!:\xab^F^N!A\xaa^B\xc2^N^S^^?^^＠^^A^^=^^B^N＠^V)^NC\xab^H^NC^VD\xe6^VE\x81F", stack_depth = 6, constants_data = 0x71b210), line 657 in "bytecode.c"
[32] funcall_compiled_function(fun = UNION, nargs = 5, args = 0xffbec838), line 523 in "bytecode.c"
[33] Ffuncall(nargs = 6, args = 0xffbec834), line 3227 in "eval.c"
[34] execute_optimized_program(program = 0xb4f410 "^H^I\n\xc3a?\xad^B\xc3\xc4\x89^]^^^F^^^G^^^H^^^I\xca^N^K^N^L\n\xac^E^N^M\xaa^C^N^N\xc4^N^O%\x89^U\xd0\x98\xab^I^N^Q\xab^E^N^Q\xaa^B^M-\x87\xdc", stack_depth = 7, constants_data = 0x77be90), line 747 in "bytecode.c"
[35] funcall_compiled_function(fun = UNION, nargs = 5, args = 0xffbecb48), line 523 in "bytecode.c"
[36] Ffuncall(nargs = 6, args = 0xffbecb44), line 3227 in "eval.c"
[37] execute_optimized_program(program = 0x9bfcd0 "\xc0^Is\xab^N\xc2^K^L^M^N^F^N^G^N^H&^F\x87\xc2^K^L^M^N^F^N^G\xa2\xae^C^N^G%\x87b\xd8^D", stack_depth = 7, constants_data = 0x19e0510), line 747 in "bytecode.c"
[38] funcall_compiled_function(fun = UNION, nargs = 6, args = 0xffbece58), line 523 in "bytecode.c"
[39] Ffuncall(nargs = 7, args = 0xffbece54), line 3227 in "eval.c"
[40] execute_optimized_program(program = 0xffbecf90 "^H\xab^H\xc1\xc2^K\xc4#\xaa^N\xc5\xc6^N^G\xc8\x89^N^I\xcaB\xcb&^F\x89^V^L\xcd\x98\x87", stack_depth = 7, constants_data = 0x1671e90), line 747 in "bytecode.c"
[41] Fbyte_code(instructions = UNION, constants = UNION, stack_depth = UNION), line 2406 in "bytecode.c"
[42] Feval(form = UNION), line 2992 in "eval.c"
[43] internal_catch(tag = UNION, func = 0x14ea00 = &Feval(Lisp_Object form), arg = UNION, threw = (nil)), line 1321 in "eval.c"
[44] execute_rare_opcode(stack_ptr = 0xffbed2dc, program_ptr = 0xf838e1 "\xac\xfc^N(\xab^Q^N'^V^F\xeb^N^F!\xae^C^N^F^V^G\xaa^K\xdc^N'!^V^F^N'^V^G.^F^N,\xab^K^N^F\x97^V^F^N^G\x97^V^G\xed^^.\xef^^0\xd2^N.^N1"^^2\xd2^N0^N1"^^3^N2\xab^I^N2^N^F\xa1\x88\xaa^M\xf4^N.^N^FBC^N1"^V1^N3\xab^I^N3^N^G\xa1\x88\xaa^M\xf4^N0^N^GBC^N1"^V1,\xd5^^5\xd2^N5^N^S"\x89^^6\xab^H^N6^N^G\xa1\xaa^L^N5^N^GB^N^SB\x89^V^S.^F\x87\xd4", opcode = Bcatch), line 1253 in "bytecode.c"
[45] execute_optimized_program(program = 0xf83810 "\xc0\xc1!\x88\n\xc3\x89^L^]^^^F^^^G^^^H^M\xabR^M＠\x89^^^I\xca\x98\xab3\xcb^N^L!\x89^^^M\xac^F^MA^U\xaa"^N^M;\xab^I^N^M^V^G\xc3^U\xaa^U^N^M<\xab^K\xce^N^M!^V^G\xc3^U\xaa^F\xcf\xd0\xd1"\x88)\xaa^T\xd2^N^I^N^S"A\x89^V^G\xab^E\xc3^U\xaa^D^MA^U)\xaa\xad^N^G\xac3^N^T\xac/\xd2\xd5^N^S"A\xae%\xd2\xd6^N^S"A\xae^]\xd2\xd7^N^S"A\xae^U\xd2\xd8^N^S"A\xae^M\xd2\xd9^N^S"A\xae^E^N^S＠A^V^G^N^G\xac^H^N^Z^V^G\xdb^V^H\xdc^N^G!^V^F\xc0\xdd!\x88^N^H\xabB\xde\xdf^N^S"^^ ^N!^^"^N#^^$^N^G^^%\xdb^^&\xc3^^'\xc3^V(\xe9\xea\x8d\xac\xfc^N(\xab^Q^N'^V^F\xeb^N^F!\xae^C^N^F^V^G\xaa^K\xdc^N'!^V^F^N'^V^G.^F^N,\xab^K^N^F\x97^V^F^N^G\x97^V^G\xed^^.\xef^^0\xd2^N.^N1"^^2\xd2^N0^N1"^^3^N2\xab^I^N2^N^F\xa1\x88\xaa^M\xf4^N.^N^FBC^N1"^V1^N3\xab^I^N3^N^G\xa1\x88\xaa^M\xf4^N0^N^GBC^N1"^V1,\xd5^^5\xd2^N5^N^S"\x89^^6\xab^H^N6^N^G\xa1\xaa^L^N5^N^GB^N^SB\x89^V^S.^F\x87\xd4", stack_depth = 5, constants_data = 0xf00410), line 657 in "bytecode.c"
[46] funcall_compiled_function(fun = UNION, nargs = 0, args = 0xffbed5e8), line 523 in "bytecode.c"
[47] Ffuncall(nargs = 1, args = 0xffbed5e4), line 3227 in "eval.c"
[48] execute_optimized_program(program = 0x1941710 "\xc0\xc1!\x88\n\xab^F\xc3\n^L"\x88\xc5\xc6N\xac^K\xc7\xc5\xc6\x89#\x88\xc8^MB^U\xc9^V^F\xca \x88\xcb \x88\xcc^^^M\xc9^^^N\xcf ^^^P\xd1\xd2 !\x89^^^S^N^PW\xab^N^N^P^^^T^N^S^V^P^N^T^V^S)\xd5^N^P^N^S"\x88\xd6\xd7\xd8!\xae^N\xd7\xd9!\xae^I\xd7\xda!\xae^D\xd7\xdb!!\x88\xdc \x88\xdd^N^P^N^S"^^^^^N^_\xab<^N^_\xa7\xab^H^N^^^N^_X\xab%\xe0^N^P^N^S"\x88^N^Pb\x88^N!\xae^B\xe2^^#^N$\xab^H\xe5^N#!\x88\xaa^E\xe6\xc9!\x88)\xaa^L\xe7 \x88\xe8\xe9^N^^^N^_#\x88)^N^P\xcc\x89\x93\x88^N^S\xcc\x89\x93\x88,\xc0\xea!\x88\xca \x87", stack_depth = 5, constants_data = 0x1941410), line 747 in "bytecode.c"
[49] funcall_compiled_function(fun = UNION, nargs = 0, args = 0xffbedb8c), line 523 in "bytecode.c"
[50] Ffuncall(nargs = 1, args = 0xffbedb88), line 3227 in "eval.c"
[51] run_hook_with_args_in_buffer(buf = 0x1a0ea00, nargs = 1, args = 0xffbedb88, cond = RUN_HOOKS_TO_COMPLETION), line 3678 in "eval.c"
[52] run_hook_with_args(nargs = 1, args = 0xffbedb88, cond = RUN_HOOKS_TO_COMPLETION), line 3691 in "eval.c"
[53] Frun_hooks(nargs = 1, args = 0xffbedb88), line 3545 in "eval.c"
[54] Ffuncall(nargs = 2, args = 0xffbedb84), line 3213 in "eval.c"
[55] execute_optimized_program(program = 0x19cde10 "\xc0^I!\xac^E\xc2\xc3!\x88\xc4^I!\xac^K\xc2\xc5^N^F\xc7H\xc8H"\x88\xc9\xca\x89\xcb\xcc$\x88^N^F\xc7H\xcdHJ^V^Fp`\xca^^^N^^^O^^^P\x8c~\x88\x8a\xd1\xd2^N^F!!\x83\xa0", stack_depth = 6, constants_data = 0x1941d10), line 747 in "bytecode.c"
[56] funcall_compiled_function(fun = UNION, nargs = 1, args = 0xffbede98), line 523 in "bytecode.c"
[57] Ffuncall(nargs = 2, args = 0xffbede94), line 3227 in "eval.c"
[58] execute_optimized_program(program = 0x1791c10 "\xc0^I!\n^K\xc4\xc5\x89\x89\x89\x89\x89\x89\x89\x89^^^F^^^G^^^H^^^I^^\n^^^K^^^L^^^M^^^N^^^O^^^P^^^Q\x89^^^R\x89^V^K\x83E^A^N^R^N^K=\xabx\xd3^N^K＠\xd4\xd5#^^^V\xd7^N^V!?\xad^C^N^V)\x89^V^N\xac^[\xd3^N^K＠\xd8\xd5#\x89^V^N\xac^O\xd9^N^K＠!\x89^V^N\xac^E\xda\xdb!\x88\xd3^N^K＠\xdc"^V^L^N^]\xad^L\xc5^^^^\xdf^N^]^N^K＠")\x89^V\n\xe0\x9a?\xad^C^N\n^V\n^N^L\xabc^N!;\xab^\xc4^^^O\xe2\xe3^N!!^N^L"\xe4\x9a)\xacN^N!^N^LP^V^L\xaaE\xd3^N^K＠\xd4\xd5#\x89^V^H\xab^K^N^N\xe5^N^HQ^V^N\xaa/\xd3^N^K＠\xd8\xd5#\x89^V^H\xab^K^N^N\xe5^N^HQ^V^N\xaa^Y\xd9^N^K＠!\x89^V^H\xab^K^N^N\xe5^N^HQ^V^N\xaa^E\xda\xdb!\x88^N&\xab?\xd3^N^K＠\xe7\xd5#^V^H\xd3^N^K＠\xe8\xd5#^V^G^N^H\xab^S^N^M\xab^K^N^M\xe5^N^HQ^V^M\xaa^E^N^H^V^M^N^G\xab^S^N^M\xab^K^N^M\xe5^N^GQ^V^M\xaa^E^N^G^V^M\xd3^N^K＠\xe9\xea#\xae^H\xd3^N^K＠\xeb\xea#\xd3^N^K＠\xec\xea#^N^IBB^V^I^N&\xab\n\xd3^N^K＠\xed\xe5#\xae^H\xd3^N^K＠\xee\xe5#^N^FB^V^F^N^KA\x89^V^K\x84\xbf\xfe^N/\xab^Y\xc4^^0^N^N\xab^G\xf1^N^N!^V^N^N^M\xab^G\xf1^N^M!^V^M)\xf2^N^N!^V^N\xf2^N^M!^V^M^N3\xab^M\xf4^N^N!^V^N\xf4^N^M!^V^M\xf5^N^N\xc5\xc4#^V^N\xf5\xf6\xf5^N^M\xc5\xc4#^N^N\xf7^N^N!#\xc4\x89#^V^M^N^N\xab^I\xf8\xf9^N^N\xfa#^V^N^N^M\xab^I\xf8\xf9^N^M\xfa#^V^M^N^N\xac^H^N^M^V^N\xc5^V^M\xfb\xc5^N^I"^V^I\xf8\xf9^N^I\xea#^V^I\xfc^N^I\xfd"^V^I" ..., stack_depth = 14, constants_data = 0x19c3610), line 747 in "bytecode.c"
[59] funcall_compiled_function(fun = UNION, nargs = 3, args = 0xffbee1c8), line 523 in "bytecode.c"
[60] Ffuncall(nargs = 4, args = 0xffbee1c4), line 3227 in "eval.c"
[61] execute_optimized_program(program = 0x167ed50 "\xc0 \x88^I\xab^N\xc2^I!\xac^F\xc3\xc4!\xab^D^Iq\x88\xc5 \x88\xc6 \x88\xc7\xc8\xc9^N\n#\x87%V\x98L", stack_depth = 4, constants_data = 0x19f3250), line 747 in "bytecode.c"
[62] funcall_compiled_function(fun = UNION, nargs = 1, args = 0xffbee4cc), line 523 in "bytecode.c"
[63] Ffuncall(nargs = 2, args = 0xffbee4c8), line 3227 in "eval.c"
[64] Fcall_interactively(function = UNION, record_flag = UNION, keys = UNION), line 946 in "callint.c"
[65] Fcommand_execute(cmd = UNION, record = UNION, keys = UNION), line 2629 in "eval.c"
[66] execute_command_event(command_builder = 0x8756c0, event = UNION), line 4343 in "event-stream.c"
[67] Fdispatch_event(event = UNION), line 4642 in "event-stream.c"
[68] Fcommand_loop_1(), line 578 in "cmdloop.c"
[69] command_loop_1(dummy = UNION), line 493 in "cmdloop.c"
[70] condition_case_1(handlers = UNION, bfun = 0xe0340 = &`xemacs`cmdloop.c`command_loop_1(Lisp_Object dummy), barg = UNION, hfun = 0xdf0a0 = &`xemacs`cmdloop.c`cmd_error(Lisp_Object data, Lisp_Object dummy), harg = UNION), line 1646 in "eval.c"
[71] command_loop_3(), line 255 in "cmdloop.c"
[72] command_loop_2(dummy = UNION), line 266 in "cmdloop.c"
[73] internal_catch(tag = UNION, func = 0xdf3d8 = &`xemacs`cmdloop.c`command_loop_2(Lisp_Object dummy), arg = UNION, threw = (nil)), line 1321 in "eval.c"
[74] initial_command_loop(load_me = UNION), line 304 in "cmdloop.c"
[75] xemacs_21_2_b19_sparc_sun_solaris2_8(argc = 1, argv = 0xffbeed5c, envp = 0xffbeed64, restart = 0), line 1762 in "emacs.c"
[76] main(argc = 1, argv = 0xffbeed5c, envp = 0xffbeed64), line 2187 in "emacs.c"
(verve:dbx) 2$
- 2 participants
- 2 comments
Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19
24 years, 7 months
Dan Harkless
Dan Harkless
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> > That's a bug, but deleting spaces (any ASCII space or tab
> > characters) in Japanese is data corruption, pure and simple. Don't
> > fix it by breaking Japanese.
>
> The Japanese fixed it by breaking English. And French. And
> Croatian. And...
>
> We'll revert to the state of affairs when things worked for European
> languages, and then we'll accept correct fixes for Japanese. Which is
> how we should have dealt with it in the first place.
I don't have an xemacs built with mule, so I can't try it, but do you get
lines of (fill-column + 1) columns if you type a space at fill-column in
Japanese too?
If so, it seems like the current code is wrong for all languages -- what
about my previous suggestion that the right thing to do if you need to
preserve spaces is to have auto-fill actually go back and break at the
_previous_ legal fill boundary? Then the unbreakable text at the end of the
line and the space after it would go down to the beginning of the next line.
There could even be a variable like [auto-?]fill-preserve-spaces or
something like that that you could set in any language that would cause that
behavior. If it wasn't set, the old correct (Western language) behavior of
changing the space to a newline would apply.
People working in Japanese would just need to be sure to set that variable
(if there weren't some automatic way of turning it on while working in
Japanese buffers).
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-xemacs(a)dilvish.speed.net | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
- 1 participants
- 0 comments
VM or BBDB eating XEmacs?
24 years, 7 months
Erik Arneson
Erik Arneson
Howdy guys,
I'm not sure if this is a problem you've heard of already, but I'm
having some trouble tracking it down. Once or twice a day while reading
e-mail, VM starts to go out of control. XEmacs eats up more memory and
more CPU, and eventually either dies or locks up X11 for a while.
Lately I've been killing it before it becomes too much of a problem.
Anyhow, it always happens when I select a new message, and I think on
the few backtraces I've managed to get, it always looks like the last
thing recorded looks like a `resize-subwindow' call that may have
something to do with the gutter. Here's a backtrace I've dug up:
Lisp backtrace follows:
resize-subwindow(#<image-instance (widget) on #<x-device on ":0.0" 0x213f> (#<
face default "default face">)Buffers 789x23 on #<x-frame > 0x0x8cbe808 0x11ef0> 7
89 nil)
# bind (inst frame-or-buffer)
update-tab-in-gutter(#<buffer "(AD&D) Summary">)
select-window(#<window on "(AD&D) Summary" 0x11eee>)
# bind (w-list osw sw p first-window position-map)
tapestry-set-position-map(((nil nil nil t) (nil nil nil nil)) #<window on "(AD&
D) Summary" 0x11eee>)
# bind (first-window sf tapestry-windows-changed frame-list frame-map other-map
s other-map root-window-edges n map)
set-tapestry((((... ...)) ((... ... ...))) 1)
# bind (nonexistent nonexistent-summary selected-frame summary message composit
ion edit config)
byte-code("..." [vm-mutable-windows throw done nil " *vm-nonexistent*" " *vm-no
nexistent-summary*" vm-selected-frame config edit composition message summary sel
ected-frame nonexistent-summary nonexistent tags vm-window-configurations default
vm-copy vm-find-composition-buffer t major-mode vm-summary-mode vm-mail-buffer b
uffer-name vm-mode vm-presentation-mode vm-virtual-mode mail-mode vm-system-state
editing vm-check-for-killed-presentation vm-presentation-buffer vm-check-for-kil
led-summary vm-summary-buffer tapestry-replace-tapestry-element #<compiled-functi
on (x) "...(9)" [x] 1> set-tapestry 1 get-buffer vm-maybe-delete-windows-or-frame
s-on vm-get-buffer-window vm-replace-buffer-in-windows] 9)
# (catch done ...)
# bind (tags)
vm-set-window-configuration(vm-scroll-forward reading-message)
apply(vm-set-window-configuration (vm-scroll-forward reading-message))
# bind (wf w)
# (unwind-protect ...)
# bind (vm-sbe-buffer do-not-raise configs commands display buffer)
vm-display(nil nil (vm-scroll-forward vm-scroll-backward) (vm-scroll-forward re
ading-message))
# bind (w old-w-start mp-changed needs-decoding was-invisible arg)
vm-scroll-forward(nil)
# bind (command-debug-status)
call-interactively(vm-scroll-forward)
# (condition-case ... . error)
# (catch top-level ...)
I have the gutter disabled, and I'm reading mail in VM with BBDB hooked
into it. What could be causing this? It's bugging the heck out of me.
(emacs-version) => "XEmacs 21.2 (beta19) \"Shinjuku\" [Lucid]
(i686-pc-linux, Mule) of Thu Sep 2 1999 on inanna"
--
# Erik Arneson erik(a)starseed.com Webring Software Engineer #
# Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 #
# "There's such a fine line between stupid and clever." Spinal Tap #
- 2 participants
- 2 comments
hpux 10.20 + all latest patches : OUCH!
24 years, 7 months
Richard Cognot
Richard Cognot
Just applied the all the hpux patches on my machine. Everything is
fine, except xemacs.
My binary for 21.2 stopped working (dumps core right at the start when
processing the env variables). So did my 21.1 binary??? And my
21.0???????
I'm back to 19.16 (????????????????) now, and it seems to work.
No luck recompiling either: dumps core when running the dumped xemacs
for the first time (while testing for shadows).
I've tried with/without rel-alloc/gnu-malloc, no luck.
With gnu malloc, it dumps while putting the env variables into lisp
strings, in gmalloc itself (line 586, next->prev is nil). If I protect
that one, it dumps with an assertion, due to the fact that the first
lisp string created for for the first env variable is 0xffffffff (in
make_uninit_string). Can't figure out why though...
Any ideas?
Richard.
--
|-------------------------------------------------------------|
| Richard Cognot | Proceed, with fingers crossed... |
| | /\^^/\ |
| <cognot(a)ensg.u-nancy.fr> | `' |
|-------------------------------------------------------------|
| http://www.ensg.u-nancy.fr/~cognot |
|-------------------------------------------------------------|
- 3 participants
- 5 comments