December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Martin Buchholz

Recent messages to this list, by JDonner, and Vincent Hamrick, contain html which causes VM to fire up w3, which crashes XEmacs with the following Lisp backtrace. It's very important to fix this as soon as possible, and I am willing to help, but probably Andy or Bill are the right people to find the fix. If you need for me to debug a little to help out if you can't reproduce it yourself, let me know... Martin # (unwind-protect ...) specifier-instance(#<image-specifier global=((... . ...) (... . ...) (... . ...)) fallback=((nil . ...)) 0x1bd3> nil nil nil) # bind (value no-fallback default domain property glyph) glyph-property-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x1bd3>0x1bd2> image nil nil nil) # bind (no-fallback default domain glyph) glyph-image-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x1bd3>0x1bd2>) # bind (inhibit-read-only zmacs-region-stays val frame value message) raw-append-progress("Parsing 5k" 33 #<x-frame "emacs" 0x593e>) # bind (tmsg top frame value message label) append-progress(progress "Parsing 5k" 33 nil) # bind (frame value message label) display-progress(progress "Parsing 5k" 33) # bind (str args value fmt) progress("Parsing %s" 33 "5k") # bind (w3-p-s-btdt w3-p-s-baseobject w3-p-s-except w3-p-s-content-model w3-p-s-tran-list w3-p-s-transition w3-p-s-state-transitions w3-p-s-includep w3-p-s-end-tag w3-p-s-content w3-p-s-var w3-p-s-undo-list w3-p-s-overrides w3-p-s-num w3-p-s-pos w3-p-s-entity open-list content content-model attr-value attr-name ref w3-p-d-exceptions w3-p-d-shortref-chars w3-p-d-shortrefs w3-p-d-in-parsed-marked-section w3-p-d-null-end-tag-enabled w3-p-d-non-markup-chars w3-p-d-debug-url marked-section-undo-stack w3-p-d-open-element-stack w3-p-d-current-element tag-end attribute-value-end tag-attributes net-tag-p w3-p-d-end-tag-p w3-p-d-tag-name between-tags-end between-tags-start parse-buffer one-hundred status-message-format loop-count last-loop-start gc-cons-threshold old-syntax-table buff) w3-parse-buffer(#<buffer " *w3-region*">) # (unwind-protect ...) byte-code("..." [get-buffer-create " *w3-region*" erase-buffer source w3-parse-buffer parse st nd w3-draw-tree nil widget glyph url w3-image-widgets-waiting widget-get :src assoc w3-graphics-list (widget-value-set widget glyph) ((error)) url-current-object 6 push-mark t w3-find-specific-link w3-running-xemacs device-type tty w3-fixup-eol-faces message "Drawing... done"] 3) # (unwind-protect ...) # bind (parse w3-display-same-buffer source nd st) w3-region(2535 8151) # bind (buffer-read-only start end buffer-size) byte-code("..." [nil buffer-size end start buffer-read-only message "Inlining text/html, be patient..." vm-fsfemacs-mule-p enable-multibyte-characters xzx ((set-buffer-multibyte xzx)) set-buffer-multibyte vm-mime-insert-mime-body layout vm-mime-transfer-decode-region w3-region t inhibit-read-only remove-text-properties (read-only nil) "Inlining text/html... done"] 4) !\"\"Æ" ... 6))))se ... . ((error (byte-code "À ÂÃÄ # bind (layout) vm-mime-display-internal-text/html([("text/html" "charset=us-ascii" "name=xemacs2118changes.html") ("text/html" "charset=us-ascii" "name=\"xemacs2118changes.html\"") "7bit" nil nil ("inline" "filename=xemacs2118changes.html") ("inline" "filename=\"xemacs2118changes.html\"") #<marker at 5339992 in inbox 0x8939224> #<marker at 5340163 in inbox 0x893920c> #<marker at 5345779 in inbox 0x8939104> nil nil <<m>> nil]) byte-code("..." [intern "vm-mime-display-internal-" type layout] 3) # (condition-case ... . ((void-function))) # (unwind-protect ...) # bind (modified file type type2 type-no-subtype extent dont-honor-c-d layout) vm-decode-mime-layout([("text/html" "charset=us-ascii" "name=xemacs2118changes.html") ("text/html" "charset=us-ascii" "name=\"xemacs2118changes.html\"") "7bit" nil nil ("inline" "filename=xemacs2118changes.html") ("inline" "filename=\"xemacs2118changes.html\"") #<marker at 5339992 in inbox 0x8939224> #<marker at 5340163 in inbox 0x893920c> #<marker at 5345779 in inbox 0x8939104> nil nil <<m>> nil]) # bind (part-list layout) vm-mime-display-internal-multipart/mixed([("multipart/mixed" "boundary=------------5D211D64D97BE22F2D781758") ("multipart/mixed" "boundary=\"------------5D211D64D97BE22F2D781758\"") "7bit" nil nil nil nil #<marker at 5337291 in inbox 0x88c3b8c> #<marker at 5339147 in inbox 0x88d0cb4> #<marker at 5345822 in inbox 0x88d04d4> ([... ... "7bit" nil nil nil nil #<marker at 5339231 in inbox 0x88fa6c4> #<marker at 5339307 in inbox 0x88fa6ac> #<marker at 5339952 in inbox 0x893923c> nil nil <<m>> nil] [... ... "7bit" nil nil ... ... #<marker at 5339992 in inbox 0x8939224> #<marker at 5340163 in inbox 0x893920c> #<marker at 5345779 in inbox 0x8939104> nil nil <<m>> nil]) nil <<m>> nil]) byte-code("..." [intern "vm-mime-display-internal-" type layout] 3) # (condition-case ... . ((void-function))) # (unwind-protect ...) # bind (modified file type type2 type-no-subtype extent dont-honor-c-d layout) vm-decode-mime-layout([("multipart/mixed" "boundary=------------5D211D64D97BE22F2D781758") ("multipart/mixed" "boundary=\"------------5D211D64D97BE22F2D781758\"") "7bit" nil nil nil nil #<marker at 5337291 in inbox 0x88c3b8c> #<marker at 5339147 in inbox 0x88d0cb4> #<marker at 5345822 in inbox 0x88d04d4> ([... ... "7bit" nil nil nil nil #<marker at 5339231 in inbox 0x88fa6c4> #<marker at 5339307 in inbox 0x88fa6ac> #<marker at 5339952 in inbox 0x893923c> nil nil <<m>> nil] [... ... "7bit" nil nil ... ... #<marker at 5339992 in inbox 0x8939224> #<marker at 5340163 in inbox 0x893920c> #<marker at 5345779 in inbox 0x8939104> nil nil <<m>> nil]) nil <<m>> nil]) # (unwind-protect ...) # (unwind-protect ...)

3 participants
3 comments

Re: How about a feature freeze 24 years, 4 months

Hrvoje Niksic

Bill Perry <wmperry(a)aventail.com> writes: > Do we want to try and break a few things out into modules before > 21.2 starts getting close? > > I'm thinking eldap.c, gpmevent.c, etc. Modules might be one of the things we will want to finish for the 21.2 release. Breaking existing functionality into modules may or may not be part of that process. We should definitely think about it.

3 participants
2 comments

Re: W3 crashes 24 years, 4 months

Daniel Pittman

On Thu, 16 Dec 1999, Martin Buchholz <martin(a)xemacs.org> wrote: >>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > Jan> Martin Buchholz <martin(a)xemacs.org> writes: >>> following Lisp backtrace. It's very important to fix this as soon as >>> possible, and I am willing to help, > > Jan> There is a fix, but you vetoed it :-). This is caused by the > Jan> Xaw3d/Xaw breakage. Compile with plain athena as a work around. > > Hey, I didn't realize this was a bug fix! I was trying to avoid > introducing a DE-stabilizing change into XEmacs. How come this crash > hasn't always been a problem? >From what other people have said[1], creating a subclass of an Athena widget with the flat Athena headers, then running against a 3d Athena will cause you pain. > Daniel, I'm suddenly much more interested in helping with this, since > I don't really like people being able to crash my XEmacs by sending me > email. *grin* The next patch went through today[2]. It will refuse point blank to build with mismatched Athena headers and widgets. It also prefers to use something it *knows*[3] is right -- the headers is `neXtaw/' for the neXtaw library and so on. It's pretty robust against slight mismatches. > I'm not convinced yet that it's an Xaw/Xaw3d mixup yet, though. Well, I currently have the gutter turned off because it killed my machine. Then I tried using W3 and the progress stuff killed me. Hmmm. Heres a test for it. I just built with matching headers and shared libs; lets try that some test again... /time passes/ Well. Still here. The new progress bars look positively awful with the neXtaw library, or possibly just at all. They didn't cope well at all with this XEmacs of mine. Still, no crash. Personally, I am now convinced that at least some of the lossage with the new widgets is Athena foolishness related. Daniel Footnotes: [1] I have seen things crash, put flat Xaw back and had them work, but only because other people said this would work (and it did :) [2] MsgId <87ln6vgr03.fsf(a)inanna.danann.net> in xemacs-patches [3] Where /knows/ is defined as `if the user isn't deliberately trying to make me suffer' -- you can probably fool the detection, but not without actually trying. -- The best work of artists in any age is the work of innocence liberated by technical knowledge. -- Nancy Hale

1 participants
0 comments

Re: W3 crashes 24 years, 4 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > following Lisp backtrace. It's very important to fix this as soon as > possible, and I am willing to help, There is a fix, but you vetoed it :-). This is caused by the Xaw3d/Xaw breakage. Compile with plain athena as a work around. Jan

2 participants
1 comments

New Athena configure support patch. 24 years, 4 months

Daniel Pittman

I have just posted an updated version of my Athena support for configure to xemacs-patches. Could I ask that people give this a try and let me know if it fails anywhere -- especially if it makes mistakes finding your Athena widgets? Thanks, Daniel -- C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

1 participants
0 comments

Re: How about a feature freeze 24 years, 4 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> Modules might be one of the things we will want to > Hrvoje> finish for the 21.2 release. Breaking existing > Hrvoje> functionality into modules may or may not be part of > Hrvoje> that process. We should definitely think about it. > > I think breaking out functionality at this point is a bad idea; do > we have any working and heavily used code in modules now? We don't. > Did the docstrings issue ever get resolved? It did. > Etc, etc; AFAIK there are still design issues with this capability > and we don't want to set bad precedents by doing things in a release > we one release later are forced to declare deprecated after user > experience reports come in. The C interface stuff has unresolved issues. However, breaking stuff internally might be a good UI issue. But I don't have strong feelings about that. Maybe you're right, and modules should be postponed for 21.4. But you could say the same for the portable dumper, etc. It was only my thought that we should finish these projects, if at all possible.

1 participants
0 comments

Re: interactive version of ldap-search 24 years, 4 months

Oscar Figueiredo

>>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: Charles> The interactive version of ldap-search seems to perform the search, Charles> then send the output to /dev/null. What is the intended interactive Charles> use of ldap-search? Bug. I confess I never used that function interactively. I'll send a fix. Oscar

1 participants
0 comments

Modules (was: Re: How about a feature freeze) 24 years, 4 months

Oscar Figueiredo

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> Bill Perry <wmperry(a)aventail.com> writes: >> Do we want to try and break a few things out into modules before >> 21.2 starts getting close? >> >> I'm thinking eldap.c, gpmevent.c, etc. Hrvoje> Modules might be one of the things we will want to finish for the Hrvoje> 21.2 release. Breaking existing functionality into modules may or Hrvoje> may not be part of that process. We should definitely think about Hrvoje> it. I'm interested in moving eldap.c to a module. What's the status of the module support ? Is it ready for such a thing ? And most of all where can I find the documentation (I haven't searched yet), which docstrings/info files should I read ? Oscar

1 participants
0 comments

Re: New version of ispell packages breaks with aspell :/ 24 years, 4 months

Daniel Pittman

On Thu, 16 Dec 1999, Kevin Atkinson <kevinatk(a)home.com> wrote: > Daniel Pittman wrote: [...] >> The new ispell package released recently causes aspell[1] to die. >> This is because aspell does not grok the `-vv' switch passed from >> `check-ispell-version'. [...] > That option would be difficult for me to implement so that it is > exactly the same as ispell. Exactly what does the ispell package use > this information for? A quick check of my local install says... nothing. The only place that this function is called, the return value is ignored. Thus it does not matter what is returned by `-vv' from aspell, at least to the ispell package. Alternately this makes me wonder if it is really necessary for the package to try and obtain this value at all. Daniel -- Women who seek to be equal with men lack ambition. -- Timothy Leary

1 participants
0 comments

Re: New Release of XEmacs-Packages 24 years, 4 months

Norbert Koch

Andreas Jaeger <aj(a)suse.de> writes: > I've uploaded now all packages to ftp.xemacs.org/xemacs/packages > together with new sumo tar balls. Hi! Trying to install the packages using "XEmacs 21.2 (beta24) \"Hecate\" [Lucid] (i586-pc-win32) of Thu Dec 16 1999 on KEATS" I get a 'Installation of package xxx failed' for every package, although the installation succeeds. The package-load-path is ("d:\\xemacs\\xemacs-packages\\lisp\\" "d:\\xemacs\\xemacs-packages\\lisp\\apel\\" ; .... ) In order to go on with the installation and not trying to install the same package over and over again, I've to restart pui-list-packages. Cheers, nobbi

1 participants
0 comments

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 December 1999