April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[CRASH] Feval during redisplay 24 years, 1 month

Yoshiki Hayashi

(emacs-version) "XEmacs 21.2 (beta32) \"Kastor & Polydeukes\" [Lucid] (i686-pc-linux, Mule) of Fri Apr 14 2000 on buck" XEmacs crashed when I hit C-g while it was trying to make a new frame. Backtrace shows that Feval is called from widget_query_geometry. And in fact, it is. Andy, please fix this. #0 0x4040f911 in kill () from /lib/libc.so.6 #1 0x80c0b6c in fatal_error_signal (sig=6) at emacs.c:293 #2 0x4040f848 in sigaction () from /lib/libc.so.6 #3 0x40410c51 in abort () from /lib/libc.so.6 #4 0x80c3047 in signal_1 (sig=137167476, data=137167356) at eval.c:1881 #5 0x80c389d in Fsignal (error_symbol=137167476, data=137167356) at eval.c:2048 #6 0x80c4968 in Feval (form=140765360) at eval.c:2511 #7 0x815c430 in widget_query_geometry (image_instance=144232664, width=0xbffff378, height=0xbffff37c, disp=IMAGE_DESIRED_GEOMETRY, domain=144148720) at glyphs-widget.c:425 #8 0x81505c5 in image_instance_layout (image_instance=144232664, width=4294967295, height=4294967295, domain=144148720) at glyphs.c:1737 #9 0x8153d0c in glyph_width (glyph_or_image=144232664, domain=144148720) at glyphs.c:3682 #10 0x8154231 in update_glyph_cachel_data (w=0x89788f0, glyph=138756360, cachel=0x898c380) at glyphs.c:3964 #11 0x815838e in get_glyph_cachel_index (w=0x89788f0, glyph=138756360) at glyphs.c:3999 #12 0x819aa94 in add_glyph_rune (data=0xbffff554, gb=0x8994398, pos_type=0, allow_cursor=0, cachel=0x0) at redisplay.c:1536 #13 0x81a0f0c in create_string_text_block (w=0x89788f0, disp_string=141613772, dl=0xbffff634, start_pos=0, prop=0xbffff630, default_face=7) at redisplay.c:1786 #14 0x81a1c6e in generate_displayable_area (w=0x89788f0, disp_string=141613772, xpos=4, ypos=41, width=655, height=24, dla=0x89468d8, start_pos=0, default_face=7) at redisplay.c:5010 #15 0x8166eee in output_gutter (f=0x8978798, pos=TOP_GUTTER, force=0) at gutter.c:285 #16 0x8167b8f in update_frame_gutters (f=0x8978798) at gutter.c:562 #17 0x81a4122 in redisplay_frame (f=0x8978798, preemption_check=0) at redisplay.c:6446 #18 0x81a4345 in redisplay_device (d=0x83a4690, automatic=1) at redisplay.c:6533 #19 0x81a46b8 in redisplay_without_hooks () at redisplay.c:6622 #20 0x8112daf in Fnext_event (event=144160872, prompt=137167356) at event-stream.c:2180 #21 0x80a481e in Fcommand_loop_1 () at cmdloop.c:566 #22 0x80c2a14 in condition_case_1 (handlers=137167452, bfun=0x80a4a70 <command_loop_1>, barg=137167356, hfun=0x80a4b20 <cmd_error>, harg=137167356) at eval.c:1644 #23 0x80a4c34 in command_loop_2 (dummy=137167356) at cmdloop.c:252 #24 0x80c28dc in internal_catch (tag=137241476, func=0x80a4bf0 <command_loop_2>, arg=137167356, threw=0x0) at eval.c:1310 #25 0x80a40d7 in initial_command_loop (load_me=137167356) at cmdloop.c:301 #26 0x80bed01 in xemacs_21_2_b32_i686_pc_linux () at emacs.c:1873 #27 0x80bf53f in main () at emacs.c:2292 #28 0x40409a42 in __libc_start_main () from /lib/libc.so.6 -- Yoshiki Hayashi

2 participants
3 comments

return of the son of frame creation crash 24 years, 1 month

John A. Turner

Irix/gcc build as describe in: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00021.html but with fresh CVS snapshot (well, yesterday) familiar scenario: o pop up frame in VM o tabs turn funky o kaboom useless stack: (gdb) run Starting program: /tmp_mnt/u/turner/Tools/src/xemacs-21.2/src/./xemacs Error: Object "(null)" does not have windowed ancestor Program exited with code 01. Current language: auto; currently asm (gdb) where No stack. I keep running with VM frame creation in hopes that one of these days I'll get a stack trace that helps pinpoint the problem... -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 825-8319

3 participants
3 comments

Re: efs and custom 24 years, 1 month

Michael Sperber

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> michael, doesn't this mean you need a :require efs in your defgroup? Ben> john really is right that you shouldn't have to manually load. I'm trying to do the right thing here. So :require is a keyword for `defcustom', not `defgroup'. Does that mean every single `defcustom' in EFS (there are 70 of them) should have :require 'efs? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: PCL-CVS 24 years, 1 month

Gunnar Evermann

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > So I finally broke down, took Charles Waldman's fixes, applied what's > left to PCL-CVS 2.9.8, and made a package from it. excellent! Just yesterday I was considering doing the same. Let's *finally* get around to releasing a new version! > (Including a gross hack to make it work with our diff.el.) It's > ready to go in, only I'm waiting for a bugfix release Stefan Monnier > has promised me RSN. didn't he just announce 2.9.9 yesterday on gnu.emacs.sources? > Just so nobody else does redundant work. let me know if you want me to test your package. Gunnar

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 1 month

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > So, customize puts its variables into ~/.emacs according to a > heuristic I haven't groked yet fully. (Needless to say, this was a > bad idea ...) IIRC, this was not so under original Per's design. Stallman insisted on using ~/.emacs. > What's a politically correct (and preferably simple) to determine > the set/region of forms in ~/.emacs under the control of customize? > Can I search for (custom-load-themes ...) or (custom-set-variables > ...) and take the region from there to the end of the file? Or can > I take all forms starting with (custom-... ...). Or what? I think you should do it the way Customize does it. This is virtually guaranteed to be correct, because then if somebody uses a weird .emacs format, Customize will not work with it either. The way Custom does it is to read the top-level forms until the form whose car is the required symbol is found. Look at `custom-save-delete' for an example of that. Unless I'm missing something, it's very easy to implement.

1 participants
0 comments

Custom migration to ~/.xemacs/options.el 24 years, 1 month

Michael Sperber

So, customize puts its variables into ~/.emacs according to a heuristic I haven't groked yet fully. (Needless to say, this was a bad idea ...) What's a politically correct (and preferably simple) to determine the set/region of forms in ~/.emacs under the control of customize? Can I search for (custom-load-themes ...) or (custom-set-variables ...) and take the region from there to the end of the file? Or can I take all forms starting with (custom-... ...). Or what? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Milestone 1 submission... 24 years, 1 month

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > At 10:09 PM 4/12/00 -0700, Ben Wing wrote: > > >i think it's wrong to tout the raw gtk-* interface as the "right" > >interface to write lisp in. in fact, if at all possible i'd suggest not > >exposing this at all. instead, expand the generic interface as > >necessary to include new gtk features. you could also provide an > >"escape" mechanism for adding or querying raw gtk properties that are > >not implemented in the abstract interface, but i do NOT want to see a > >proliferation of lisp code that is gtk-specific. although creating raw > >interfaces may seem "easier" and more powerful, it is in fact a classic > >mistake made by novice interface designers, and invariably comes back to > >haunt them. > > Absolutely right. > > From an XEmacs point-of-view the statement "..abstract interface is > beyond the scope of this project...." seems erronous to me. Given the > effort we've put into clean abstraction we absolutely can't start > breaking this with a proliferation of gtk specific dialogs. Especially as > its not clear to me how some of these constructs would map onto other > windowing systems. I would be the first to admit, however, that what we > have right now API-wise is a million miles from the richness of the gtk > APIs. Whether this is a bad thing or not is less clear to me... > > I like the XML glade idea. Personally I do too, and have been leaning more towards that since I discovered some of the 'arguments' stuff that Gtk has. Qt 2.1.0 has something similar as well. You can set generic properties on objects and define arbitrary handlers for them in your object. With Gtk you can use gtk_object_query_args() to figure out what arguments a widget accepts and what types of objects it expects (using the GTK_FUNDAMENTAL_TYPE() macro). Using this, mapping things onto generic 'get' and 'put' routines after you create the widgets would be fairly easy. Converting glyphs to/from Gdk could be a pain (even though they have gdk_pixmap_foreign_new()). I think eventually it might make sense to have a real port to using Gdk/Gtk as the 'windowing system' as an alternative to X. Then we could use them for our ports to Windows, BeOS, Macintosh, etc. One of the reasons I was looking at exposing all the gtk-specific pieces is to emulate what the rep-gtk port (and sawmill) has done. If we could incorporate some of their stuff, we could probably move a lot of the logic about WM interaction into lisp. I'm not sure if actually using glade is a good idea or not - I personally would prefer a 'real' lisp representation. Writing an XML parser wouldn't be _that_ difficult, but it would take time, and I've got basically the next 5 weeks to work on it full time to get the core redisplay & binding design done. I think what I will end up doing is in the first cut have a lisp-only representation, and then maybe use PSGML or actually make expat into a loadable module (like I've had roughed out for the last 2 years *sigh*) and use that to parse the glade stuff into that lispy representation. Then we get the best of both worlds. I'm going to start working on the implementation document tonight. I think that Gtk is the way to go, and unless people have huge arguments against it, that's what I'll base the next document on. -Bill P.

3 participants
2 comments

Out of Touch 24 years, 1 month

Vin Shelton

I'll be off email for approximately 10 days. I'll be taking a work trip to Munich for a few days and then my wife and son are joining me for a small holiday. I'll be back in the US on 4/25, but it will probably take me a few days to catch up. I plan on releasing what is currently in CVS as 21.1.10 shortly after my return. - vin

1 participants
0 comments

PCL-CVS 24 years, 1 month

Michael Sperber

FYI: So I finally broke down, took Charles Waldman's fixes, applied what's left to PCL-CVS 2.9.8, and made a package from it. (Including a gross hack to make it work with our diff.el.) It's ready to go in, only I'm waiting for a bugfix release Stefan Monnier has promised me RSN. Just so nobody else does redundant work. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: DAV and EFS 24 years, 1 month

William M. Perry

Andrew J Cosgriff <ajc(a)polydistortion.net> writes: > William M. Perry wrote : > > > If anyone is interested in DAV support, I would vote for extending > > the new URL library available via anoncvs from gnu.org. One of the > > guys at work is actually starting on this, but is not very far > > along. > > > But depending on how closely cadaver adheres to the ftp command set, > > you might just be able to set the efs-ftp-program-name to 'cadaver' > > and be on your way. > > Yeah, I was only thinking of this as a possible interim solution. > > What's the module name for the new URL library ? I guessed "url" and > it didn't work (assuming > :pserver:gnus＠quimby.gnus.org:/usr/local/cvsroot is the correct path > ?) That's gnu.org, not gnus.org :) :pserver:anoncvs＠anoncvs.gnu.org:/gd/gnu/anoncvsroot empty password. Module names are 'url' and 'w3'. You will need at least gnus 5.8.3 to install it though, since this version is the first to use the spiffy MIME handling that lars wrote (originally based on the w3 stuff, but now much much nicer). -Bill P.

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 April 2000