To: rpgoldman@real-time.com, To: mcclim-devel@common-lisp.net Date: Thu, 4 May 2006 02:51:07 +0200 From: Max-Gerd Retzlaff

As I have said:

When I now load McClim into the generic ACL 6.2 image even a simple CLX demo like XLIB::JUST-SAY-LISP doesn't work anymore. (Before the loading of McClim it does).

Bye, Max

"Doesn't work" is NOT a very helpful discription! Any error messages? Dumps core? Returns to the prompt without doing anything? Mike McDonald mikemac@mikemac.com

Hello, after having checked out, built and tested cvs mcclim of two months, one months, 45 days, 37 days, and 41 days ago I've found the commit that has caused my CLX breakage: "Fix (temporary hack) to use file sockets in CLX on ACL": http://article.gmane.org/gmane.lisp.mcclim.cvs/418 The comment in this patch says: +;;; XXX CLX in ACL doesn't use local sockets, so here's a fix. This is gross +;;; and should obviously be included in Franz' clx and portable clx, but I +;;; believe that enough users will find that their X servers don't listen for +;;; TCP connections that it is worthwhile to include this code here +;;; temporarily. Of course, it would be nice to not require the X server to run without "--nolisten tcp" but this patch breaks the whole CLX (not only for mcclim) on my system. The function is obviously taken from Franz' version of clx (or both have a common ancestor) and then an if-construct is added that will, under certain circumstances, connect to the X server via the FILE menthod instead of the usual TCP connection. But in the version in acl/contrib/clx/dependent.cl this function is prefixed by an #+(and excl clx-use-allegro-streams) while clx-use-allegro-streams is pushed on the *features* in the Makefile of clx *only on mswindows*. If there is no clx-use-allegro-streams a variant of the function will be taken that uses a file descriptor (see ftp://ftp.franz.com/pub/contrib/clx/dependent.cl). As the new version in mcclim/Backends/CLX/port.lisp is only prefixed by #+allegro it will also replace the latter function, and that is not very nice as the described problems occur. Btw. the "fix" will also not work on mswindows if host is either string= to "" or "unix" as Franz's documentation to make-socket says: "The value of the address-family keyword can't be :file on Windows because Windows does not support it." (See http://www.franz.com/support/documentation/6.2/doc/pages/operators/socket/ma... or http://www.franz.com/support/documentation/8.0/doc/operators/socket/make-soc...) In general it is also all but nice that a function of the package xlib will be changed in the mcclim backend via a (defun xlib::open-x-stream ...). Because of these problems I propose to remove the patch from the mcclim cvs repository again. It would be nice to not require an X server that listens for TCP connections but this code is too buggy and mcclim/Backends/CLX/port.lisp is just not the right place for such an hack. What do you think? Bye, Max -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> http://blog.matroid.org For your amusement: In the Spring, I have counted 136 different kinds of weather inside of 24 hours. -- Mark Twain, on New England weather

Hello On Thu, May 04, 2006 at 07:38:49PM -0700, Mike McDonald wrote:

...

Of course, it would be nice to not require the X server to run without "--nolisten tcp" but this patch breaks the whole CLX (not only for mcclim) on my system.

No, it'd be really nice if psuedo security weenies wouldn't break the standard X configuration!! (Can you tell I have an opinion on this subject?)

Yes, of course. On every machine I use I have configured (or let configure) X to listen on TCP connection, as I do not only need it for mcclim but in general. It really gets on my nerves that I have to give reasons for the change to each administrator again. Unfortunately, and stupidily, the default for most distributions seems to be "--nolisten tcp" these days. That's the reason why I've said not to require it would be nice; that doesn't mean that I like the decision to use this as the default setting (in the name of an alleged higher security). (If they are so desperate to want to disable "remote X access"[1] they should bind X to localhost / the loopback device but not disable listening for TCP connections in general.) Bye, Max 1) See for example: http://www.debianhelp.co.uk/security.htm http://www.us.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.e... -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> http://blog.matroid.org For your amusement: Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.