June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Making docdir configurable 25 years, 5 months

Michael Sperber

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 10:59 AM 6/28/99 +0200, Michael Sperber [Mr. Preprocessor] wrote: >> I should have been clearer: This ties in with a package system >> overhaul which is aware of multiple versions of the same package. >> This necessarily means that name clashes occur, and this in turn means >> that they must reside in separate directories. Andy> I guess my point is that for 95% of users they won't care about this Andy> feature but they *will* care about the speed. They will need to care about this very soon, as Steve and Valdis have pointed out. >> I really hate the fact that we're catering on the XEmacs side to >> what's really a performance bug in the OS. High-performance remote >> filesystems (like AFS) essentially solve the whole problem. Andy> And this is available on NT when? Now, as far as I know. :-) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Making docdir configurable 25 years, 5 months

Michael Sperber

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 10:05 PM 6/27/99 +0200, Michael Sperber [Mr. Preprocessor] wrote: >> To be honest (unless something other than stat is spending all that >> time), I don't know how to optimize things further. (Maybe someone >> with a kernel trace that actually gives useful results could check one >> of these days.) Any change to reduce the number of package >> directories is necessarily going to compromise the flexibility of the >> package system. Andy> Why? Call me heretical but we have manifest files so we know which files Andy> are in a package, doesn't this mean we could just have one directory if we Andy> so chose? Name clashes could be resolved by careful naming. At least having Andy> the option would be cool. I should have been clearer: This ties in with a package system overhaul which is aware of multiple versions of the same package. This necessarily means that name clashes occur, and this in turn means that they must reside in separate directories. The whole concept of manifest files which contain completely redundant information sucks. In the new framework I envision, it would probably be easier to optionally keep some sort of central-file database in synch with the actual package layout which in turn would save us a lot of stats. I know I won't be the one to implement it. I really hate the fact that we're catering on the XEmacs side to what's really a performance bug in the OS. High-performance remote filesystems (like AFS) essentially solve the whole problem. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

3 participants
2 comments

Re: X selection bug in 21.1 25 years, 5 months

SL Baur

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: > can somebody reproduce (or even fix) this? I cannot duplicate this in 21.2. Andy Piper has changed the selection code fairly heavily and perhaps he has fixed this bug. -- 郷に入っては郷に従え

2 participants
1 comments

Motif 2.0 documentation? 25 years, 5 months

Andy Piper

Can anyone with access to Motif 2.0 documentation tell me the salient points about XmComboBox? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: zombies on Solaris 2.5[.1] with 21.1.3 25 years, 5 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > excellent hint -- thanks, Jan! Excellent work in finally locating the problem! > So I suggest we reinitialise our handler again, if the tt_open() call > in tooltalk.c has failed. Any comments? Seems like the best solution. > P.S.: I haven't checked my HPUX builds yet, but maybe we have the same > problem there. Has anybody ever actually USED tooltalk on HPUX? If I recall correctly there have been similar problems on AIX. Not sure. Does anybody every use tooltalk nowadays? Workshop now uses this eserve stuff which is completely different isn't it? Jan

1 participants
0 comments

Re: zombies on Solaris 2.5[.1] with 21.1.3 25 years, 5 months

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > I believe this was also related to X11R6 (not openwin). Chuck had me > do a bunch of experiments. I don't remember the outcome, but it fixed > most of the problems. These are from after that. The problem you are referring to is probably the one in the PROBLEMS file (solution by Casper Dik). Jan

1 participants
0 comments

Re: zombies on Solaris 2.5[.1] with 21.1.3 25 years, 5 months

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: >> I seem to remember that there were some problems with zombie >> subprocesses on Solaris before. I couldn't find anything in the >> list-archives. Was this ever understood and fixed Jan> Something is eating the SIGCHLD's. Back then it seemed related Jan> to tooltalk+gcc (disabling tooltalk/workshop support has always solved it for Jan> me). However since I switched to 'cc' the problem also went away. Jan> That it also occurs with cc is new to me. I believe this was also related to X11R6 (not openwin). Chuck had me do a bunch of experiments. I don't remember the outcome, but it fixed most of the problems. Ray

1 participants
0 comments

Re: zombies on Solaris 2.5[.1] with 21.1.3 25 years, 5 months

Gunnar Evermann

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > I seem to remember that there were some problems with zombie > > subprocesses on Solaris before. I couldn't find anything in the > > list-archives. Was this ever understood and fixed > > Something is eating the SIGCHLD's. Back then it seemed related > to tooltalk+gcc (disabling tooltalk/workshop support has always solved it for > me). excellent hint -- thanks, Jan! I can now reproduce the problem from a vanilla xemacs, if no ttsession process is running on the machine. truss/dbx show that there are a couple of sigaction() calls from deep inside the libtt (apparently it forks and tries to execute something or other -- I didn't check in detail. These calls do NOT happen if a ttsession is running). All this is triggered by loading the tooltalk and the sunpro stuff and executing sunpro-startup. The original sigaction done by xemacs is: TRUSS> sigaction(SIGCLD, 0xEFFFF430, 0x0064DE3C) = 0 TRUSS> new: hand = 0xEF1B7D9C mask = 0 0 0 0 flags = 0x0000 TRUSS> old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x20000 the calls from inside libtt are: TRUSS> sigaction(SIGCLD, 0xEFFFD790, 0xEFFFD890) = 0 TRUSS> new: hand = 0x00000000 mask = 0 0 0 0 flags = 0x20012 TRUSS> old: hand = 0xEF1B7D9C mask = 0 0 0 0 flags = 0x0000 TRUSS> Received signal #18, SIGCLD, in waitid() [default] TRUSS> siginfo: SIGCLD CLD_EXITED pid=11826 status=0x007F TRUSS> sigaction(SIGCLD, 0xEFFFD790, 0xEFFFD890) = 0 TRUSS> new: hand = 0xEF1B7D9C mask = 0 0 0 0 flags = 0x20012 TRUSS> old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x20000 I think it's pretty obvious that libtt doesn't restore the old action correctly (i.e. it resets the handler but uses its own flags 0x20012 instead of the ones xemacs had originally installed 0x0000). from /usr/include/sys/signal.h these flags are: #define SA_NOCLDSTOP 0x00020000 /* don't send job control SIGCLD's */ #define SA_NODEFER 0x00000010 #define SA_RESETHAND 0x00000002 whatever that exactly means... I think this machine is not really up to date on patches, so maybe this was fixed by Sun at some point (any Sun employees reading this, who can peek at the libtt source to confirm/deny this?) So I suggest we reinitialise our handler again, if the tt_open() call in tooltalk.c has failed. Any comments? Gunnar P.S.: I haven't checked my HPUX builds yet, but maybe we have the same problem there. Has anybody ever actually USED tooltalk on HPUX? -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: Making docdir configurable 25 years, 5 months

Michael Sperber

>>>>> "GB" == giacomo boffi <giacomo.boffi(a)polimi.it> writes: GB> Michael Sperber [Mr. Preprocessor] writes: >> In the new framework I envision, it would probably be easier >> to optionally keep some sort of central-file database in synch >> with the actual package layout which in turn would save us a >> lot of stats. I know I won't be the one to implement it. GB> the same approach is held by different TeX distributions, using GB> the kpathsea library: GB> ---------------------------------------- from the info file ----- GB> [...] The library's fundamental purpose is to return a filename GB> from a list of directories specified by the user, similar to what GB> shells do when looking up program names to execute. GB> ----------------------------------------------------------------- No, this is fundamentally different as kpathsea is a low-level library operating at the file level. It is hugely bloated, buggy in some design aspects, and causes (if you use its directory-in-a-file feature) synchronization problems without end in practice. We've gone over kpathsea already numerous time for the job. For XEmacs, what's needed is something which works at the package level in a quite different way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 25 years, 5 months

SL Baur

Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes in xemacs-beta(a)xemacs.org: ... > As packages proliferate, you *will* need to be able to say thinks like: > "I'm the sysadmin, and user1 needs to use (require 'foobar '(atleast 3.8)) > but user2 insists on having a (require 'foobar '(exactly 3.7)) because > foobar 3.8 Breaks Really Badly if run with QuuzBaz 0.9.34. We have to do this now, assuming that XEmacs will continue to support not compiling in Mule. If this statement does not make any sense, please look at the new ps-print source code in the testing directory on the FTP site and image what XEmacs/NoMule will have to look like in order to take advantage of it, then imagine other common packages being rewritten in the same fashion. Or maybe no one cares and we can drop XEmacs/no-Mule entirely ... -- BEGIN chic and refined products for your urban single life. - found lurking on a Japanese microwave oven

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