23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

Started Emacs without any init functionality to confirm this
performance issue.

Visual operations (e.g. line down/up) are much, much slower than in
my last CVS build from 2 weeks ago.  There is a perceptible lag every
time I press up/down arrow for example.  I didn't see a way to compile
without multi-tty at the configure level to confirm the multi-tty
patch is the problem, but I suspect it.  It may be related that
(start-server) doesn't start the Emacs server.

Nonvisual operations, e.g. Gnus loading, are as fast as they were
before based on observation but no hard numbers.


In GNU Emacs 23.0.50.1 (i386-apple-darwin8.10.1, Carbon Version 1.6.0, multi-tty)
 of 2007-09-06 on tzz
Windowing system distributor `Apple Inc.', version 10.4.10
configured using `configure  '--enable-carbon-app' '--with-xpm' '--with-jpeg' '--with-png' 'CC=gcc''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  recentf-mode: t
  auto-image-file-mode: t
  cua-mode: t
  display-time-mode: t
  icomplete-mode: t
  image-tag-mode: t
  show-paren-mode: t
  which-function-mode: t
  auto-insert-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> <C-prior> <C-home> <C-home> <down-mouse-1> 
<mouse-2> <return> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <next> q c <down> 
<down> <down> c c <down> c c <down> c c <up> c l <down> 
<down> c <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> c <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
l <prior> <up> <up> <up> <up> <up> <up> <return> <return> 
SPC SPC SPC SPC i <down> <up> <end> <down> <down> <home> 
<end> <down> c <down> <down> <up> <up> <up> <up> <down> 
<down> <return> <down> <return> C-d C-d C-d C-d C-d 
C-d C-d C-d C-d C-d C-d C-d <next> q <down> <up> <up> 
<down> <return> c <return> c <down> <up> <return> c 
<return> <down> <end> <down> <down> <down> <return> 
i <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<up> <up> <up> <C-home> <down> <down> <down> <down> 
<down> <down> <end> <return> <up> <return> <C-home> 
<down> <up> <down> <down> <return> <down> <return> 
<prior> <prior> <escape> x r e p o r t - e m a c s 
- b u g <return>

Recent messages:
spam-split: calling the spam-check-BBDB function
spam-split: calling the spam-check-blacklist function
Auto-saving...done
Loading gnus-fun...done
Mark set
Loading bbdb-hooks...done
Hit C-g to stop BBDB from annotating.  5 of 5 addresses processed.
Loading bbdb-gui...done
Mark set
Loading emacsbug...done

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

I couldn't send the bug report by mail (smtpmail-send-it problems) and
posted via news (GMane).  Unfortunately I was in the wrong gmane
newsgroup, this should have gone to gmane.emacs.pretest.bugs.  Sorry.

I'm not sure if I should also post it to gmane.emacs.pretest.bugs, which
would generate more noise--please let me know if so.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Nick Roberts]

 > I couldn't send the bug report by mail (smtpmail-send-it problems) and
 > posted via news (GMane).  Unfortunately I was in the wrong gmane
 > newsgroup, this should have gone to gmane.emacs.pretest.bugs.  Sorry.
 > 
 > I'm not sure if I should also post it to gmane.emacs.pretest.bugs, which
 > would generate more noise--please let me know if so.

I think they're the same mailing list now.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > Started Emacs without any init functionality to confirm this
  > performance issue.
  > 
  > Visual operations (e.g. line down/up) are much, much slower than in
  > my last CVS build from 2 weeks ago.  There is a perceptible lag every
  > time I press up/down arrow for example.  I didn't see a way to compile
  > without multi-tty at the configure level to confirm the multi-tty
  > patch is the problem, but I suspect it.  It may be related that
  > (start-server) doesn't start the Emacs server.
  > 
  > Nonvisual operations, e.g. Gnus loading, are as fast as they were
  > before based on observation but no hard numbers.

This is a known problem (it has been reported before), unfortunately
nobody seems to care enough about that platform to try to fix it and
there is no active maintainer for it.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 07:14:54 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 

DN> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Started Emacs without any init functionality to confirm this
>> performance issue.
>> 
>> Visual operations (e.g. line down/up) are much, much slower than in
>> my last CVS build from 2 weeks ago.  There is a perceptible lag every
>> time I press up/down arrow for example.  I didn't see a way to compile
>> without multi-tty at the configure level to confirm the multi-tty
>> patch is the problem, but I suspect it.  It may be related that
>> (start-server) doesn't start the Emacs server.
>> 
>> Nonvisual operations, e.g. Gnus loading, are as fast as they were
>> before based on observation but no hard numbers.

DN> This is a known problem (it has been reported before), unfortunately
DN> nobody seems to care enough about that platform to try to fix it and
DN> there is no active maintainer for it.

If the problem appeared with the recent multi-tty merge, as I am
guessing, wouldn't it make sense to look at at least disabling that
functionality selectively as configure options?  I know very little
about MacOS Carbon development, but this seems like a nasty problem that
will hit lots of users.  Would Emacs 23 get released with such slow
visual performance?  I hope not.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > On Thu, 06 Sep 2007 07:14:54 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
  > 
  > DN> Ted Zlatanov <tzz@lifelogs.com> writes:
  > >> Started Emacs without any init functionality to confirm this
  > >> performance issue.
  > >> 
  > >> Visual operations (e.g. line down/up) are much, much slower than in
  > >> my last CVS build from 2 weeks ago.  There is a perceptible lag every
  > >> time I press up/down arrow for example.  I didn't see a way to compile
  > >> without multi-tty at the configure level to confirm the multi-tty
  > >> patch is the problem, but I suspect it.  It may be related that
  > >> (start-server) doesn't start the Emacs server.
  > >> 
  > >> Nonvisual operations, e.g. Gnus loading, are as fast as they were
  > >> before based on observation but no hard numbers.
  > 
  > DN> This is a known problem (it has been reported before), unfortunately
  > DN> nobody seems to care enough about that platform to try to fix it and
  > DN> there is no active maintainer for it.
  > 
  > If the problem appeared with the recent multi-tty merge, as I am
  > guessing, wouldn't it make sense to look at at least disabling that
  > functionality selectively as configure options?  

No, it would be much more complex that just simply fixing the mac
port. I think the input processing is simply not initialized
correctly/completely. My guess is that it would be a few lines of code
to fix this. But someone that cares about that platform would need to
do the work. 

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 09:10:09 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 

DN> No, it would be much more complex that just simply fixing the mac
DN> port. I think the input processing is simply not initialized
DN> correctly/completely. My guess is that it would be a few lines of code
DN> to fix this. But someone that cares about that platform would need to
DN> do the work. 

I think caring about MacOS shouldn't matter.  If the multi-tty merge
brought in input processing bugs that are only visible on MacOS, that
doesn't mean they are only happening on MacOS.  I have no knowledge of
the multi-tty merge, so I can't do this work, but I'll gladly test and
debug any fixes.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > On Thu, 06 Sep 2007 09:10:09 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
  > 
  > DN> No, it would be much more complex that just simply fixing the mac
  > DN> port. I think the input processing is simply not initialized
  > DN> correctly/completely. My guess is that it would be a few lines of code
  > DN> to fix this. But someone that cares about that platform would need to
  > DN> do the work. 
  > 
  > I think caring about MacOS shouldn't matter.  

Why not? Please explain. 

  > If the multi-tty merge brought in input processing bugs that are
  > only visible on MacOS, that doesn't mean they are only happening
  > on MacOS.

Can you please explain what are you implying here?

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 10:15:17 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 

DN> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 06 Sep 2007 09:10:09 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
>> 
DN> No, it would be much more complex that just simply fixing the mac
DN> port. I think the input processing is simply not initialized
DN> correctly/completely. My guess is that it would be a few lines of code
DN> to fix this. But someone that cares about that platform would need to
DN> do the work. 
>> 
>> I think caring about MacOS shouldn't matter.  

DN> Why not? Please explain. 

You said this was "more complex than just fixing the mac port."  I
understood it to mean that this is not necessarily just a MacOS bug, and
thus should not matter only to those who care about MacOS.  If I
misunderstood, sorry.  Also see below.

>> If the multi-tty merge brought in input processing bugs that are
>> only visible on MacOS, that doesn't mean they are only happening
>> on MacOS.

DN> Can you please explain what are you implying here?

Just because *any* bug only shows up on MacOS doesn't necessarily mean
it only happens on MacOS, or that it only matters on MacOS.  You seem to
be saying that is the case for this particular bug.  I'm sure you know
the internals much better than me, but you haven't said that it's known
to only matter on MacOS so I'm not assuming it.  You said it was
reported before, that's all.  I actually couldn't find that previous bug
report, so if you could point me to it I'd appreciate it.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > On Thu, 06 Sep 2007 10:15:17 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
  > 
  > DN> Ted Zlatanov <tzz@lifelogs.com> writes:
  > >> On Thu, 06 Sep 2007 09:10:09 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
  > 
  > >> If the multi-tty merge brought in input processing bugs that are
  > >> only visible on MacOS, that doesn't mean they are only happening
  > >> on MacOS.
  > 
  > DN> Can you please explain what are you implying here?
  > 
  > Just because *any* bug only shows up on MacOS doesn't necessarily mean
  > it only happens on MacOS, or that it only matters on MacOS.  

In abstract yes, but this sound like splitting hairs to me. So IMHO
continuing to discuss along those lines is not very useful.

  > You seem to be saying that is the case for this particular bug.  

Yep, given that multi-tty works just fine on Windows and X11, I have
no reason to believe that this is not just a mac issue.

  > I'm sure you know the internals much better than me, but you        

I only have a bit more knowledge because I worked a bit on the code,
but the only person that actually knows and understands the whole
multi-tty design is Karoly Lorentey. 

  > but you haven't said that it's known to only matter on MacOS so I'm not
  > assuming it.  You said it was reported before, that's all.  

I am sorry I wasn't more clear, my intention was to say that this was
actually a mac problem.

  > I actually couldn't find that previous bug report, so if you could
  > point me to it I'd appreciate it.

Look for a long thread in the past few weeks with the subject
"CVS HEAD fails to build on OSX 10.4"

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 

DN> Look for a long thread in the past few weeks with the subject
DN> "CVS HEAD fails to build on OSX 10.4"

I looked at the thread more carefully.  Chad Brown reported a very
specific issue exactly like the one I experienced, with the symptom
being that keypresses are handled very slowly, but he couldn't debug it
further because Emacs crashed.  Mitsuharu commented in the thread:

> 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.

Mitsuharu, can you tell us if you think this problem can be solved
easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd like
to have something that works in the CVS Emacs for MacOS users.  Can we
just reintroduce that FD_SET call, or will that break other things?
Should we increase the frequency of the SIGALRM polling instead?

If Karoly Lorentey is around, maybe we can get their comments as well.

Thanks
Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
>
> DN> Look for a long thread in the past few weeks with the subject
> DN> "CVS HEAD fails to build on OSX 10.4"
>
> I looked at the thread more carefully.  Chad Brown reported a very
> specific issue exactly like the one I experienced, with the symptom
> being that keypresses are handled very slowly, but he couldn't debug
> it further because Emacs crashed.  Mitsuharu commented in the
> thread:
>
>> 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.
>
> Mitsuharu, can you tell us if you think this problem can be solved
> easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd
> like to have something that works in the CVS Emacs for MacOS users.
> Can we just reintroduce that FD_SET call, or will that break other
> things?

The respective patch says:

-------------------------------- src/process.c --------------------------------
index a129195..bd12f3e 100644
@@ -138,11 +138,11 @@ Boston, MA 02110-1301, USA.  */
 #include "charset.h"
 #include "coding.h"
 #include "process.h"
+#include "frame.h"
 #include "termhooks.h"
 #include "termopts.h"
 #include "commands.h"
 #include "keyboard.h"
-#include "frame.h"
 #include "blockinput.h"
 #include "dispextern.h"
 #include "composite.h"
@@ -328,11 +328,11 @@ extern int timers_run;
 
 static SELECT_TYPE input_wait_mask;
 
-/* Mask that excludes keyboard input descriptor (s).  */
+/* Mask that excludes keyboard input descriptor(s).  */
 
 static SELECT_TYPE non_keyboard_wait_mask;
 
-/* Mask that excludes process input descriptor (s).  */
+/* Mask that excludes process input descriptor(s).  */
 
 static SELECT_TYPE non_process_wait_mask;
 
@@ -3158,6 +3158,10 @@ usage: (make-network-process &rest ARGS)  */)
 
  open_socket:
 
+#ifdef __ultrix__
+  /* Previously this was compiled unconditionally, but that seems
+     unnecessary on modern systems, and `unrequest_sigio' was a noop
+     under X anyway. --lorentey */
   /* Kernel bugs (on Ultrix at least) cause lossage (not just EINTR)
      when connect is interrupted.  So let's not let it get interrupted.
      Note we do not turn off polling, because polling is only used
@@ -3174,6 +3178,7 @@ usage: (make-network-process &rest ARGS)  */)
       record_unwind_protect (unwind_request_sigio, Qnil);
       unrequest_sigio ();
     }
+#endif
 
   /* Do this in case we never enter the for-loop below.  */
   count1 = SPECPDL_INDEX ();
@@ -6958,20 +6963,12 @@ DEFUN ("process-filter-multibyte-p", Fprocess_filter_multibyte_p,
 
 
 \f
-/* The first time this is called, assume keyboard input comes from DESC
-   instead of from where we used to expect it.
-   Subsequent calls mean assume input keyboard can come from DESC
-   in addition to other places.  */
-
-static int add_keyboard_wait_descriptor_called_flag;
+/* Add DESC to the set of keyboard input descriptors.  */
 
 void
 add_keyboard_wait_descriptor (desc)
      int desc;
 {
-  if (! add_keyboard_wait_descriptor_called_flag)
-    FD_CLR (0, &input_wait_mask);
-  add_keyboard_wait_descriptor_called_flag = 1;
   FD_SET (desc, &input_wait_mask);
   FD_SET (desc, &non_process_wait_mask);
   if (desc > max_keyboard_desc)
@@ -7043,7 +7040,12 @@ init_process ()
   process_output_skip = 0;
 #endif
 
+  /* 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
 
   Vprocess_alist = Qnil;
 #ifdef SIGCHLD



So it might be that "the display method should call
add_keyboard_wait_descriptor on stdin".  Maybe the respective code
doing that did not make it into the multi-tty branch?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
  > 
  > DN> Look for a long thread in the past few weeks with the subject
  > DN> "CVS HEAD fails to build on OSX 10.4"
  > 
  > I looked at the thread more carefully.  Chad Brown reported a very
  > specific issue exactly like the one I experienced, with the symptom
  > being that keypresses are handled very slowly, but he couldn't debug it
  > further because Emacs crashed.  Mitsuharu commented in the thread:
  > 
  > > 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.
  > 
  > Mitsuharu, can you tell us if you think this problem can be solved
  > easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd like
  > to have something that works in the CVS Emacs for MacOS users.  Can we
  > just reintroduce that FD_SET call, or will that break other things?
  > Should we increase the frequency of the SIGALRM polling instead?

Can you try to do what the comment in the code says: add a call to
add_keyboard_wait_descriptor? Probably mac_term_init is the place to
do that. 

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 485 bytes --]

Ted Zlatanov wrote:
>> 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.
>>     
>
> Mitsuharu, can you tell us if you think this problem can be solved
> easily?

The problem can be solved by calling add_keyboard_wait_descriptor in the
mac terminal setup function.


[-- Attachment #1.2: Type: text/html, Size: 869 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 13:16:32 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 

DN> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
>> 
DN> Look for a long thread in the past few weeks with the subject
DN> "CVS HEAD fails to build on OSX 10.4"
>> 
>> I looked at the thread more carefully.  Chad Brown reported a very
>> specific issue exactly like the one I experienced, with the symptom
>> being that keypresses are handled very slowly, but he couldn't debug it
>> further because Emacs crashed.  Mitsuharu commented in the thread:
>> 
>> > 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.
>> 
>> Mitsuharu, can you tell us if you think this problem can be solved
>> easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd like
>> to have something that works in the CVS Emacs for MacOS users.  Can we
>> just reintroduce that FD_SET call, or will that break other things?
>> Should we increase the frequency of the SIGALRM polling instead?

DN> Can you try to do what the comment in the code says: add a call to
DN> add_keyboard_wait_descriptor? Probably mac_term_init is the place to
DN> do that. 

I added:

  int desc = 0;
  printf("Setting up FD %d\n", desc);
  /* replacing the call FD_SET (0, &input_wait_mask) from process.c */
  add_keyboard_wait_descriptor(desc);

before, during, and after the BLOCK_INPUT/UNBLOCK_INPUT portion, and it
didn't help.  Input was still very slow.  I put in the printf to be sure
the function was running.  If I'm missing something, let me know please.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Richard Stallman]

    If the problem appeared with the recent multi-tty merge, as I am
    guessing, wouldn't it make sense to look at at least disabling that
    functionality selectively as configure options?

It makes no sense to create a configure option just because right now
there is a bug.  The thing to do is fix the bug.

MacOS is not highest priority for us, but there are people that want
to support it, and I expect they will fix the bug sooner or later.
You can help debug it, if it is important to you.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Thu, 06 Sep 2007 21:45:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 06 Sep 2007 13:16:32 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
DN> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
>>> 
DN> Look for a long thread in the past few weeks with the subject
DN> "CVS HEAD fails to build on OSX 10.4"
>>> 
>>> I looked at the thread more carefully.  Chad Brown reported a very
>>> specific issue exactly like the one I experienced, with the symptom
>>> being that keypresses are handled very slowly, but he couldn't debug it
>>> further because Emacs crashed.  Mitsuharu commented in the thread:
>>> 
>>> > 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.
>>> 
>>> Mitsuharu, can you tell us if you think this problem can be solved
>>> easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd like
>>> to have something that works in the CVS Emacs for MacOS users.  Can we
>>> just reintroduce that FD_SET call, or will that break other things?
>>> Should we increase the frequency of the SIGALRM polling instead?

DN> Can you try to do what the comment in the code says: add a call to
DN> add_keyboard_wait_descriptor? Probably mac_term_init is the place to
DN> do that. 

TZ> I added:

TZ>   int desc = 0;
TZ>   printf("Setting up FD %d\n", desc);
TZ>   /* replacing the call FD_SET (0, &input_wait_mask) from process.c */
TZ>   add_keyboard_wait_descriptor(desc);

TZ> before, during, and after the BLOCK_INPUT/UNBLOCK_INPUT portion, and it
TZ> didn't help.  Input was still very slow.  I put in the printf to be sure
TZ> the function was running.  If I'm missing something, let me know please.

Anyone with new suggestions?  Am I doing add_keyboard_wait_descriptor()
in the right place?  Should I do multiple calls?  Can we look at
increasing the SIGALRM frequency as a workaround?

Thanks
Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Mon, 10 Sep 2007 09:12:38 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 06 Sep 2007 21:45:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> On Thu, 06 Sep 2007 13:16:32 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
DN> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
>>>> 
DN> Look for a long thread in the past few weeks with the subject
DN> "CVS HEAD fails to build on OSX 10.4"
>>>> 
>>>> I looked at the thread more carefully.  Chad Brown reported a very
>>>> specific issue exactly like the one I experienced, with the symptom
>>>> being that keypresses are handled very slowly, but he couldn't debug it
>>>> further because Emacs crashed.  Mitsuharu commented in the thread:
>>>> 
>>>> > 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.
>>>> 
>>>> Mitsuharu, can you tell us if you think this problem can be solved
>>>> easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd like
>>>> to have something that works in the CVS Emacs for MacOS users.  Can we
>>>> just reintroduce that FD_SET call, or will that break other things?
>>>> Should we increase the frequency of the SIGALRM polling instead?

DN> Can you try to do what the comment in the code says: add a call to
DN> add_keyboard_wait_descriptor? Probably mac_term_init is the place to
DN> do that. 

TZ> I added:

TZ> int desc = 0;
TZ> printf("Setting up FD %d\n", desc);
TZ> /* replacing the call FD_SET (0, &input_wait_mask) from process.c */
TZ> add_keyboard_wait_descriptor(desc);

TZ> before, during, and after the BLOCK_INPUT/UNBLOCK_INPUT portion, and it
TZ> didn't help.  Input was still very slow.  I put in the printf to be sure
TZ> the function was running.  If I'm missing something, let me know please.

TZ> Anyone with new suggestions?  Am I doing add_keyboard_wait_descriptor()
TZ> in the right place?  Should I do multiple calls?  Can we look at
TZ> increasing the SIGALRM frequency as a workaround?

Hi,

it's been two weeks and no one has suggested a fix for this issue.
Despite some discussion on external Emacs Cocoa/Carbon ports, there was
no consensus (as far as I am aware) on what the Emacs project itself
will do about the currently broken Cocoa build.

I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
the Emacs project can't run reliably there in a graphical mode; the text
mode build can continue to work normally.  The problem should also be
documented in case someone with interest can fix it.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Jason Rumney]

Ted Zlatanov wrote:
> I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
> the Emacs project can't run reliably there in a graphical mode;
How will disabling a GUI framework help improve it? Code in CVS is
development code, if you want a 100% stable version of Emacs, use 21.1

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Tue, 25 Sep 2007 16:03:36 +0100 Jason Rumney <jasonr@gnu.org> wrote: 

JR> Ted Zlatanov wrote:
>> I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
>> the Emacs project can't run reliably there in a graphical mode;
JR> How will disabling a GUI framework help improve it? Code in CVS is
JR> development code, if you want a 100% stable version of Emacs, use 21.1

I am not looking for stability.  The current Cocoa port is *unusable*
and *unmaintained* (to the best of my knowledge) which is a very
different thing from unstable and the reason I'm trying to bring up this
issue again after 2 weeks of silence on the subject.  I'd fix it myself
if I could, but I need at least some help (I posted on that earlier in
the thread) and none has been offered on the emacs-devel list since my
attempt 2 weeks ago.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Tue, 25 Sep 2007 11:53:45 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 25 Sep 2007 16:03:36 +0100 Jason Rumney <jasonr@gnu.org> wrote: 
JR> Ted Zlatanov wrote:
>>> I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
>>> the Emacs project can't run reliably there in a graphical mode;
JR> How will disabling a GUI framework help improve it? Code in CVS is
JR> development code, if you want a 100% stable version of Emacs, use 21.1

TZ> I am not looking for stability.  The current Cocoa port is *unusable*
TZ> and *unmaintained* (to the best of my knowledge) which is a very
TZ> different thing from unstable and the reason I'm trying to bring up this
TZ> issue again after 2 weeks of silence on the subject.  I'd fix it myself
TZ> if I could, but I need at least some help (I posted on that earlier in
TZ> the thread) and none has been offered on the emacs-devel list since my
TZ> attempt 2 weeks ago.

s/Cocoa/Carbon/g, my mistake.  Sorry.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Jason Rumney]

Ted Zlatanov wrote:
> I am not looking for stability.  The current Cocoa port is *unusable*
>   

You do mean Carbon, don't you? The Cocoa/GNUstep port is not yet merged.
I think if we disable it now, it will never be revived, even if someone
later comes forward who can maintain it. It's maybe better to leave our
options open at this stage, at least until the Cocoa/GNUstep work is
merged. The VMS code was unmaintained for years before we finally
disabled and removed it.

> and *unmaintained* (to the best of my knowledge) which is a very
> different thing from unstable and the reason I'm trying to bring up this
> issue again after 2 weeks of silence on the subject.  I'd fix it myself
> if I could, but I need at least some help (I posted on that earlier in
> the thread) and none has been offered on the emacs-devel list since my
> attempt 2 weeks ago.
>   

I don't think anyone feels qualified to make an open offer of general
help. But if you post specific issues here, then people may be able to
help you on a case-by-case basis. I have been through the pain of
getting the Windows port working after the multi-tty merge, and the
former Carbon maintainer may still be reading the list if you need OSX
specific help. The multi-tty code and design is currently poorly
understood, but that is a general problem, not an OSX specific one.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Tue, 25 Sep 2007 21:43:51 +0100 Jason Rumney <jasonr@gnu.org> wrote: 

JR> Ted Zlatanov wrote:
>> I am not looking for stability.  The current Cocoa port is *unusable*

JR> You do mean Carbon, don't you? The Cocoa/GNUstep port is not yet
JR> merged.

Yes, I posted a correction.  I'm definitely not a MacOS developer :)

JR> I think if we disable it now, it will never be revived, even if someone
JR> later comes forward who can maintain it. It's maybe better to leave our
JR> options open at this stage, at least until the Cocoa/GNUstep work is
JR> merged. The VMS code was unmaintained for years before we finally
JR> disabled and removed it.

I understand.  Would it be possible to at least tell users "the Carbon
port has performance issues" in the docs?  It's truly unusable at this
point.

>> and *unmaintained* (to the best of my knowledge) which is a very
>> different thing from unstable and the reason I'm trying to bring up this
>> issue again after 2 weeks of silence on the subject.  I'd fix it myself
>> if I could, but I need at least some help (I posted on that earlier in
>> the thread) and none has been offered on the emacs-devel list since my
>> attempt 2 weeks ago.
>> 

JR> I don't think anyone feels qualified to make an open offer of general
JR> help. But if you post specific issues here, then people may be able to
JR> help you on a case-by-case basis. I have been through the pain of
JR> getting the Windows port working after the multi-tty merge, and the
JR> former Carbon maintainer may still be reading the list if you need OSX
JR> specific help. The multi-tty code and design is currently poorly
JR> understood, but that is a general problem, not an OSX specific one.

There's a single specific issue: interactively, Emacs is unusable in the
Carbon port.  Matsuharu gave a hint for fixing it (see my earlier post).
I tried what he said and it didn't work; no one has been interested in
helping me further.  I can re-summarize in a separate post if you think
it will help.

Thank you for discussing this with me.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 25 Sep 2007 15:58:28 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

> There's a single specific issue: interactively, Emacs is unusable in
> the Carbon port.  Matsuharu gave a hint for fixing it (see my
> earlier post).  I tried what he said and it didn't work;

It's neither a hint nor a sufficient condition for the Carbon port
with multi-tty to work, but a necessary condition.  Absence of the
necessary condition was enough to show that multi-tty Carbon has not
worked properly since its beginning, i.e., the non-functioning is not
due to the later syncs with the trunk to the multi-tty branch.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Ted Zlatanov <tzz@lifelogs.com> writes:

  > On Tue, 25 Sep 2007 16:03:36 +0100 Jason Rumney <jasonr@gnu.org> wrote: 
  > 
  > JR> Ted Zlatanov wrote:
  > >> I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
  > >> the Emacs project can't run reliably there in a graphical mode;
  > JR> How will disabling a GUI framework help improve it? Code in CVS is
  > JR> development code, if you want a 100% stable version of Emacs, use 21.1
  > 
  > I am not looking for stability.  The current Cocoa port is *unusable*
  > and *unmaintained* (to the best of my knowledge) which is a very
  > different thing from unstable and the reason I'm trying to bring up this
  > issue again after 2 weeks of silence on the subject.  I'd fix it myself
  > if I could, but I need at least some help (I posted on that earlier in
  > the thread) and none has been offered on the emacs-devel list since my
  > attempt 2 weeks ago.

I'd try to compare the code in mac_term_init and Fx_create_frame to
the similar code for X11 and Windows and see if you can find anything
that is missing... Hope this helps. 

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Dan Nicolaescu]

Jason Rumney <jasonr@gnu.org> writes:

  > merged. The VMS code was unmaintained for years before we finally
  > disabled and removed it.

Was there decision to remove VMS? There's still a ton of VMS
#ifdefs... in emacs/src/*

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Jason Rumney]

Dan Nicolaescu wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>   > merged. The VMS code was unmaintained for years before we finally
>   > disabled and removed it.
>
> Was there decision to remove VMS? There's still a ton of VMS
> #ifdefs... in emacs/src/*
>   

The vms subdirectory was removed. But maybe that was due to changes in
the VMS build.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Jason Rumney]

Jason Rumney wrote:
> Dan Nicolaescu wrote:
>   
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>   > merged. The VMS code was unmaintained for years before we finally
>>   > disabled and removed it.
>>
>> Was there decision to remove VMS? There's still a ton of VMS
>> #ifdefs... in emacs/src/*
>>   
>>     
>
> The vms subdirectory was removed.
Sorry, I was mistaken. I thought there used to be much more in the vms
subdirectory, but savannah does not show anything in the Attic.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Eli Zaretskii]

> Date: Wed, 26 Sep 2007 08:44:10 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Ted Zlatanov <tzz@lifelogs.com>, emacs-devel@gnu.org
> 
> Jason Rumney wrote:
> > Dan Nicolaescu wrote:
> >   
> >> Jason Rumney <jasonr@gnu.org> writes:
> >>
> >>   > merged. The VMS code was unmaintained for years before we finally
> >>   > disabled and removed it.
> >>
> >> Was there decision to remove VMS? There's still a ton of VMS
> >> #ifdefs... in emacs/src/*
> >>   
> >>     
> >
> > The vms subdirectory was removed.
> Sorry, I was mistaken. I thought there used to be much more in the vms
> subdirectory, but savannah does not show anything in the Attic.

Nevertheless, your recollections are right: the removal of various
VMS-related parts in the code was requested several times, but it was
always rejected, even though the VMS build was clearly unmaintained.
We did NOT remove the VMS directory precisely for that reason.

Personally, I find it disturbing that many Free Software projects
consider removing bit-rotting builds too easily.  I like the fact that
Emacs is a notable exception from this rule.  So I don't think we
should remove the Mac build in question so quickly and so easily.

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Wed, 26 Sep 2007 08:50:22 +0900 (JST) YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Tue, 25 Sep 2007 15:58:28 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
>> There's a single specific issue: interactively, Emacs is unusable in
>> the Carbon port.  Matsuharu gave a hint for fixing it (see my
>> earlier post).  I tried what he said and it didn't work;

YM> It's neither a hint nor a sufficient condition for the Carbon port
YM> with multi-tty to work, but a necessary condition.  Absence of the
YM> necessary condition was enough to show that multi-tty Carbon has not
YM> worked properly since its beginning, i.e., the non-functioning is not
YM> due to the later syncs with the trunk to the multi-tty branch.

Thank you for the clarification.  I appreciate your assistance.

Ted

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

[Ted Zlatanov]

On Wed, 26 Sep 2007 11:19:47 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Personally, I find it disturbing that many Free Software projects
EZ> consider removing bit-rotting builds too easily.  I like the fact that
EZ> Emacs is a notable exception from this rule.  So I don't think we
EZ> should remove the Mac build in question so quickly and so easily.

I did not suggest removal, only disabling or documenting the Carbon
port.  Documenting would at least tell users that it's unusable
interactively and that help is needed.  I also did not suggest it should
be quick or easy :)

Ted