August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 21.2.19 assert failure, editing in minibuf 26 years

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > I just got a crash while editing in the minibuf, too. :-( > I was doing a filename completion, and had just pressed tab when the > crash occurred. > > The back trace (shown in part below), is very similar to Karl's: Hmm. It seems to be a very real problem: > #7 0x18f364 in bufpos_to_bytind (buf=0x430c00, x=0) at buffer.h:986 x is a Bufpos so it should never ever be 0. I am not sure whether the new wordskipping logic in syntax.c is correct (it might contain a off by one error). However this code should never ever be reached if from = 1 and count = -1 as from already is the lowest possible value! Could you check the value of 'limit' in this frame? > #8 0x2249fc in scan_words (buf=0x430c00, from=1, count=-1) at > #syntax.c:427 If limit is 0 above somebody has screwed up the BUF_BEGV of the minibuffer. That would then be the real problem the scan_words change is just exposing it. Jan

1 participants
0 comments

Re: 21.2.19 assert failure, editing in minibuf 26 years

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Karl Kleinpaste <karl(a)justresearch.com> writes: >> I was editing a minibuf prompt, which had a default response that I >> was altering. I had backed up to the first character in the minibuf, >> a comma, and hit M-BS a last time (after deleting several words >> beforehand) to eliminate it. I just got a crash while editing in the minibuf, too. :-( I was doing a filename completion, and had just pressed tab when the crash occurred. The back trace (shown in part below), is very similar to Karl's: #0 0xef07452c in kill () #1 0xa0108 in fatal_error_signal (sig=6) at emacs.c:276 #2 <signal handler called> #3 0xef07452c in kill () #4 0xef03a5d4 in abort () #5 0xa3584 in assert_failed (file=0x30d520 "insdel.c", line=607, expr=0x30d5d8 "( newmin) > BI_BUF_BEG (buf) && newmin <= BI_BUF_Z (buf)") at emacs.c:2672 #6 0x18e6dc in bufpos_to_bytind_func (buf=0x430c00, x=0) at insdel.c:607 #7 0x18f364 in bufpos_to_bytind (buf=0x430c00, x=0) at buffer.h:986 #8 0x2249fc in scan_words (buf=0x430c00, from=1, count=-1) at syntax.c:427 #9 0x224e40 in Fforward_word (count=-1, buffer=4393984) at syntax.c:476 #10 0x69e6c in execute_rare_opcode (stack_ptr=0xefffc1fc, program_ptr=0x110656a "\210`\026\a\016\nfzËU«\013\016\nb\210Ìv\210`\026\n\016\016b\210\016\r\016\a\016\nZX\020\016\a\016\nZ\016\017X\006\016\n\016\a{)\207\001", opcode=Bforward_word) at bytecode.c:1390 #11 0x68b6c in execute_optimized_program (program=0xefffc1fc "ÿÿÿÿ", stack_depth=118, constants_data=0x1551b10) at bytecode.c:657 #12 0x685f4 in funcall_compiled_function (fun=24612332, nargs=0, args=0xefffc458) at bytecode.c:523 #13 0xacfac in Ffuncall (nargs=0, args=0xefffc454) at eval.c:3221 #14 0x68ebc in execute_optimized_program (program=0xefffc454 "\001Vª€", stack_depth=0, constants_data=0x13fb090) at bytecode.c:747 #15 0x685f4 in funcall_compiled_function (fun=24612360, nargs=0, args=0xefffc6a8) at bytecode.c:523 #16 0xacfac in Ffuncall (nargs=0, args=0xefffc6a4) at eval.c:3221 #17 0x68ebc in execute_optimized_program (program=0xefffc6a4 "\001VªŒ", stack_depth=0, constants_data=0x13fb6d0) at bytecode.c:747 #18 0x685f4 in funcall_compiled_function (fun=24742536, nargs=0, args=0xefffc900) at bytecode.c:523 #19 0xacfac in Ffuncall (nargs=0, args=0xefffc8fc) at eval.c:3221 #20 0x68ebc in execute_optimized_program (program=0xefffc8fc "\001V£L\001V\231\fï\035Åž", stack_depth=0, constants_data=0x1799490) at bytecode.c:747 #21 0x685f4 in funcall_compiled_function (fun=24743292, nargs=0, args=0xefffcc54) at bytecode.c:523 #22 0xacfac in Ffuncall (nargs=0, args=0xefffcc50) at eval.c:3221 #23 0xae37c in run_hook_with_args_in_buffer (buf=0x3dc804, nargs=1, args=0xefffcc50, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3671 Jan> Did this prompt have any high-bit characters in it? Not for me. Jan> It _is_ crashing in a new part of the code. However the assert is Jan> close to impossible to trigger. So this crash is very weird. Jan> Do you still have the core file? Yes. >> #4 0x81360f3 in bufpos_to_bytind_func (buf=0x8318ee8, x=0) at insdel.c:607 Jan> Could you check buf->pt and buf->bufpt in this frame? (As well as the Jan> value of bufmin). #6 0x18e6dc in bufpos_to_bytind_func (buf=0x430c00, x=0) at insdel.c:607 607 DEC_BYTIND (buf, newmin); (gdb) p buf $1 = (struct buffer *) 0x430c00 (gdb) p buf->pt $2 = 8 (gdb) p buf->bufpt $3 = 8 Jan> Which gcc version do you use? 2.7.2.2 on Solaris 2.5.1. If you need more info, I can give it to you. Ray

1 participants
0 comments

Re: Usability issues (was: horribly long Subject ;D) 26 years

Jan Vroonhof

Bless Terje <link(a)rito.no> writes: > * Figure out why it takes so long to make binaries > and "installers" (InstallShield, rpms, etc.) and This very simple. Major developer should stop changing jobs :-). > * Start with a "clean" machine (e.g. a fresh Red Hat > 6.0 install), open a web browser to www.xemacs.org > [..] > Now, figure out what can be done to cut down on the > number of steps. Can you get it below five? :-) One Major step would be "Get Red Hat to finally ship the d*mn thing!" Every other distribution does. Regardless of the state of the installation instructions it helps if you have seen XEmacs before. > [2] - No, I'm _not_ volunteering! :-| This is of course part of the problem. Jan

1 participants
0 comments

Re: Usability issues (was: horribly long Subject ;D) 26 years

Jan Vroonhof

John S Jacobs Anderson <jacobs(a)azstarnet.com> writes: > as someone who also had a bit of a struggle with the initial 'install > curve', I'm willing to volunteer some time to help out, especially if > it can free up a developer for 'real work'. > > I'm basically qualified (I think) to do Terje's (or is it > Bless's?) first and third tasks (web site updates and install > documentation development). > > Where do I go to sign up? As far as I am concerned you just did. You probably need the appropriate passwords and stuff to update things. I hope I'm not presumptuous but I think Jason and Marcus would love some help. I have CC'ed them in case they are somehow not reading this. Jan

1 participants
0 comments

Re: Usability issues (was: horribly long Subject ;D) 26 years

john s jacobs anderson

Bless Terje <link(a)rito.no> writes: > [ Apologies if this email is fubar. I'm struggling to make ] [ MS > Outlook act like a decent email client. So far my ] [ success has > been limited. :-( ] [ came thru mostly okay though. ] { major snippage } as someone who also had a bit of a struggle with the initial 'install curve', I'm willing to volunteer some time to help out, especially if it can free up a developer for 'real work'. I'm basically qualified (I think) to do Terje's (or is it Bless's?) first and third tasks (web site updates and install documentation development). Where do I go to sign up? john. -- ---------------------------------------------------------------- John S Jacobs Anderson jacobs(a)azstarnet.com www.treefort.org/~jacobs/ <-- GeneHack (bioinfo*linux*opinion)

1 participants
0 comments

Usability issues (was: horribly long Subject ;D) 26 years

Bless Terje

[ Apologies if this email is fubar. I'm struggling to make ] [ MS Outlook act like a decent email client. So far my ] [ success has been limited. :-( ] Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote: >Hans Reiser <reiser(a)idiom.com> wrote: > >>If you guys could put the contents of Jan's simple instructions >>in the README, boy, it would be nice.... > >As I wrote. I don't know why Didier's announcement is not on the >ftp site. Combined with an undermaintained Web site (I am not sure >what is the problem there, but I presume also time constraints) >we have a serious Problem. Yes! I'd rate myself somewhere in the neighbourhood of a "power user"[0] and it took me ages to find /anything/ on xemacs.org. In the lull after 19.14 (IIRC) I was starting to think XEmacs was dead since nothing seemed to be happening on the web site. Not until I found XEmacs-beta did I figure out that there was actually something going on. >>It is NOT obvious where sumo goes. > >Even after reading README.packages (or the equivalent link on the web >site)? I wrote that README and I am afraid I cannot do better then >that. Please point out how it should be changed. The same problem here as above; Y'all are thinking on the wrong level! To follow the evolution of XEmacs, I need an updated web site which lists current version -- including minor revisions and user level change log -- and current "Beta"[1] version with similar information. There should also be information regarding what is being worked on and what is planned for future releases. The packaging needs to be extremely simple -- rpms, IRIX inst'able or Windoze InstallShield/Point&Drool, or a single tar that gets you everything you need to get started; _including_ efs and whatever else I need to get the package system running. Figuring out what is optional and what is required and which archive gets untared where is sub-optimal to the point of being obtuse. If you want to fiddle with this, chances are you are actively developing for XEmacs and should be getting this stuff from cvs. Otherwise you just want to use the (arguably) best editor/ide/whatever without having to figure out implementation details to do it. I love XEmacs, but I'll never write a line of LISP if I can avoid it. XEmacs is a monolitic application -- and packages amount to "plugins" -- from my POV. I'd like to be able to treat XEmacs as a "Black Box", but I keep getting reminded that there is a whole lot of plumbing underneat and this is especially true during installation. My suggestions for remeding these problems: * Get some poor schmuck to take over what work the current "webmaster" on www.xemacs.org doesn't have time for[2]. You don't have to tie up developer's time for this; any XEmacs user should be able to manage the brunt of the work. * Figure out why it takes so long to make binaries and "installers" (InstallShield, rpms, etc.) and fix it. Recruit new builders; fix the problems that makes them spend so much time getting stuff out the door. * Start with a "clean" machine (e.g. a fresh Red Hat 6.0 install), open a web browser to www.xemacs.org and proceede to install the most recent XEmacs. Write down the steps (i.e. click link; read page; click link; download tar file one; download tar file two; etc.) until you can start working with XEmacs (e.g. check out your current Perl project from the cvs repository and start writing). Now, figure out what can be done to cut down on the number of steps. Can you get it below five? :-) HTH, TTFN. -link [0] - As in "He does some admining and simple Perl programs, but for gods sakes do not let him near anything complicated!" :-) [1] - For an arbitrarily wide definition of "beta". [2] - No, I'm _not_ volunteering! :-|

1 participants
0 comments

Re: 21.2.19 assert failure, editing in minibuf 26 years

Karl Kleinpaste

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Did this prompt have any high-bit characters in it? Yup, when it started. There had been a \377 in there. > Do you still have the core file? Regrettably, about 10min after I posted that, with the dying xemacs still trapped in gdb hell, the machine crashed. :-( I will see what I can learn when it next happens. Perhaps I can induce this one more easily, if it just takes a high-bit char. > Could you check buf->pt and buf->bufpt in this frame? (As well as the > value of bufmin). Not this time. :-/ > Which gcc version do you use? 2.7.2.3, as distributed with RH5.2, bland and vanilla. --karl

1 participants
0 comments

Re: 21.2.19 assert failure, editing in minibuf 26 years

Jan Vroonhof

Karl Kleinpaste <karl(a)justresearch.com> writes: > I was editing a minibuf prompt, which had a default response that I > was altering. I had backed up to the first character in the minibuf, > a comma, and hit M-BS a last time (after deleting several words > beforehand) to eliminate it. > > (Specifically, a Keywords: specification in a reply in Gnus.) Did this prompt have any high-bit characters in it? It _is_ crashing in a new part of the code. However the assert is close to impossible to trigger. So this crash is very weird. Do you still have the core file? > #4 0x81360f3 in bufpos_to_bytind_func (buf=0x8318ee8, x=0) at insdel.c:607 Could you check buf->pt and buf->bufpt in this frame? (As well as the value of bufmin). Which gcc version do you use? Jan

1 participants
0 comments

Re: Yeah! Using instructions missing from the README, xemacs installed! (was Re: How can xemacs have been made so hard to install? Do the developers have any clue it is needlessly hard/undocumented?) 26 years

Jan Vroonhof

Hans Reiser <reiser(a)idiom.com> writes: > If you guys could put the contents of Jan's simple instructions in > the README, boy, it would be nice.... As I wrote. I don't know why Didier's announcement is not on the ftp site. Combined with an undermaintained Web site (I am not sure what is the problem there, but I presume also time constraints) we have a serious Problem. > It is NOT obvious where sumo goes. Even after reading README.packages (or the equivalent link on the web site)? I wrote that README and I am afraid I cannot do better then that. Please point out how it should be changed. > I did use Sumo. That left me having to download 5 tar balls, and > having no instructions on what goes where (It has no README saying > where it goes), Please tell me what can be improved on the "The SUMO tarball" section of README.packages. > > P.S. The package index signing issues is because we fell into a trap > > set for us set for us by RSA inc, The US government and the designers > > of PGP all working together. This will (hopefully) soon be resolved. > > What happened to that signatures index package? Did you guys take it off the site, > or did I just forget where I saw it? No the problem is that the XEmacs maintainer can currently only use GnuPG and that doesn't support PGP signatures. Unfortunately signing with GPG causes PGP 2.6.x to report a "Package signature failed" (or something like that) which is even worse than the current problem. > gcc -g -O3 -Wall -Wno-switch -Demacs -I../src -DHAVE_CONFIG_H > /usr/src/xemacs-21.1.4/lib-src/make-path.c -o make-path > In file included from /usr/include/bits/errno.h:25, > from /usr/include/errno.h:36, > from /usr/src/xemacs-21.1.4/lib-src/make-path.c:36: > /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory > make[1]: *** [make-path] Error 1 > make[1]: Leaving directory `/usr/src/xemacs-21.1.4/lib-src' > make: *** [lib-src] Error 2 Note that the including of asm/errno.h is done by /usr/include/bits/errno.h which is included by usr/include/errno.h. It seems to me something is screwed up with your header files. You really should just install a working set of headers in /usr/include and forget about the symlink. This creates some hassle in compiling tightly bound linux tools but it is worth it. > boy, you guys sure ought to clean up a lot of warnings, you know, just so you'll > notice if there is a warning that is significant.... Using egcs 1.1.2 are you? That compiler is broken with respect to the warnings. Under Solaris (with CC) and with gcc 2.7.2 or gcc 2.95 there are close to know warnings. > I didn't get a chance to try out this script Eric sent me, but > thanks for sending the script. Maybe the developers of xemacs might > take a look at it. I didn't either. But at first glance it looks all-right. Jan

2 participants
1 comments

About package versions 26 years

Norbert Koch

Hi, after updating the packages yesterday, I have (w3-version) "WWW 4.0pre.39, URL p4.0pre.39, MM 1.96" Now, from the w3 mailing-list I gather that pre.44 is the current version which can be retrieved via CVS. Then, AFAIK, there also exists the package (module) CVS tree. Two questions: - when are the packages updated? - are the CVS repositories synchronised? Thanks, norbert.

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta August 1999