October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Stupid pdump+GC suggestion 25 years, 1 month

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > 2. A GC that works like this > a. start at the roots of accessibility (the obarrary, the > GCPRO list, the staticpro list, catch lists, etc.) and mark > all referenced objects and objects that those objects > reference, recursively. But surely you must stop recursing into already marked objects (to avoid loops)? I now checked and it does indeed do that. In fact it already bails out earlier if the object is read-only. > b. Walk over all objects freeing those that have not been > marked, and unmarking everything else. Yes but this is conceptually the same as my phases "a" and "c" just merged into one for efficiency. > > Won't we get something extremely purespace-like, by > > i) pdumped object are read-only _and have the mark bit set_ > > ii) in phase a and c walk only over the non-pdumped objects? > > Given the revised GC description, obviously this won't work. Sorry but it is not obvious to me at all. Just replace "all" in b. by "all non-pdumped". > However, the current non-hashed GC has a pure bit in the > lrecord header. This can be used to make GC not mark or > otherwise molest dumped objects that should be considered > read-only. In fact mark_object already works that way. > In the dumper I was considering, there would > also have been a `held' bit that would be set for read-write > objects referenced by a read-only object. Objects with the > 'held' bit would not be reclaimed by the GC. Do you think there would be enough such objects around that this is worth it? (The problem is that you need to treat these held objects as additional roots). Jan

2 participants
1 comments

Stupid pdump+GC suggestion 25 years, 1 month

Jan Vroonhof

Although I like a hashing GC, I agree it may be too much to change at this moment. I am I correct in thinking that pre-hash we have 1. Read-only lisp objects 2. A GC collecter that works like this a. Walk over all lisp objects, clearing the mark bit. b. starting at the roots walk the graph of reference as follows - Mark bit was set. no action - Mark bit was not set set mark bit recurse over children c. Walk over all objects freeing those that have not been marked. Won't we get something extremely purespace-like, by i) pdumped object are read-only _and have the mark bit set_ ii) in phase a and c walk only over the non-pdumped objects? The logic I am thinking of is Having the mark bit already set precludes the GC from writing to the object, however it also terminates the recursion. That is no problem as pdumped objects can never point to non-pdumped objects because they are read-only. That way you get shareability mostly for free. We can they delay fancy GC experiments until the pdumper is finished. Jan

2 participants
1 comments

[Dave Love <d.love@dl.ac.uk>] cus-edit.el custom comments changes 25 years, 1 month

Didier Verna

-- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: cus-edit.el custom comments changes 25 years, 1 month

Didier Verna

Dave, thanks for letting me informed. I didn't have time to look at your changes yet, but for the time being, I'll forward your message to the XEmacs beta testers in case they have some comments, especially on the comment widget's visibility part. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: SIG11 in garbage collection, image related, gcc version 2.95.2 19990906 (prerelease) 25 years, 1 month

Didier Verna

Andy Piper <andy(a)xemacs.org> wrote: > At 09:47 AM 10/8/99 +0200, Didier Verna wrote: > > It looks very much like the same: > > Ok, I've got it. Yup. The following patch is needed on top of yours in order to fix a couple of XErrors (freeing null pixmaps). I'll apply it to cvs. Index: src/glyphs-x.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-x.c,v retrieving revision 1.49.2.35 diff -u -u -r1.49.2.35 glyphs-x.c --- glyphs-x.c 1999/10/11 13:47:30 1.49.2.35 +++ glyphs-x.c 1999/10/14 08:49:46 ＠＠ -416,10 +416,11 ＠＠ if (IMAGE_INSTANCE_X_PIXMAP_SLICES (p)) { for (i = 0; i < IMAGE_INSTANCE_PIXMAP_MAXSLICE (p); i++) - { - XFreePixmap (dpy, IMAGE_INSTANCE_X_PIXMAP_SLICE (p,i)); - IMAGE_INSTANCE_X_PIXMAP_SLICE (p, i) = 0; - } + if (IMAGE_INSTANCE_X_PIXMAP_SLICE (p,i)) + { + XFreePixmap (dpy, IMAGE_INSTANCE_X_PIXMAP_SLICE (p,i)); + IMAGE_INSTANCE_X_PIXMAP_SLICE (p, i) = 0; + } xfree (IMAGE_INSTANCE_X_PIXMAP_SLICES (p)); IMAGE_INSTANCE_X_PIXMAP_SLICES (p) = 0; } -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: Crash from network X server crash 25 years, 1 month

Jan Vroonhof

Ronald Pottol <chaos(a)chaostrophy.org> writes: > I run Xemacs in console mode on a stock Red Hat Linux 6.0 system, and > display to an X server on my desktop. The desktop machine had a > hardware crash. Xemacs on the console became unresponsive, I try more > than one C-g, and eventually it backgrounds its self. This is a known (and probably unsolvable) problem with the Xt libraries. It used to be that XEmacs died immediately, so there has been some improvement. > #1 0x806eba9 in fatal_error_signal () > #2 <signal handler called> > (gdb) Unfortunately this is useless... I if interpret the gdb mailing list archives correctly this because gdb prior to gdb 4.18+patch from july cannot interpret the linux kernel trampolines. If you [or any body else running Red Hat 6.x] have the time could you try a development snapshot from gdb (http://sourceware.cygnus.com/gdb) to confirm that is fixed that would be nice. Jan

1 participants
0 comments

Re: Xemacs crashes my linux! 25 years, 1 month

Kyle Jones

morten.stenseth(a)baerum-kommune.telemax.no writes: > > > Hi, I have had som problems with xemacs 21.2.15 to 21.2.19, everytime > > > i start up xemacs,it crashes linux when the xemacs-beta logo > > > becomes visible, > > > > You mean it crashes the X server? > > > no . it locks up my linux. i can't do anything ,but turn the computer off. OK. We need more data to isolate the problem. Try starting XEmacs as "xemacs -nw". If the system doens't lock up, then we're probably dealing with a X related video driver bug or something like that. If the system still locks up, then there is some other kernel trouble. But even this little bit of information would help. You could also try starting XEmacs as "xemacs -f kill-emacs". If the system still locks up, then we can rule out the event loop being the cause of the trouble. Did you compile with sound support enabled? If so do you use it in your startup sequence? If so you might try disabling it and see if it helps. SOmething you can try to verify that your system is unrecoverable when it hangs is to start XEmacs with this script #!/bin/sh xemacs & sleep 15 kill -9 $! This start XEmacs is the background, waits 15 seconds and then tries to kill the process. IF XEmacs is killable using this method then your system isn't in as much distress as we thought, and the bug is likely not to be in the Linux kernel or drivers.

1 participants
0 comments

(call-process ...) to return correct exit-status on NT 25 years, 1 month

Adrian Aichner

Hello Reviewers, hello Windows NT native experts! I wouldn't dare to send this patch to xemacs-patches yet. However, I have a first working[1] implementation for (call-process ...) to return the correct exit status of the child process called. It is a simple upgrade of the wait_for_termination(int pid) function in src/sysdep.c conditionalized on WINDOWSNT. Please test it, rip it apart and rebuild it, and send me suggestions (copying xemacs-beta and/or xemacs-nt since my mail server is having problems). A Weak Spot: When OpenProcess() returns an invalid process handle I fake a signal termination signal. synch_process_death = signal_name (SIGTERM); This is nothing than a wild guess, but better than setting synch_process_retcode = status; I have tested this using external cygnus executables "sleep" and "grep" as follows. Patch against latest CVS source of 21.2-b19 is at end. Thanks in advance for any help! Best regards, Adrian ;;; Sleeping for 3 seconds, then returns 0. (apply 'call-process "sleep" nil nil nil (list "3")) 0 ;;; Trying to sleep for 30 seconds, but killed via Windows NT Task ;;; Manager. (apply 'call-process "sleep" nil nil nil (list "30")) "software termination signal from kill" ;;; Looking for drivers in sysem file succeeds, returning 0. (apply 'call-process "grep" nil nil nil (list "drivers" "c:\\winnt\\system.ini")) 0 ;;; Looking for passangers in sysem file fails, returning 1. (apply 'call-process "grep" nil nil nil (list "passangers" "c:\\winnt\\system.ini")) 1 ;;; Looking for drivers in invalid file fails, returning 2. (apply 'call-process "grep" nil nil nil (list "drivers" "c:\winnt\system.ini")) 2 cvs server: Diffing src Index: src/sysdep.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.c,v retrieving revision 1.32.2.7 diff -u -r1.32.2.7 sysdep.c --- sysdep.c 1999/07/05 05:56:44 1.32.2.7 +++ sysdep.c 1999/10/11 14:13:46 ＠＠ -345,6 +345,36 ＠＠ Since implementations may add their own error indicators on top, we ignore it by default. */ +#elif defined (WINDOWSNT) + int ret = 0, status = 0; + HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); + if (hProcess == NULL) { + /* + * If the process is gone, it has probably been terminated. APA + */ + synch_process_alive = 0; + synch_process_death = signal_name (SIGTERM); + } else { + do { + QUIT; + ret = GetExitCodeProcess(hProcess, &status); + } while (status == STILL_ACTIVE); + if (ret) { + synch_process_alive = 0; + synch_process_retcode = status; + } + else { + /* + * GetExitCodeProcess() didn't return a valid exit status, + * nothing to do. APA + */ + stderr_out ("wait_for_termination.GetExitCodeProcess status %d return %d for pid %d\n", status, GetLastError (), pid); + } + if (!CloseHandle(hProcess)) { + stderr_out ("wait_for_termination.CloseHandle return %d for pid %d\n", + GetLastError (), pid); + } + } #elif defined (EMACS_BLOCK_SIGNAL) && !defined (BROKEN_WAIT_FOR_SIGNAL) && defined (SIGCHLD) while (1) { cvs server: Diffing src/m cvs server: Diffing src/s Footnotes: [1] driven by my need for ediff-directories to work in Windows NT native XEmacs. It does now.

3 participants
3 comments

Re: saving customizations became _really_ slow 25 years, 1 month

Jake Colman

>>>>> "JV" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: JV> I am fairly sure it means "It is the drop[let] that makes the bucket JV> overflow". (I am not sure about "bucket" (it could be "vase"), but JV> that is what it says in the equivalent Dutch saying). Funnily enough <snip> JV> P.S. Given the fact the saying exists in Italian and in Dutch, I JV> would assume something close to it would exists in English too but I JV> don't have a good dictionary handy. In English we might say "It is the straw that broke the camel's back" or, as commonly used, "that was the last straw". -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 505-2795 Jersey City, NJ 07311 E-mail: colman(a)ppllc.com E-mail: jcolman(a)jnc.com web: http://www.ppllc.com "Every time I think I've idiot-proofed something someone comes up with a better idiot"

1 participants
0 comments

Crash from network X server crash 25 years, 1 month

Ronald Pottol

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta18) "Toshima" [Lucid] (i686-pc-linux) of Sat Oct 2 1999 on prime configured using `configure --prefix=/usr --package-path=/var/tmp/xemacs-root/usr/lib/xemacs/xemacs-packages --debug=no --error-checking=none --with-pop --mail-locking=flock --with-mule=no --dynamic=yes --lockdir=/var/lock/xemacs' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I run Xemacs in console mode on a stock Red Hat Linux 6.0 system, and display to an X server on my desktop. The desktop machine had a hardware crash. Xemacs on the console became unresponsive, I try more than one C-g, and eventually it backgrounds its self. I type fg to bring it back to the forground, and I get a message asking if I want to autosave (I say no) then a message asking if I want to quit and dump core, I say no. It did anyways. >From gdb on the core: #0 0x402b5111 in __kill () (gdb) where #0 0x402b5111 in __kill () #1 0x806eba9 in fatal_error_signal () #2 <signal handler called> (gdb) I still have the core file (well, until another drops on it) and would be more than happy to assist in any way I can. Ronald Pottol Recent keystrokes: [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC x m a k e - f r a m e - o n - d i s p l a y RET 1 0 . 1 0 . 1 0 . 6 : 0 RET misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading outline...done Loading outline... Loading efs-cu...done Loading efs-cu... Note: file is write protected Loading view-less...done Loading view-less...

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