Problems (conceivably) with scheme-xp design and questions ******************************************************************************** A somewhat silly point. When using lists of points, or alists, or whatever, use (x y) or (x . y)? It's a shame that (x . y) is so much uglier than (x y). (x . y) is now always used. Maybe it should be the other way ... ... leaning more and more that it should be the other way ... Now it's the other way. ******************************************************************************** We use an alist for things that would traditionally use keywords. The best compromise? ******************************************************************************** Buffer output? This is supposed to speed things up. I don't think we're at the point of counting context switches yet, though. ******************************************************************************** Things like poly-points should probably be (poly-point d gc mode '(x0 . y0) '(x1 . y1) '(x2 . y2)) rather than (poly-point d gc mode '((x0 . y0) (x1 . y1) (x2 . y2))) ******************************************************************************** What format, exactly, is a sequence of Char2Bs? Is there some odd conversion from JIS (for example) to Char2B? We need some method for unifying string8 and string16 values. ******************************************************************************** There's a bug somewhere. Once, I saw a choke due to event 135 not being supported. There shouldn't be anything at all over 127. It showed itself during (color-change). ******************************************************************************** Need opcode->request-name. ******************************************************************************** Pools? Right now (April 27, 1999), we have a string set aside for each request. (We were producing lots and lots of garbage, before.) But this blocks another thread trying the same call. I don't see this becoming a concern, but there's an alternative. We can set up a cache of strings. When a request is made, it grabs a string from the cache. If one isn't available, we allocate one. If we kept one string per request available in the cache, it would only take up 1 or 2k, and they wouldn't initiate a collection. If we drop one, it just gets collected -- no leaks. The request would still stall at the mouth of the (locked) xserver pipe. We could max out the number of same-request strings in the cache and just drop extras, if there was some odd surge of popularity among a request. ******************************************************************************** The number of locks used is getting pretty absurd. ******************************************************************************** There is much garbage produced by mover, which was written to track the problem. I laboriously went through and removed as much garbage production as I could, trying to find the source. It all seems to be coming from activation records. Weird. ********************************************************************************