emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)


From: YAMAMOTO Mitsuharu
Subject: Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)
Date: Fri, 31 Aug 2007 19:04:00 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 31 Aug 2007 01:12:38 -0700, Dan Nicolaescu <address@hidden> said:

> YAMAMOTO Mitsuharu <address@hidden> writes:
>> >>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu <address@hidden> 
>> >>>>> said:
>> 
>> >> It works in terminal mode, but fails to launch in carbon mode. :(
>> 
>> > It used to do at least that much when I did the mac multi-tty port
>> > back in May. A lot of things seem to have changed in CVS for the mac
>> > since then.
>> 
>> Now I can hardly believe that.  I couldn't find any calls to
>> add_keyboard_wait_descriptor in the past macterm.c in the multi-tty
>> branch despite the comment in process.c below:
>> 
>> /* Don't do this, it caused infinite select loops.  The display
>> method should call add_keyboard_wait_descriptor on stdin if it
>> needs that.  */
>> #if 0
>> FD_SET (0, &input_wait_mask);
>> #endif
>> 
>> I seriously suspect you ran a wrong (i.e., non multi-tty) executable.

> I am not sure what your intention is with this. I don't think I had a
> multi-tty executable around.

As multi-tty no longer does `FD_SET (0, &input_wait_mask)' in
process.c, if no `add_keyboard_wait_descriptor' calls are made, then
Carbon Emacs reads events from the window system only rarely via
polling with SIGALRM and becomes very unresponsive as reported.  I
couldn't imagine that you weren't aware of such a noticeable
deficiency when you tested it, so I suspected you ran a different
executable.

> When I did that work I clearly stated that I did only minimal
> testing. For the record here's what that meant:
> -bootstrap with --without-carbon --with-x11, make sure it works
> -configure --with-carbon
> -make (no rebootstrap, I kept the byte compiled files)
> -check that  emacs -nw starts up (don't remember what I had to do to
> make it work, mainly it was compilation fixes for new interfaces)
> -hack until a carbon frame is displayed, run emacs -f server-start,
> check that emacsclient and emacsclient -t can connect to it.

So you didn't type any commands in a Carbon frame.  Then it is very
likely that the current Carbon port is actually as unresponsive as the
one you tested in May.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]