August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Crash] gnuclient -nw 26 years, 3 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > The Unix environment more than likely isn't unless you have been > really, really careful. I'm constantly running into differences. At least in the 20.4 case I mentioned we explicitly verified that. The only difference between the xterm case output of env and that under the window maneager was TERM and WINDOWID... I am suspecting it is something in the state of the filedesc (buffering settingss?) that XEmacs inherits from the WM. Jan

1 participants
0 comments

Re: [Off Topic] Re: Reconciling Emacs Lisp and Scheme 26 years, 3 months

Michael Sperber

>>>>> "Didier" == Didier Verna <verna(a)inf.enst.fr> writes: Didier> OK. What I mean is that I have multiple Posix threads Didier> created with pthread_create (), and those threads are likely Didier> to perform (in parallel) calls to `Eval' on scheme procedure Didier> objects (those calls are made from C). My question was to know Didier> if it's safe or ot in the case where no global object is Didier> involved. Absolutely not. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [Off Topic] Re: Reconciling Emacs Lisp and Scheme 26 years, 3 months

Didier Verna

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: [ I'll change my attribution. It's boring. ] > >> Elk is not thread-safe and it does not provide a thread library. > > Didier> Does this mean that I can't safely have different threads calling > Didier> scheme functions in parallel, even if those functions don't use or > affect Didier> global objects ? > > Again, specify what you mean by "thread" and I'll give you an answer. > Unless I'm missing something in your question, the answer is always > "no," however. OK. What I mean is that I have multiple Posix threads created with pthread_create (), and those threads are likely to perform (in parallel) calls to `Eval' on scheme procedure objects (those calls are made from C). My question was to know if it's safe or ot in the case where no global object is involved.

1 participants
0 comments

Re: font lock faces ugly 26 years, 3 months

Didier Verna

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > I'd like there to be a site-wide options.el file, similar to the > site-start.el. I think that's a good idea. --didier

1 participants
0 comments

Re: [Crash] gnuclient -nw 26 years, 3 months

Karl M. Hegbloom

>>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> Well, I've just built gpm-1.14, [...] Where did you download that?

1 participants
0 comments

Re: [Off Topic] Re: Reconciling Emacs Lisp and Scheme 26 years, 3 months

Michael Sperber

>>>>> "Didier" == Didier Verna <verna(a)inf.enst.fr> writes: Didier> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Didier> and seems to be usable in multi-threaded apps. >> >> I don't know what you mean by this, but it's wrong by almost any >> definition. Didier> In Elk, the garbadge collector acts ala emacs: you inform it Didier> explicitely of any objects that should be protected with GC_Link(). Even if Didier> it's a PITA to have to protect by hand the scheme objects, the advantage is Didier> that different threads can create and protect scheme objects easily. On the Didier> contrary, there's no explicit GC protection in guile. Consequently, guile will Didier> know only the main program stack and objects created by subsequent threads Didier> won't be caugth by the GC. You really need to say what you mean by "thread." If you mean threads of the underlying C library or the OS, then the GC protection mechanism doesn't help you much, because it's not thread-safe itself. It doesn't perform any synchronization whatsoever. If you're talking about threads as provided Elk---well, there aren't any. >> Elk is not thread-safe and it does not provide a thread library. Didier> Does this mean that I can't safely have different threads calling Didier> scheme functions in parallel, even if those functions don't use or affect Didier> global objects ? Again, specify what you mean by "thread" and I'll give you an answer. Unless I'm missing something in your question, the answer is always "no," however. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: font lock faces ugly 26 years, 3 months

Karl M. Hegbloom

I'd like there to be a site-wide options.el file, similar to the site-start.el. The default faces could all be set up in that, and optionally dumped in... Root could set up a site wide default setup there, and users could override them. Would it take a lot of work to do that, I wonder? (when will I learn not to suggest things like this when I have limited time to perform the labor.)

1 participants
0 comments

Re: [Off Topic] Re: Reconciling Emacs Lisp and Scheme 26 years, 3 months

Didier Verna

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Didier> and seems to be usable in multi-threaded apps. > > I don't know what you mean by this, but it's wrong by almost any > definition. In Elk, the garbadge collector acts ala emacs: you inform it explicitely of any objects that should be protected with GC_Link(). Even if it's a PITA to have to protect by hand the scheme objects, the advantage is that different threads can create and protect scheme objects easily. On the contrary, there's no explicit GC protection in guile. Consequently, guile will know only the main program stack and objects created by subsequent threads won't be caugth by the GC. > Elk is not thread-safe and it does not provide a thread library. Does this mean that I can't safely have different threads calling scheme functions in parallel, even if those functions don't use or affect global objects ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: [21.2] gnuserv doesn't exit when xemacs exits 26 years, 3 months

Jan Vroonhof

[AAAAARGGHHHH... Yet another I started XEmacs from my WM problem, it must be the heat wave.] giacomo boffi <boffi(a)rachele.stru.polimi.it> writes: > 1. let my WM (gwm) start xemacs like this > > xemacs -f gnuserv-start > > 2. exit xemacs > > 3. observe a gnuserv process that eats up to 95% of cpu Please attach 'strace' to gnuserv to see what it is doing just before and after XEmacs is exited. P.S. What happends when you just do 'xemacs' from your WM and then M-x gnuserv-start. P.P.S. What happens when you use 'xemacs -f gnuserv-start <somefile >someotherfile 2>&1' And what happens if you use this script (possibly from an xterm) #!/usr/bin/perl close STDOUT; close STDIN; close STDERR; exec "xemacs","-f","gnuserv-start"

2 participants
1 comments

Re: [Off Topic] Re: Reconciling Emacs Lisp and Scheme 26 years, 3 months

Michael Sperber

>>>>> "Didier" == Didier Verna <verna(a)inf.enst.fr> writes: Didier> Speaking about that, does anybody have experience in both Guile and Didier> Elk ? I'd be interested in a comparison. For what I can see now, Elk is very Didier> well documented, has usefull extensions like unix (syscalls) and X11, I did a lot of work with Elk in the 2.x releases. The code is indeed mature and well-documented. Especially the interface to C is very well thought-out, and light years beyond what Guile provides. Moreover, it does precise garbage collection. Elk is considerably slower than SCM, and most other Scheme implementations. I don't know how it compares to Guile which is also slower than SCM. Didier> and seems to be usable in multi-threaded apps. I don't know what you mean by this, but it's wrong by almost any definition. Elk is not thread-safe and it does not provide a thread library. Didier> The lastest release occured last year though. Actually, the latest release was in 1996. Some minor patches have accumulated, but that's about all. Elk development is pretty much dead, and there's just too much stuff missing. I'm afraid it's not a very viable candidate for us.- Didier> On the contrary, guile seems far less mature, not very clean, Didier> and the documentation is completely out-of-date. Maybe it's Didier> just August, but the guys on the mailing list seem very closed Didier> on themselve. I'm wondering how they can expect more people to Didier> get involved in guile development under those conditions. Tell me about it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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 August 1998