-getRed:green:blue:alpha: not defined for the NSColor

-getRed:green:blue:alpha: not defined for the NSColor

[Keith David Bershatsky]

I have several older Apple machines running OSX 10.6.8 and only one newer machines with El Capitan (which I no longer use for a variety of reasons).  Between the dates of 04/08/2019 and 07/10/2019, change(s) to the master branch broke the ability to use Emacs.  I get a welcome screen and gdb spams me with the following messages:

2019-07-12 14:36:27.976 Emacs[74347:60f] *** -getRed:green:blue:alpha: not defined for the NSColor NSCustomColorSpace Device RGB colorspace 0 0 0 1; need to first convert colorspace.

If possible, it would be wonderful if Emacs master branch could still support users with older computers running outdated operating systems; e.g., OSX 10.6.8.

If support for OSX 10.6.8 is no longer possible, then it would be greatly appreciated if someone can please point me to which commit(s) created this issue and some advice regarding how I can at least fix it on my end.  The average Emacs build time is in excess of 30 minutes due to all the byte-compiling and it would likely take me a very long time to locate the commit by trial and error; e.g., building various versions of Emacs from 04/08/2019 to the present until the culprit is located.

My build options are as follows:

CFLAGS='-Wall -O0 -g3' ./configure \
--with-ns \
--enable-checking='yes,glyphs' \
--enable-check-lisp-object-type \
--without-compress-install \
--without-makeinfo \
--with-gnutls=no \
--with-mailutils \
--without-makeinfo

Thanks,

Keith

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Paul Eggert]

Keith David Bershatsky wrote:

> it would likely take me a very long time to locate the commit by trial and error; e.g., building various versions of Emacs from 04/08/2019 to the present until the culprit is located.

You can use binary search, so this is only O(log N).

You could also take a look at commits 2019-04-02T20:49:36Z!alan@idiocy.org 
(9624f609493da7c08016ba00d6895bad0fe26a0e) and the flurry of commits near 
2019-04-14T02:41:31!agrambot@gmail.com 
(5d8b0fadeec373cd2861328aeb1cb4293cbc9ded) as they seem relevant. But for this 
sort of thing I've found binary search is often best.

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Keith David Bershatsky]

Thank you, Paul, you hit the nail on the head with your first educated guess.  The problem is present with 9624f609493da7c08016ba00d6895bad0fe26a0e, and the problem disappears when reverting to the previous commit cb367c8e0d4a881acf8255e1ff6bdd6442efb538.  You saved me a lot of time -- greatly appreciated!!!

I will reset to *26a0e and revert each component of that commit one by one in an effort to isolate the problem.  When I have an update on my progress, I'll post another comment to the mailing list -- it may require a good night's sleep though.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [07-12-2019 16:56:23] <12 Jul 2019 16:56:23 -0700>
> From: Paul Eggert <eggert@cs.ucla.edu>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Subject: Re: -getRed:green:blue:alpha: not defined for the NSColor
> 
> Keith David Bershatsky wrote:
> 
> > it would likely take me a very long time to locate the commit by trial and error; e.g., building various versions of Emacs from 04/08/2019 to the present until the culprit is located.
> 
> You can use binary search, so this is only O(log N).
> 
> You could also take a look at commits 2019-04-02T20:49:36Z!alan@idiocy.org
> (9624f609493da7c08016ba00d6895bad0fe26a0e) and the flurry of commits near
> 2019-04-14T02:41:31!agrambot@gmail.com
> (5d8b0fadeec373cd2861328aeb1cb4293cbc9ded) as they seem relevant. But for this sort of thing I've found binary search is often best.

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Keith David Bershatsky]

The following change made with 9624f609493da7c08016ba00d6895bad0fe26a0e is what prevents Emacs on OSX 10.6.8 from working.  Would it be possible for the Emacs team to put in a condition that permits Emacs on OSX 10.6 to use the two lines of code that were removed?  [I do not know what is the earliest version of OSX that can make use of two new lines of code without breaking.]

diff --git a/src/nsimage.m b/src/nsimage.m
index 33236c4..0249d22 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -313,8 +313,8 @@ - (instancetype)setXBMColor: (NSColor *)color
   if (bmRep == nil || color == nil)
     return self;
 
-  if ([color colorSpaceName] != NSCalibratedRGBColorSpace)
-    rgbColor = [color colorUsingColorSpaceName: NSCalibratedRGBColorSpace];
+  if ([color colorSpace] != [NSColorSpace deviceRGBColorSpace])
+    rgbColor = [color colorUsingColorSpace:[NSColorSpace deviceRGBColorSpace]];
   else
     rgbColor = color;

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Alan Third]

On Sat, Jul 13, 2019 at 11:10:29AM -0700, Keith David Bershatsky wrote:
> The following change made with
> 9624f609493da7c08016ba00d6895bad0fe26a0e is what prevents Emacs on
> OSX 10.6.8 from working. Would it be possible for the Emacs team to
> put in a condition that permits Emacs on OSX 10.6 to use the two
> lines of code that were removed? [I do not know what is the earliest
> version of OSX that can make use of two new lines of code without
> breaking.]

Hi Keith, thanks for tracking this down. Can you try this change:

modified   src/nsimage.m
@@ -310,6 +310,6 @@ - (instancetype)setXBMColor: (NSColor *)color
     return self;
 
-  if ([color colorSpace] != [NSColorSpace deviceRGBColorSpace])
-    rgbColor = [color colorUsingColorSpace:[NSColorSpace deviceRGBColorSpace]];
+  if ([color colorSpace] != [NSColorSpace genericRGBColorSpace])
+    rgbColor = [color colorUsingColorSpace:[NSColorSpace genericRGBColorSpace]];
   else
     rgbColor = color;

If that doesn’t work I’ll make your suggested change.
-- 
Alan Third

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Keith David Bershatsky]

Thank you, Alan, for working on this -- greatly appreciated!

Yes, your proposed modification works well for Emacs on OSX 10.6.8.  Emacs starts up just fine and there are no error messages in the gdb terminal.  I did some light testing with cursor movement and splitting windows from the Emacs welcome screen ...

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [07-14-2019 03:24:11] <14 Jul 2019 11:24:11 +0100>
> From: Alan Third <alan@idiocy.org>
> 
> * * *
> 
> modified   src/nsimage.m
> @@ -310,6 +310,6 @@ - (instancetype)setXBMColor: (NSColor *)color
>      return self;
> 
> -  if ([color colorSpace] != [NSColorSpace deviceRGBColorSpace])
> -    rgbColor = [color colorUsingColorSpace:[NSColorSpace deviceRGBColorSpace]];
> +  if ([color colorSpace] != [NSColorSpace genericRGBColorSpace])
> +    rgbColor = [color colorUsingColorSpace:[NSColorSpace genericRGBColorSpace]];
>    else
>      rgbColor = color;

Re: -getRed:green:blue:alpha: not defined for the NSColor

[Alan Third]

On Sun, Jul 14, 2019 at 09:12:08AM -0700, Keith David Bershatsky wrote:
> Thank you, Alan, for working on this -- greatly appreciated!
> 
> Yes, your proposed modification works well for Emacs on OSX 10.6.8.
> Emacs starts up just fine and there are no error messages in the gdb
> terminal. I did some light testing with cursor movement and
> splitting windows from the Emacs welcome screen ...

Thanks. Change pushed to master.
-- 
Alan Third