January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Crash related to x-win-init-sun [was Re: Crash using gnuclient] 25 years, 10 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > This code is completely different as of 21.2.5. This doesn't crash > for me in 21.2.8. On a Sun? > Is it possible this is a crash I've actually > *removed*? So it would be fine to leave it for now if it was just my silly M-x disassemble example. However for the original poster it happened due to real work. As it seems to be a GC problem there is of course also the opportunity you new code just hides it? Jan P.S. Silly idea would it be possible (using a smartly redefined LispObject type and dito GCPRO macros) to catch GCPRO bugs using a C++ compiler.

1 participants
0 comments

Re: doctor kills xemacs 25 years, 10 months

Gunnar Evermann

dhawkins(a)rmas.com writes: > M-x doctor [snip] > bash$ Fatal error: assertion failed, file bytecode.c, line 532, specpdl_ptr->func == 0 I can reproduce that and have investigated a little bit. I have a pretty good idea what is causing it, but am too afraid to touch the marzilla stuff. :-) first of all a smaller recipe for the crash: - create a file test.el containing: (defun foo (bar) bar) - byte-compile and load this file - in *scratch* eval: (foo 7) OK, '7' is printed - make bar buffer-local: (make-local-variable 'bar) - eval (foo 7) again CRASH The problem is that funcall_compiled_function() correctly creates the specbinding for the local variable bar: $27 = {symbol = 139220936, old_value = 138893388, func = 0x80bdbec <specbind_unwind_local>} but at eval.c:532 UNBIND_TO_GCPRO_VARIABLES_ONLY is used which assumes that all bindings are 'normal' variables (i.e. func==0). I'm pretty sure that all this can be cured by using UNBIND_TO_GCPRO instead but maybe there is a smarter way. Martin? HTH Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

2 participants
1 comments

Re: What to do with modules now ... 25 years, 10 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Andy Piper <andyp(a)parallax.co.uk> writes: > > > If this is the case (and I know that it is) doesn't this make > > dynamic loading less useful since you will have to have modules > > compiled for every sort of build (mule, non-mule etc) > > Well, the modules will be distributed in source form, won't they? When > you compile them, they get compile with the same options your XEmacs was > compiled against, and things work. I think andy's concern was with the fact that they will need to be _installed_, and then you might not be able to share install trees or something like that. -bp

3 participants
2 comments

XEmacs works with autoconf 2.13 and libpng-1.0.3 25 years, 10 months

Martin Buchholz

I installed these two libraries, autoconf'ed myself a new configure script, and rebuilt XEmacs 21.2, without any problems. Not that I've stress-tested them or anything. I've updated the tarballs for these packages at: ftp://ftp.xemacs.org/pub/xemacs/aux Hopefully there are bug fixes in libpng 1.0.3 that lays to rest the complaints about various bugs libpng 1.0.2. (our configure script only accepts 1.0.2 and later). Martin

1 participants
0 comments

Re: Beware of modules. 25 years, 10 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > Having everything in src/ bugs me. (...) I think I hear Kyle's chainsaw buzzing. I think I'll get out of the way now.

4 participants
5 comments

Re: Beware of modules. 25 years, 10 months

William M. Perry

Olivier Galibert <galibert(a)pobox.com> writes: > On Fri, Jan 15, 1999 at 01:10:33AM -0800, Marat Boshernitsan wrote: > > I need even more extensibility than XEmacs lisp gives me, > > and modules do just that. > > Nice. Now my question is, is being able to add C functions callable from > lisp enough for you, or do you need to "plug" into the C code itself one > way or another? I'm not 100% sure I understand what you mean by 'plug' into the C code itself, but here's a stab at a response anyway. :) I assume you mean being able to call core XEmacs primitives that are already in C? I'm not sure you can really make a distinction between the two here. When I did the first very rough cut of the module support, the first module I wrote was a base64 decoder, which had to deal with all the cruft with MULE, buffers, GCPRO, throwing errors, etc, etc. Any non-trivial module would have to do this. -Bill P.

4 participants
4 comments

Re: Benchmarking XEmacs (was Re: Beware of modules.) 25 years, 10 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > I can't perceive the difference between Mule and no-Mule for most of > the fundamental editing and redisplay operations even on an ancient > Sparc ELC or a 80486/50MHz (both are XEmacs 20.4, though), including > stuff like sort-lines. Once a Japanese font is loaded, changing to > that font is no slower in XEmacs than in a kterm, perceptually. If > Hrvoje can perceive those differences as a half-order of magnitude, > he's quick. I use non-Mule XEmacs every day. As soon as I compile with Mule to test it, stuff like `M-x gnus' or editing tasks or whatever become incredibly slow. Perhaps there is another explanation for that, but I can't think of any.

2 participants
1 comments

Crash related to x-win-init-sun [was Re: Crash using gnuclient] 25 years, 10 months

Jan Vroonhof

Richard Zatorski <Richard.Zatorski(a)eng.sun.com> writes: > In XEmacs 21.0 "Pyrenean" [Lucid] (sparc-sun-solaris2.5.1) of Wed Jan 13 1999 on cheers > configured using [...] Note that in general it is a good idea to minimize the number of options used on configure. If you force something that should be autodetected this can lead to subtle configure failurs. > x-win-init-sun() > # bind (vendor) I can reproduce what I think is a related bug, same machine, totally different libraries, SUN cc 4.2. Recipe Start 'xemacs -vanilla' under X. M-x disassemble RET x-win-init-sun RET boom! #0 0x28f8c4 in print_symbol () #1 0x28f2e8 in print_internal () #2 0x28c260 in Fprin1 () #3 0xf0a38 in Fbacktrace () #4 0xcbfa4 in fatal_error_signal () #5 <signal handler called> #6 0x7400586d in ?? () #7 0x28f2e8 in print_internal () #8 0x28c260 in Fprin1 () #9 0xe5340 in funcall_recording_as () #10 0x7b73c in Fbyte_code () #11 0xea2ac in funcall_lambda () #12 0xe5778 in funcall_recording_as () #13 0x7b73c in Fbyte_code () #14 0xea2ac in funcall_lambda () #15 0xe5778 in funcall_recording_as () #16 0x7b73c in Fbyte_code () #17 0xea2ac in funcall_lambda () #18 0xe5778 in funcall_recording_as () #19 0xe7ae8 in Fapply () #20 0xeabf4 in apply1 () #21 0x7e8f0 in Fcall_interactively () #22 0xe1560 in Fcommand_execute () #23 0xe51e4 in funcall_recording_as () #24 0x7b73c in Fbyte_code () #25 0xea2ac in funcall_lambda () #26 0xe5778 in funcall_recording_as () #27 0x7ff6c in Fcall_interactively () #28 0xe1560 in Fcommand_execute () #29 0x179f5c in execute_command_event () #30 0x17b8e4 in Fdispatch_event () #31 0x9893c in Fcommand_loop_1 () #32 G > warning: core file may not match specified executable file. Have you checked this? > #3 0x1b9754 in map_obarray () > #4 0x1b9a40 in Ffset () Can somebody figure out where map_obarray is called in Ffset.? Jan

2 participants
1 comments

Re: Beware of modules. 25 years, 10 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > :) I'm OK with this. It was the Lisp directories that I wanted > consolidated, for speed. But that looks completely out of the > question now, so forget it. Well, I clearly remember you saying that you'd freak out if the C sources were split the same way that the Lisp sources have been.

2 participants
1 comments

Re: Beware of modules. 25 years, 10 months

William M. Perry

Olivier Galibert <galibert(a)pobox.com> writes: > > > 3- Modules and undumping aren't really compatible > > > > > > Undumping requires loading a lot of lisp. Said lisp uses most of the > > > functions that would end up in modules, hence all the modules will > > > have to be loaded. Worse, the data and bss sections of these modules > > > will have references to the lisp code. Do we want to write a module > > > undumper? > > Eh? I dont understand this objection at all. Why do you want to undump > > something that is dynamic? Please expand on this more so that I can > > understand the objection / limitation. > > XEmacs isn't an editor written in C. XEmacs is written in emacs lisp. > The C part is constituted of: > - the core lisp engine > - all the basic tasks involving the environment (accessing files, > drawing to screen...) > - some functions that could have been written in lisp, but would have > been too slow as a result > > Part of the building process of XEmacs is called the undumping. A > bunch of lisp is loaded which "plugs" into the C level through static > variables (the staticpro'ed ones) and then a new executable is created > which includes said lisp. > > If you use modules for parts of the engine, you will need to find some > way to link back said static variables to the lisp code. I wouldn't even > know where to start. I don't think you would need to dump the actual modules - you would just dump autoloads for their entry points, and let them get loaded when needed, just as you would for a .el or .elc. [...] > For the people out there who don't understand modern VMs very well, > let me outline two scenarios where a user wants to use for the first > time a DB function: > > a- monolithic executable: > - the function is called > - page fault, the code is loaded in memory. A bit of read-ahead of > the code is done before and after the function > - the function runs > > b- module > - the program sees that the function is not in memory > - the module is found and the function table is loaded (but not the > function code itself, usually) > - the function pointers are updated > - the function is eventually called. Go to a. > > Guess who's fastest ? Do we really care that much about the speed of the _first_ time you call a function? This is like saying we should not allow any .el files to be loaded. They should all be loaded up and dumped into a fresh xemacs executable because it would be faster than pulling in the .elc file from disk. Once you take the hit of loading the module, you end up chasing a pointer and doing the function call. Still a little slower, but I doubt it would be noticeable, given the other areas that bog down XEmacs. :) -Bill P.

4 participants
3 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 January 1999