emacs-devel
[Top][All Lists]
Advanced

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

Re: Carbon port and multi-tty


From: Dan Nicolaescu
Subject: Re: Carbon port and multi-tty
Date: Wed, 07 May 2008 18:03:40 -0700

YAMAMOTO Mitsuharu <address@hidden> writes:

  > >>>>> On Wed, 07 May 2008 00:15:52 -0700, Dan Nicolaescu <address@hidden> 
said:
  > 
  > > YAMAMOTO Mitsuharu <address@hidden> writes:
  > >> >>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu
  > >> <address@hidden> said:
  > >> 
  > >> >> The bug introduced by this change is mentioned here: >>
  > >> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
  > >> 
  > >> > OK, a 1 line change (in a ~1000 lines patch) that you seemed to
  > >> have > known about for a while.
  > >> 
  > >> 1-line change can introduce a nasty bug as actually seen in this
  > >> case.  And this could be easily avoided by not changing the part
  > >> that is unrelated to multi-tty.
  > 
  > > And it would have been easily fixed, like all other bugs in emacs,
  > > had the platform not been declared unmaintained the moment the patch
  > > came out.  Not saying that without the patch the code would not even
  > > compile.  Not mentioning that you could have simply fixed it without
  > > causing all this racket.
  > 
  > Again, I'm saying about mixing unrelated changes, not this particular
  > single-line bug.  Please don't understate the problem.

You keep repeating the same thing over and over.  We heard you the first
time, and nobody agreed.

We have all realized by now that you are making a mountain out of a mole hill.

This code has been in CVS for a year, you have made a choice to neither
undo it, nor move a single finger to make it completely functional.  
The fact that you have known about a one line bug for 4 months and chose
not to fix it, but instead create all this commotion did not win you any
friends.

You have already been told by the 2 head Emacs maintainers: "If you're 
disturbed by
the remaining problems on Carbon, please try working on a fix instead of
complaining." "If you can do better, show us.  Otherwise, please stop 
complaining"

PLEASE STOP WASTING OUR TIME.

  > And about this ChangeLog entry:
  > 
  > 2008-05-07  Dan Nicolaescu  <address@hidden>
  > 
  >     * macfns.c (Fx_create_frame): Make a copy of frame parameters
  >     because the original parameters are in pure storage now.
  > 
  > The primary purpose of the copying is not for the parameters allocated
  > in the pure storage, but to prepare for frame parameter clearing in
  > x_get_arg.

This is the same ChangeLog used by Martin Rudalics to fix a similar
problem that was discovered by Juanma Barranquero that manifested itself
by trying to write to pure storage.




reply via email to

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