[Openmcl-devel] Weird problem with ns-color

Ron Garret ron at flownet.com
Tue Feb 4 05:14:23 UTC 2020


I realize that I am way behind the times here, but...

Welcome to Clozure Common Lisp Version 1.11-r16812M  (DarwinX8664)!
? (setf x (#/colorWithCalibratedRed:green:blue:alpha: ns:ns-color 0.0 0.0 1.0 1.0))
#<NS-COLOR NSCalibratedRGBColorSpace 0 0 1 1 (#x600000243CF0)>
? (setf y (#/colorWithCalibratedRed:green:blue:alpha: ns:ns-color 0.0 0.0 0.9 1.0))
#<NS-COLOR NSCalibratedRGBColorSpace 0 0 0.9 1 (#x608000440570)>
? x
#<NS-COLOR NSCalibratedRGBColorSpace 0 0 1 1 (#x600000243CF0)>
? y
#<NS-COLOR NSCalibratedRGBColorSpace 0 0 0.9 1 (#x608000440570)>
? 

Then I close the listener window and open a new listener:

Welcome to Clozure Common Lisp Version 1.11-r16812M  (DarwinX8664)!
? x
#<NS-COLOR NSCalibratedRGBColorSpace 0 0 1 1 (#x600000243CF0)>
? y
#<Bogus ObjC Object #x608000440570>
? 

This is 100% reproducible,  It is also data-dependent.  Any color with an RGB value that is not numerically equal to 1 or 0 gets corrupted when the listener it was created in is closed.

My guess is that this has something to do with the first listener’s autorelease pool being drained, but why would that depend on the numerical value of one of the color fields?

Thanks,
rg



More information about the Openmcl-devel mailing list