Re: lookup-color deadlock

[John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>]

Your message:

       I think lookup-color should return nil if the color string isn't found.
       It seems overly pedantic to require the programmer to find out that the
       requested color doesn't exist by trapping name errors using handler-bind
   ...
       
    I agree, returning NIL on name errors would be a nice feature.
    It would be nice if open-font would do this too...
    Would you like to add these features John?
- --------

Ugh.  Not this year...  :-)

I guess my first question then is why does the lookup-color request deadlock --
shouldn't wait-for-reply read the error and print it out?  (It doesn't,
the process just sits in the wait-for-reply)

Looking at Xlib, its reply function returns 0 *without* calling XError
if it gets a NAME error on certain requests, an ALLOC or ACCESS error,
or a FONT error on query-font.  So it would seem we could make
wait-for-reply take apart the error the way Xlib does, eat the error,
and return an "I snarfed this error" value.

Assuming it's possible to snarf the error and return some useful failure value
from (lookup-color, open-font, alloc-coloc, store-color, store-colors,
(did I miss any)), what should be returned?  nil?  Seems like people will
write code like:

(let ((color (xlib:lookup-color *default-colormap* "brownn")))
  (setq red-val (xlib:color-red color)))

which will fail with an unhelpful bus error on conventional architectures (in
compiled code at high speed, low safety settings, your mileage may vary).

However, even with this problem I think it's better to return nil than to
signal an error.  Is there an approval process for changes to the CLX
spec?

I'm CC'ing this letter to cl-windows to provoke some discussion.

	-- John Irwin, Franz Inc.  jdi%franz.uucp@ucbarpa.berkeley.edu