gmane.lisp.mcclim.devel

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Andy Hefner — 2008-08-23T16:05:45

(defmethod port-deallocate-pixmap ((port clx-port) pixmap) + (let ((medium (climi::pixmap-medium pixmap))) + (when medium + (with-slots (gc) medium + (when gc + (xlib:free-gcontext gc))))) (when (port-lookup-mirror port pixmap) (destroy-mirror port pixmap))) Would it be more appropriate to move the subform starting with (with-slots (gc) ..) to deallocate-medium (or possibly degraft-medium), and one of those instead? Not a big deal, given virtually nothing else in mcclim calls these when it probably should.

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Christophe Rhodes — 2008-08-23T13:31:54

I attach a patch for consideration against mcclim (yeah, I know, I have commit access, but I'm rusty) which seems to fix the leaky gcontext problem in the CLX backend. There may well be an analogous problem in other backends (except the Null backend :-); I haven't investigated. I've also got something like Andy's resourcealloc patch in my clx (not pushed yet), along with a fix for Shawn's resource ID issue. Wow, it's almost like being up to date... Best, Christophe

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Andy Hefner — 2008-08-22T17:40:55

I think there are two bugs at play here - first, that CLX makes no attempt to avoid reusing IDs that are still in use once the count wraps around, and second that in this instance mcclim creates millions of gcontexts without freeing them. I've hacked resourcealloc in CLX to check against the id cache, skipping IDs which are still in use, but this runs into the problem that not all types (in particular, graphics contexts) are stored in the cache. There's some comment about this not being useful and wasting space in depdefs.lisp next to defconstant +clx-cached-types+, and without considering the performance implications I've worked around it by setting the hash table entry to T at the point the ID is allocated, so that (I hope) every allocated resource is now there. To do this correctly also requirse that the deallocate-resource-id be changed to unconditionally invoke deallocate-resource-id-internal (thereby making the macro useless), which I've neglected to do. With that in mind, here's a version of resource

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Nikodemus Siivola — 2008-08-22T16:32:56

I did not, but here are the results from a new run: Received CLX ID-CHOICE-ERROR in process NIL debugger invoked on a XLIB:ID-CHOICE-ERROR: Asynchronous ID-CHOICE-ERROR in request 10247 (last request was 10248) Code 55.0 [CreateGC] ID #x800002 Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Ignore 1: [TRY-AGAIN] Try executing the command COM-STRESS again 2: [ABORT ] Return to application command loop 3: Exit debugger, returning to top level. (XLIB::X-CERROR "Ignore" XLIB:ID-CHOICE-ERROR)[:EXTERNAL] 0] (let ((display (xlib:open-default-display))) (values (xlib:display-resource-id-mask display) (xlib:display-resource-id-base display))) 2097151 10485760 0] I'm keeping the session alive, so let me know if you need anything else. Cheers, -- Nikodemus

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Christophe Rhodes — 2008-08-22T15:30:52

Please tell me you saved the exact error message and can now add that piece of information... in particular, I'm interested in the hex number that is reported as part of the id-choice error. C.

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Nikodemus Siivola — 2008-08-22T12:50:44

Was able to reproduce here, though it took something like 30 minutes. In the image where I had just duplicated the error, while in the debugger: 2097151 10485760 In a clean image with just CLX loaded: 2097151 8388608 Cheers, -- Nikodemus

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Christophe Rhodes — 2008-08-22T12:20:25

It's still going here, about 4 hours later. Can you run (let ((display (xlib:open-default-display))) (values (xlib::display-resource-id-mask display) (xlib::display-resource-id-base display))) against your X server? Thanks, Christophe

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Nikodemus Siivola — 2008-08-22T12:09:55

IIRC it used to break in less then five minutes. I'll try to reproduce again before updating CLX. Cheers, -- Nikodemus

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Christophe Rhodes — 2008-08-22T10:16:01

I don't think this is related, but I have been investigating that one this morning anyway, while waiting for your test case to break. (It's been about an hour so far; is that normal? I can suggest diagnostics to run on your system if not.) Because your resource ID was suspicious (had a large number of 0s in it: #x600002 or so) I would tend to suspect either a bug in the resource ID logic in clx, or a bug in the X server (this is Apple, after all...) I think that the fix to Shawn's problem is to teach clx to cache only its own client resource IDs, and not anyone else's. Before installing that fix, I want to read xlib or xcb sources, and possibly a window manager's, to check that that's sane. (If someone else wants to read xlib/xcb sources instead, please be my guest!) Best, Christophe

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Nikodemus Siivola — 2008-08-22T09:15:58

I don't remember offhand for sure, but I think that was actually on a single-threaded SBCL -- so there would perforce be only one thread in Lisp Land. Since it seems to be in danger of falling through the cracks, here is a (possibly related) report from sbcl-devel. Cheers, -- Nikodemus ---------- Forwarded message ---------- From: Shawn gmail.com> Date: Sat, Jul 12, 2008 at 5:27 AM Subject: Re: [Sbcl-devel] breaking the clx xid cache To: sbcl-devel< at >lists.sf.net Hi folks, It looks like the portable-clx mailing list is down so I'm sending this here. In stumpwm I've been getting more and more error reports where the :window slot for events is a pixmap instead of a window. I've tracked it to a problem with the xid cache in clx. X appears to be recycling XIDs which confuses clx. Here's a function that exposes the bug: (defun break-display-xid-cache () (labels ((make-win (dpy) (xlib:create-window :parent (xlib:screen-root (first (xlib:display-roots dpy))) :x 0 :y 0 :width 50 :heigh

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Christophe Rhodes — 2008-08-22T06:02:29

Thanks, pushed. Best, Christophe

Re: [bug] Asynchronous ID-CHOICE-ERROR -- CLX orMcCLIM?

Andy Hefner — 2008-08-22T03:06:37

I just encountered the "Asynchronous ID-CHOICE-ERROR" myself tonight, in my case when multiple mcclim applications (in multiple threads) on one screen race to repaint. I don't know if it's related to Nikodemus' test case, which doesn't make any use of threads (excluding the omnipresent CLX event dispatching thread), but at least it's the same error. Attached is a patch to CLX intending to address a race condition when multiple threads attempt to allocate a resource ID - DISPLAY-RESOURCE-ID-COUNT is incremented, but there is no locking to protect the slot, resulting in intermittent duplicate IDs and subsequent ID-CHOICE-ERROR. I've wrapped the allocation in a with-display, and done the same to the nearby deallocate-resource-id-internal for good measure. This should protect the incf in resourcealloc, the (setf gethash) in save-id, and the remhash in deallocate-resource-id-internal. --- old-clx/display.lisp 2008-08-21 23:27:35.000000000 -0400 +++ new-clx/display.lisp 2008-08-21 23:27:35.00000000

Re: Crude multilingual input: CLX meets XKB's bodyparts.

Samium Gromoff — 2008-08-21T15:02:38

From: Christophe Rhodes cantab.net> Ok, I've done the conditional bit by generalising it somewhat, and factoring in BIG-REQUESTS. The only changes are against CLX. Perhaps "auto-init-fn" is a stupid name for that keyword parameter, but I couldn't come up with anything better. regards, Samium Gromoff diff --git a/big-requests.lisp b/big-requests.lisp --- a/big-requests.lisp +++ b/big-requests.lisp < at >< at > -19,7 +19,8 < at >< at > ;;; ;;; The name of this extension is "BIG-REQUESTS" (Big Requests ;;; Extension, section 4) -(define-extension "BIG-REQUESTS") +(define-extension "BIG-REQUESTS" + :auto-init-fn enable-big-requests) (defun enable-big-requests (display) (declare (type display display)) diff --git a/clx.asd b/clx.asd --- a/clx.asd +++ b/clx.asd < at >< at > -70,6 +70,7 < at >< at > ((:file "shape") (:file "big-requests") (:file "xvidmode") + (:file "xkeyboard") (:xrender-source-file "xrender") (:file "glx") (:file "gl" :depends-on ("glx"))

Re: Crude multilingual input: CLX meets XKB's bodyparts.

Samium Gromoff — 2008-08-13T05:59:18

From: Kalyanov Dmitry gmail.com> Not by me -- despite the obvious part of it being trivial, I've had, and am continuing to have, an extremely busy period in my life. It's not that this guarantees no work being done on my part, just the uncertainty of when it happens. Nice to have a reminder, though, I've had it preempted out of my head.. regards, Samium Gromoff

Re: Crude multilingual input: CLX meets XKB's bodyparts.

Kalyanov Dmitry — 2008-08-13T08:45:54

Re: Re: Redisplay and pixmaps

Sascha Wilde — 2008-08-12T11:08:21

Re: Re: Redisplay and pixmaps

Кальянов Дмитрий — 2008-08-11T15:48:49

Re: Redisplay and pixmaps

Sascha Wilde — 2008-08-11T09:24:19

Sorry, send the last message to early per accident, here are the missing questions: 1. What do I have to do, so that the display-function is called _every time_ a redisplay is needed? 2. Is there a better way to ensure that the picture is redisplayed whenever needed, maybe even that magical es done with the text? I know that this happens with graphics directly drawn to the pane, but as I want to draw rendered images, which basically consist of hundreds of thousands of draw-point operations this is way to slow... cheers sascha

Redisplay and pixmaps

Sascha Wilde — 2008-08-11T09:19:43

Hi *, I'm new to CLIM and currently looking for a good (and simple) way to redisplay a rendered picture (my toy program is an mandelbrot generator). My problem is, that the :display-function which in my case simply copies a pixmap to the application pane is less often called than actual redisplay is needed. Given the following simple example code: --8<---------------cut here---------------start------------->8--- (in-package :common-lisp-user) (defpackage "APP" (:use :clim :clim-lisp) (:export "APP-MAIN")) (in-package :app) (define-application-frame superapp () ((gfx :initform nil :accessor gfx) (redisplay-counter :initform 0 :accessor redisplaynr)) (:pointer-documentation t) (:panes (app :application :display-function #'redraw-gfx :height 400 :width 600) (int :interactor :height 400 :width 600)) (:layouts (default (vertically () app int)))) (define-superapp-command (com-draw :name t) () (setf (gfx *application-frame*) (allocate-pixmap (frame-standard-output *application

Retaining pane view on resize

christopher melen — 2008-08-07T17:36:16

Hi, Is there a way of ensuring that the bottom of a pane remains visible as the parent frame is resized? What I mean is when the frame is resized from the bottom the lower edge of the pane retains its relative position. I am thinking of something equivalent to ACL Common Graphics :bottom-attachment option. Many thanks __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Re: Re: [PATCH] Drei: adding some PRINT-OBJECTs forlambda-list related objects.

Troels Henriksen — 2008-07-17T10:25:52

You probably can't, because I haven't had the need to do that yet.